AWS access keys are the most commonly leaked cloud credential — the classic AKIA... prefix appears in public repositories thousands of times a day, and automated scanners harvest them continuously. Speed matters more than perfection. The playbook below is ordered to minimize damage first and answer questions second.
Step 1: Deactivate the key — right now
Console: IAM → Users → Security credentials → find the key → Actions → Deactivate. CLI, faster:
Deactivation takes effect within seconds across the entire AWS control plane. Deactivate first; delete later, after rotation and verification.
Step 2: Audit what the key actually did
CloudTrail records every API call made with that key. Filter Event History by the access key ID and pull the full window from key creation to deactivation. What you're looking for: EC2 instance launches (crypto mining), IAM changes (privilege escalation), S3 access (data exfiltration), and cross-account activity. This audit defines your blast radius and tells you whether this is a cleanup or a breach notification.
Step 3: Rotate everything the key could reach
Whatever the key touched, treat as compromised: any resource it administered, any secret it could read. Rotate database credentials, other IAM keys, and signing material in that scope. If the key had broad admin permissions, assume the worst and rotate widely — a leaked admin key can create its own backdoor keys that survive your rotation.
Step 4: Purge the key from code and history
Remove the key from wherever it leaked — repo, config, environment — then rewrite history so the credential is gone from every commit. Full walkthrough in How to Remove a Secret From Git History. Deletion of the key in IAM comes last: once your audit trail is preserved and nothing depends on it.
Step 5: Prevent recurrence
Long-lived access keys are the root cause of the whole class of incident. The durable fixes:
- Scan before commit and at push — pre-commit hooks and push protection catch the key while it's still local.
- Prefer roles over keys — EC2 instance roles, OIDC federation for CI, anywhere IAM roles can replace static keys.
- Short-lived credentials — STS tokens that expire in hours turn a leaked key from an emergency into a non-event.
- Least privilege — a read-only key on a sandbox bucket is a very different leak from an admin key.
- Scan continuously — full git history and non-code sources, not just the working tree.
Vooda automates the scanning half of this list: 900+ rules catch the AKIA... pattern in code, history, config files, and chat — with AI triage so the queue stays reviewable, and verification so you know whether the key is still live before anyone pages.
Frequently asked questions
What should I do first if my AWS access key is exposed?
Deactivate the key in IAM immediately — console or CLI. This stops all API access using that key within seconds. Then audit CloudTrail for what the key did before deactivation.
How do I check what an exposed AWS key was used for?
Query CloudTrail Event History with the access key ID as a filter. It records every API call made with that key — what resources were touched, from which IPs, and when.
How do I deactivate an AWS access key from the CLI?
Run aws iam update-access-key --access-key-id AKIA... --status Inactive --user-name <user>, then confirm with aws iam list-access-keys.
Should I delete or deactivate a leaked AWS access key?
Deactivate first — instant and reversible. Delete only after rotation, verification that nothing depends on the old key, and preserving the audit trail you need.
How do I prevent AWS access keys from leaking again?
Scan before commit and at push, prefer IAM roles and short-lived credentials over long-lived keys, enforce least privilege, and scan history and non-code sources continuously.