Revoke the key first, then read the provider's audit logs for activity under that key during the exposure window. Look for requests from unfamiliar addresses, unusual regions, new resources and permission changes. Last used data tells you if the key was touched, and audit logs tell you what was done.
Revoke before you investigate
GitHub's remediation guidance puts revocation first and activity review after. It says to consider any leaked secret compromised, and that removing it from code or pushing a new commit does not stop it being used. OWASP's containment order is the same: revoke, rotate, then delete exposed copies. Investigation is for scoping damage, not for deciding whether to act.
If downtime worries you, create and deploy the replacement first, then revoke the old one.
Define the exposure window
You need two timestamps: when the secret was first exposed and when it was revoked. Get the first from the commit date, message post time or log timestamp. The window is the period an outsider could have used it.
Where to look
| Source | What it tells you |
|---|---|
| Provider audit log | Calls made with the key, from where, and when |
| Key metadata | Last used time, service and region |
| Billing and usage views | Unexpected spend or new resource types |
| Your own access logs | Odd requests to your API if the key was yours |
| Secrets manager logs | Who read the secret and when |
AWS documentation recommends using CloudTrail to monitor access key usage and detect unauthorised access, and the IAM service reports last used information for each access key. Other providers offer similar logs under different names.
A step by step method
- Record the key identifier, not the secret value, in your incident notes.
- Pull logs for the exposure window and a day either side.
- Filter to that key identifier.
- Group by source address, user agent and region.
- Mark anything your own systems cannot explain.
- Look for follow on actions: new users, new keys, changed policies, data downloads.
- If you find misuse, widen the response: rotate related credentials and review the permissions the key held.
OWASP lists what responders need to know: who accessed the secret, when it was used and when it was last rotated. Having those records ready makes this faster.
When there are no logs
Some providers log little, or logging was off. Then assume the worst for that key's permissions. Scope the review by what the key could do, and rotate anything it could read. See leaked secret response order.
Quick check
The key shows no use. Am I safe?
Safer, not safe. Logs may be incomplete or delayed. Still rotate, and keep watching the provider for later use of the old key.
How long should I keep the logs?
OWASP suggests keeping CI/CD logs queryable for at least 90 days and archiving them longer. Match your own retention to your incident needs.
Safeguard supports compliance and evidence automation, and a free scan can help you find what else is exposed in a repository.
Sources
- GitHub docs: remediating a leaked secret
- AWS IAM: manage access keys
- OWASP Secrets Management Cheat Sheet
Last reviewed: 19 October 2026.
