Everyone who works with credentials long enough has this moment: you paste a config block into a browser tool to read it more easily, and halfway through you notice an AKIA… or an sk_live_… in what you just sent. The rest of the response is about sequence, because the instinct — to start investigating — is the wrong first move.
Minute 0–5: revoke before you understand
The credential is already exposed. It does not matter whether the site claims to store nothing, whether you trust the operator, or whether you closed the tab. Treat it as compromised and make it stop working.
- Cloud keys: deactivate the access key in your provider’s console. Deactivate rather than delete, so you keep the audit trail.
- Payment API keys: roll the key in the provider’s dashboard. Most providers keep the old one valid for a short grace period; end that window now.
- Database passwords: change the password, then check for active sessions and terminate them.
- Tokens with a short life: if it expires in ten minutes and has a narrow scope, you can often wait it out. Check the scope before deciding.
Deactivating is reversible. An attacker’s first action on a live key is usually to create a new key of their own, which is why the order is revoke-then-investigate rather than the reverse.
Minute 5–30: look for use
Now check whether anything happened. Providers keep this data, and it is usually queryable.
- Cloud audit logs: filter to the key’s identifier (not the secret) over the last hour. Look for
CreateAccessKey,CreateUser,AttachUserPolicy, unusual region usage, and new resource creation. - Payment provider events: look for charges, payout changes, or webhook endpoint edits. Both are the standard first moves after a key leak.
- Service logs: check for authentication events from unexpected source addresses.
If the logs show nothing, that is genuinely reassuring but not a guarantee. Automated scanners work fast — one widely reported experiment with a deliberately planted cloud key in a public formatter recorded unauthorised use attempts within 48 hours — but not every leaked key is scraped, and quiet days happen.
Minute 30–60: fix the path that led there
The credential was in a text file that someone pasted into a browser. That is worth a look, because the same file probably has more credentials in it, and the same habit will reproduce the incident.
- Find every copy. The original file, your clipboard history, shell history, any notes app or scratch file you pasted it into first, and any chat message where you shared it.
- Check whether it is in version control. A key committed to a repository lives in history forever and is scraped from public repos continuously. Rotating the key is the fix; rewriting history is hygiene.
- Move the secret out of the file. Use your platform’s secret manager and reference it by name. The reason the config file was readable enough to want pasting in the first place is that it was doing a secret manager’s job badly.
What not to do
Do not send the key to anyone for verification. Including support teams. A support engineer never needs the secret value; if they ask for it, that is a separate problem.
Do not assume a “trusted” destination is safe. A tool you have used for years can add server-side processing in a release note you did not read. The 2025 formatter incident affected sites that had been trusted for a decade.
Do not rely on the site’s privacy policy as evidence that nothing was retained. Read it as a description of intent. The only reliable control you have is that the credential no longer works.
Reducing the chance of a repeat
Three habits cover most of the risk, and none of them slow you down much.
- Use tools that cannot receive your input. A tool that computes in your browser has no server-side copy to leak, so the failure mode is removed rather than mitigated. This is the entire argument for local processing and it takes ninety seconds to verify with the procedure here.
- Redact before you paste. Replace the secret with a placeholder of the same shape —
AKIAIOSFODNN7EXAMPLE— before formatting. The structure of a config is what you were reading for; the secret value is not. - Give keys a scope that limits the blast radius. A read-only key with an IP restriction is a bad afternoon. A root-level key with no restrictions is a company-level event.
The uncomfortable truth is that the paste happens because reading a dense config in a textarea is genuinely useful. Keep the useful behaviour, and change the destination.