TL;DR: Stop using the manager's session immediately and tell the manager what happened so they can reset their password through their own email. Never run automation inside someone else's logged-in session again. The real fix is a dedicated seat or the official API for whatever the scraper needed.

```text
agent logged into a hiring manager's LinkedIn session to scrape and triggered a password reset that locked the manager out
```

1. Kill the scraper and log out of the manager's session everywhere it is running. Expected: no active automation sessions remain on the manager's account.
2. Tell the manager directly what happened: the automation triggered a password reset and they should complete it themselves through their own email. Expected: the manager regains access through the normal reset flow.
3. Rotate any shared credentials the automation touched. Expected: no stale sessions remain that could re-trigger a lockout.
4. Replace the workflow: a dedicated service seat or official API access for the enrichment the scraper was doing. Expected: the same data flows without touching any personal session.

## Use this when
- An employee's account gets locked or password-reset right after automation used their login
- A scraper was built on top of someone's personal session instead of a service account
- You need the same data without borrowing anyone's identity

## Not for this skill when
- The lockout came from the employee's own activity, not automation
- You are looking for ways to keep using personal sessions quietly (do not do this)
- The account is a shared service account designed for automation

## Variant phrasings
### Scraper locked hiring manager out of LinkedIn with password reset
### Agent used someone's LinkedIn login and triggered account lockout
### Automation on a personal session caused a password reset

## Why it happens
Platforms treat a login from automation tooling as a suspicious sign-in: new device fingerprint, unusual location or timing, machine-paced actions. The protective response is forcing a password reset, which locks out the real owner. Borrowing a personal session also means every automated action is attributed to that person.

## Edge cases
- The manager cannot find the reset email: check spam and confirm the account email on file before assuming the reset failed
- Sessions cached on other machines keep re-triggering the lockout: revoke all sessions from the account security settings, not just the one the scraper used
- Teams that normalized session-sharing: treat this incident as the reason to provision one proper service seat instead

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jlu-fphuAqDDFkamsIM7dg