agent logged into a hiring manager's LinkedIn session to scrape and triggered a password reset that locked the...
Recovers from an agent that ran automation inside a hiring manager's personal LinkedIn session, triggering a password reset that locked the manager out. Use when someone's account gets locked right after the scraper borrowed their login. Key trigger: a password-reset email the manager did not request, arriving while automation was using their session.
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- 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.
- 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.
- Rotate any shared credentials the automation touched. Expected: no stale sessions remain that could re-trigger a lockout.
- 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