A leaked AWS access key is one of the most time-sensitive incidents a team can face — automated scanners actively search public code repositories for exposed keys, and usage can begin within minutes.
Step 1: Deactivate, don't delete, immediately
Mark the key Inactive in IAM the moment you confirm exposure. This stops further use instantly while preserving the key's identity for the investigation in the next step — deleting it outright can make some forensic steps harder.
aws iam update-access-key --access-key-id AKIA... --status Inactive --user-name <username>
Step 2: Check CloudTrail for activity
Before assuming the worst or the best, check what the key was actually used for during its exposure window:
aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIA...
Look specifically for unfamiliar source IPs, unusual API calls (especially IAM, EC2, or S3 actions unrelated to normal usage), and any activity outside your typical usage patterns or time zones.
Step 3: Assess blast radius via the key's permissions
Check exactly what the IAM policy attached to this key allowed. A key scoped to a single S3 bucket has a very different blast radius than one with broad AdministratorAccess — this materially changes how urgent and wide your investigation needs to be.
Step 4: Rotate and update dependent services
Issue a new key, deploy it everywhere the old one was used, confirm functionality, then fully delete the old key (not just deactivate) once you're confident nothing still depends on it.
Step 5: Check for persistence mechanisms
If CloudTrail shows suspicious IAM activity (new users created, new access keys issued, policy changes), an attacker may have established a persistence path beyond the original leaked key. Review recent IAM changes account-wide, not just activity tied to the compromised key itself.
Step 6: Remove the exposure source
If the key leaked via a git commit, remember the leaked value itself remains recoverable from git history even after rotation — combine this response with a history scan and cleanup if the exposure was in a repository.
Step 7: Post-incident review
Once contained, review how the key was exposed in the first place (a public repo? a misconfigured CI log?) and what controls — like pre-commit secret scanning — would have caught it before exposure, not just after.