AWS exposed credentials and AWSCompromisedKeyQuarantineV3
What you'll see on the IAM userPolicy attached: AWSCompromisedKeyQuarantineV3
"Do NOT remove this policy. Instead, please follow the instructions specified
in the support case created for you regarding this event."
# calls to denied actions then fail with AccessDeniedAWS found your access key in public and limited what it can do. Leave the policy in place, deactivate the key, create a replacement, and check every region for anything you didn't launch.
Why it happens
AWS attaches the managed policy AWSCompromisedKeyQuarantineV3 to an IAM user whose credentials were exposed. It denies high-risk actions (launching EC2 instances, IAM user and key changes, Lambda creation, S3 reads and deletes, Bedrock model calls, and more) to limit fraud while leaving your existing resources alone. AWS also opens a support case.
The key itself keeps existing until you deactivate it, and whoever had it may have created more users, keys or resources. That is why AWS's guidance has you check CloudTrail and every region, not just the one key.
Fix it by hand
- Leave the quarantine policy attached and open the case in the AWS Support Center. Follow its instructions.
- Deactivate the exposed key. In the IAM console choose Users, the user, then the Security credentials tab. Under Access keys, choose Actions, then Deactivate. Or:
aws iam update-access-key --access-key-id AKIA... --status Inactive --user-name USER - Replace it. Prefer temporary credentials (IAM roles) over a new long-term key. If you need a key, create one on the same tab and copy the secret once; it is shown only at creation. Update every host, CI secret and
~/.aws/credentials, and confirm services work. - Delete the old key once nothing depends on it:
aws iam delete-access-key --access-key-id AKIA... --user-name USER - Check for damage. In CloudTrail Event history, look for new users, access keys, roles or policies. Check every region for EC2 instances, Lambda functions and other resources you didn't create. Review Cost Explorer. Generate an IAM credential report to audit all keys.
- Reply to the support case confirming what you did.
Stop it happening again
- Use IAM roles and temporary credentials instead of long-term access keys wherever you can.
- Give each key only the permissions it needs, never admin.
- Never put AWS keys in browser code. Call AWS from your backend.
- Turn on MFA for the root user, and set an AWS budget alert so unexpected spend reaches you fast.
Key Leaked $7
Key Leaked recognises AWS access keys in files, history and bundles, gives these revoke-and-replace steps in order (with sources and dates), and shows every other place the same key lives.
- Finds every secret in your files, every commit on every branch, and the JavaScript you ship to browsers.
- Gives exact revoke-and-replace steps for 19 providers, and never prints your full secrets.
- Verdict first. Every finding shows the file and line, what it breaks, and the fix as a diff that is applied only with your OK.
Key Leaked: how it works, with examples · Install guide
Works with Claude Code, Claude.ai, Cursor, Codex and other agents that read SKILL.md files. No installs, no accounts, works offline. No-questions refund.