What to Do When an AWS Access Key Leaks

Last verified on Nov 8, 2026.

Deactivate the key first. A deactivated key stops working for programmatic calls and can be switched back on, so it costs you nothing if the exposure turns out to be harmless. Then find out what the key did, check for persistence the attacker may have left, and rotate to a new key. This guide covers that sequence for an IAM access key beginning with AKIA.

Step 1: Identify the Key and Deactivate It

GuardDuty's remediation guidance separates key types by prefix. Keys starting AKIA are long-term credentials for an IAM user or the account root user. Keys starting ASIA are short-lived credentials from AWS STS, covered below.

Find the owner and last use of the leaked key:

aws iam list-users --query 'Users[].UserName' --output text | tr '\t' '\n' | while read u; do
  aws iam list-access-keys --user-name "$u" \
    --query "AccessKeyMetadata[?AccessKeyId=='AKIAIOSFODNN7EXAMPLE'].[UserName,Status]" --output text
done

aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLE

get-access-key-last-used returns the date and time of last use and the service and Region of the last request. A last-used time after the leak is a bad sign, and the service tells you where to look first.

Deactivate:

aws iam update-access-key --user-name Bob \
  --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive

If production depends on this key, deactivating it will break production. Decide in minutes, not hours: a deactivated key can be reactivated, and an exposed key with broad permissions can run up charges and exfiltrate data while you decide.

If the key belongs to the account root user, treat it as an account-level incident: the key can reach everything in the account, so everything in the account is in scope.

Step 2: Find What the Key Did in CloudTrail

CloudTrail event history gives you 90 days of management events per Region at no charge. lookup-events accepts one lookup attribute, and AccessKeyId is one of them:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAIOSFODNN7EXAMPLE \
  --max-results 50 --output json \
| jq -r '.Events[].CloudTrailEvent | fromjson
    | [.eventTime, .eventSource, .eventName, .sourceIPAddress, .userAgent, (.errorCode // "-")] | @tsv'

Three limits matter. Event history is recorded in the Region where the event happened, so run the command in every Region, not just your main one. It shows only management events: no data events such as S3 object reads. And it is limited to 90 days, so a trail or CloudTrail Lake is what you need for older activity.

Read the output for these:

• Source addresses you do not recognize, or one that changes between calls.
• Regions you do not use. A burst of RunInstances in a Region your team has never used deserves an immediate look.
• Persistence. CreateUser, CreateAccessKey, CreateLoginProfile, AttachUserPolicy, PutUserPolicy, and UpdateAssumeRolePolicy are how an attacker keeps access after you rotate this key.
• Defense evasion. StopLogging or DeleteTrail.
• Failed calls. An errorCode such as AccessDenied on a run of different operations means someone was enumerating what the key could do.

For the full set of CloudTrail queries beyond a single key, see CloudTrail investigation. The AWS CloudTrail page covers shipping the trail itself.

Preserve the Evidence

Before you change anything else, save what you found. Event history is an immutable record, but it only reaches back 90 days, and events fall off the end as time passes. Download the results from the Event history page, or write the lookup-events output to a file. The console download holds up to 200,000 events per file. If you have a trail writing to S3 or CloudWatch Logs, note where it lives and who can delete from it, because logging being switched off or a trail deleted is itself a sign of compromise.

Step 3: Look at GuardDuty

If GuardDuty is on, check its IAM findings. Finding types that apply to a leaked key include:

• CredentialAccess:IAMUser/CompromisedCredentials: an access key identified as potentially compromised by Amazon threat intelligence and then used to call APIs in your account.
• UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS: credentials created for an EC2 instance used from an external IP address.
• Stealth:IAMUser/CloudTrailLoggingDisabled: logging turned off.

GuardDuty's remediation steps are to identify the IAM entity and the API call in the finding, review the entity's permissions with the Permission and Access Advisor tabs, then contact the user to confirm whether the activity was legitimate, covering the API, the time, and the source address. If you cannot confirm it was legitimate, treat the key and possibly the account as compromised. See the GuardDuty integration for sending findings into your log search.

If AWS Has Already Quarantined the User

AWS applies the AWSCompromisedKeyQuarantineV3 managed policy when an IAM user's credentials are compromised or exposed publicly. It denies a list of actions to limit unauthorized charges without touching existing resources, such as ec2:RunInstances, iam:CreateAccessKey, iam:CreateUser, iam:AttachUserPolicy, and lambda:CreateFunction. AWS's instruction is not to remove it and to follow the support case it opened.

One consequence: the list also denies cloudtrail:LookupEvents. If that user's own credentials run the lookup above, it will fail. Run the investigation from a separate administrator identity.

Temporary ASIA Keys

You cannot deactivate an ASIA key. These are short-lived STS credentials that cannot be viewed or managed in the console. The CloudTrail entry's sessionIssuer element shows which role or user requested the session, and that is the thing to fix: the role's trust policy, the instance that exposed its credentials, or the long-term key that was used to assume it.

Step 4: Rotate Cleanly

An IAM user can have at most two access keys, so rotation fits in the gap:

1. Create a second key (aws iam create-access-key --user-name Bob) if you deactivated the first and a workload needs credentials.
2. Move the workload to the new key from a secret store, not a file in the repo.
3. Confirm no calls still arrive on the old key with the CloudTrail query above.
4. Delete the old key: aws iam delete-access-key --user-name Bob --access-key-id AKIAIOSFODNN7EXAMPLE.

Then clean up what the attacker made. Delete unfamiliar users, keys, roles, and instances found in Step 2, and review the trust policies of roles. Prefer roles with temporary credentials over long-term keys for workloads.

Last, find how the key leaked. Search your repositories and build output, and read secrets in logs and leaked API key for the general playbook. The exposure detection guide covers continuous checks.

Searching CloudTrail and GuardDuty in Sazabi

Sazabi, an AI-native observability and security platform, connects to your AWS account and streams CloudTrail events from the trail's CloudWatch Logs group. Each event keeps CloudTrail's own JSON, so eventName, userIdentity, sourceIPAddress, and errorCode stay searchable, so you can search by access key. GuardDuty findings can be sent in through an Amazon EventBridge rule.