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

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.

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

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

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

TL;DR: