When AWS finds one of your access keys exposed, it attaches the AWSCompromisedKeyQuarantineV3 policy to the IAM user and notifies you. That policy is a deny list: it blocks a set of expensive actions, but the key stays active, and cleaning up after the leak is still your job. If your team treats quarantine as the incident being handled, this list is for you.
The gap isn't theoretical. On August 19, 2026, Truffle Security reported in its research on leaked corporate AWS keys that 929 of the live IAM users it found with leaked keys already carried an AWS quarantine policy, some of them applied years earlier. They still authenticated. AWS saw the leak, and nobody finished the job. We've worked a leaked-key incident from the inside, and here's what quarantine leaves for you to do.
1. It won't turn the key off. Quarantine is a deny list, not a kill switch. It subtracts a set of actions from whatever the key could already do. The key keeps authenticating. That's by design: AWS's policy reference says it aims to limit fraud charges without impacting existing resources. Your workloads keep running. So does the attacker.
2. It won't stop a pivot. The policy doesn't deny sts:AssumeRole. As Corey Quinn pointed out in The Register, a key that can assume another role gets that role's permissions, and the deny list doesn't follow it there. The policy also leaves ssm:SendCommand and ssm:StartSession open. If the key had those rights, the attacker can run commands on your EC2 instances.
3. It won't protect your other secrets. Reading Secrets Manager values, reading SSM parameters, and calling kms:Decrypt all stay allowed. A leaked key's real blast radius is every credential it can read. Scope your rotation to everything the key could reach, and start with those stored secrets.
4. It won't stop damage that isn't billing fraud. The deny list targets the expensive moves: new instances, new Lambda functions, Bedrock calls, S3 deletions. It doesn't deny ses:SendEmail, sns:Publish, cloudtrail:StopLogging, backup:DeleteRecoveryPoint, or cloudformation:DeleteStack. It even blocks the key from looking up CloudTrail events while leaving it free to stop CloudTrail logging. Read the policy JSON yourself and map it against the services your account actually uses.
5. It won't do your remediation. Someone still has to find every place the key is embedded. Someone has to rotate in an order that keeps production running. Someone has to prove what the attacker touched. We wrote up the first-24-hours order of operations for leaked API keys after doing that work, and none of it starts because a policy got attached.
Treat quarantine as a smoke alarm, not a sprinkler. If your account has IAM users with access keys older than your newest hire, run the audit before AWS runs it for you. Our AWS practice does this work, rotation plan included.