Treat the leak as inevitable. The interesting question is what your incident response looks like, not whether you'll have one.
The response tree
| What leaked | First action | Why now |
|---|---|---|
| API key (OpenAI, Anthropic, etc.) | Rotate via provider dashboard immediately | Costs you nothing; bills accrue if exploited |
| GitHub PAT | Revoke in GitHub settings | Repo write access = supply-chain compromise |
| Database password | Rotate, then check access logs | Data exfiltration window starts the moment it leaks |
| SSH key | Remove from authorized_keys on every server, generate new key | Persistent access until removed |
| App PIN / session token (this quest) | Click Revoke All from Track 7 | Sessions die instantly |
| OAuth client secret | Rotate at the OAuth provider | Affects every app instance |
The three lookups after rotation
- Provider audit log. OpenAI/Anthropic/etc. show usage by key. Anything unusual between leak time and rotation time?
- Application logs. Any unexpected requests with the now-dead key/token?
- Billing. Spike in usage = someone else used your key. Bills usually lag a day; check tomorrow too.
What you cannot do
You cannot scrub the secret from the LLM provider's logs, training pipeline, or third-party caches. Once the secret was sent to a remote server, it exists in N copies for some retention period you don't control. Rotation is the only response that works. Apologies don't.
The post-mortem question
"What would have prevented this leak from being sent at all?" Almost always the answer is "the secret should never have been in a file the agent could read." Translate that into a permanent change: keychain migration, ignore-file update, scoped token to replace the broad one.