Verify Copied Key Revocation
Confirm that a copied API key is invalid at its provider, while the replacement credential still serves each authorized caller.
Removing a key from a local process does not revoke a copy. If a credential appeared in a log, repository, prompt, or shared machine, assume a copy may exist until the issuing provider disables it. The decisive evidence is provider-side invalidation plus a healthy replacement path.
First identify the provider account and key ID without redistributing the value. Ask the owner what revocation method the provider supports. Some services revoke immediately; others use propagation or cached sessions. Do not invent a universal delay. Follow the provider's documented behavior and record uncertainty where it remains.
Revocation evidence checklist
| Question | Evidence |
|---|---|
| Which key? | Provider-side ID or fingerprint |
| Who acted? | Authorized operator and timestamp |
| What changed? | Provider revocation receipt or status |
| Is it rejected? | Safe request returns an auth denial |
| Is replacement healthy? | Expected owned operation succeeds |
| Are derived tokens active? | Separate session or token review |
| Are copies retained? | Incident handling for logs and backups |
Use the old value only if an authorized operator has a safe local way to run a minimal rejection test. Do not paste it into a new tool, ticket, or model prompt just to prove failure. A provider-side disabled status may be enough when direct testing would create more exposure. Keep the method and its limit in the record.
When the provider cannot revoke this key now
Record the exact provider limitation and the earliest supported expiry or owner action. Move each known caller to a replacement with a safe health check. Disable the affected integration or narrow its provider-side permissions if those controls exist; verify the change instead of treating a local disconnect as revocation. If neither provider revocation nor a verified restriction is possible, keep the incident open with an owner, exposure window, monitoring plan, and next decision time. Do not mark the copied value invalid merely because new requests from your application use another key.
Close the incident loop
Check every known caller after the replacement. A job that runs once a day may not reveal a broken key during a quick smoke test. Compare provider usage, application errors, and service health over the agreed observation window. A copied credential may also have been exchanged for another token; review that possibility based on the provider's actual model.
OWASP's secrets guidance covers rotation and revocation as separate lifecycle actions. Keep them separate in the incident timeline. A new key working does not prove the old key stopped working. Do not close the case until both states have evidence or an explicit unresolved hold.
Make offboarding verifiable
Use the offboarding checklist to identify owners, revoke grants and verify the result. Discuss a scoped review of your application's access controls.