In a test described by Unit 42 on September 21, AWS restricted a publicly leaked access key within 10 seconds—before the warning email arrived. The revealing part is what that fast response did: it attached a policy to limit selected actions, leaving the account owner responsible for replacing the exposed credential and investigating its use.
The experiment took place on December 19, 2025; the newly published report is a measured account of an existing safeguard, not a new AWS feature or a confirmed victim breach. For developers and small teams whose deployments rely on long-lived keys, the distinction matters: quarantine is a reason to start responding, not evidence that the incident is over.
The warning came before the leak—and the restriction before the email
GitHub push protection first detected the test credentials. The researchers deliberately allowed the public commit. Ten seconds after exposure, CloudTrail recorded the attachment of AWSCompromisedKeyQuarantineV3. GitHub’s email followed one second later, an AWS Health alert after another second, and a Support case 54 seconds after the commit.
Those timings describe one controlled test. They are not a deadline AWS promises for every leak, especially one outside a monitored public repository. Deleting a committed secret is also a different operation from revoking it: a copy obtained while it was public can outlive the file.
The log tells responders where to look
Unit 42’s published CloudTrail example names TestUser in the identity fields, while also showing AWS Internal markers. A responder should not conclude from the username alone that the user manually quarantined the key.
The useful correlation is eventName: AttachUserPolicy, eventSource: iam.amazonaws.com, and the quarantine policy’s ARN in requestParameters.policyArn. Route that signal to whoever can investigate cloud credentials, alongside AWS Health and Support notifications. A warning reaching an engineering mailbox is not the same as someone taking ownership of the response.
What the quarantine changes
AWS describes the policy as a way to limit fraud-related damage and unauthorized charges while preserving existing resources. It applies explicit denials to selected operations. An explicit denial overrides an allow, but the policy is not a blanket denial of every AWS action.
The current AWS reference lists the policy’s default version as v3, edited March 16, 2026—after the experiment. Among its restrictions are creating access keys, launching EC2 instances, reading S3 objects, and invoking Bedrock models. Effective access still depends on the account’s other policies and permissions; an operation absent from this list is not automatically permitted. The policy also does not itself invalidate the exposed secret.
This makes quarantine different from replacing a credential. A restriction changes what an identity may do. Revoking the leaked key prevents further authentication with that key. Neither operation, by itself, establishes what happened before containment.
Keep the restriction and finish the response
AWS’s policy documentation tells owners to keep the quarantine in place and follow the associated Support case. From a trusted administrative identity, replace the exposed key in legitimate applications, deactivate the old key, verify the replacement works, and delete the old credential. The quarantined identity itself is restricted from key-management operations.
Review CloudTrail activity, newly created users and credentials, unfamiliar resources, and unexpected charges. If temporary role credentials are involved, address their sessions separately. AWS’s account-compromise guidance provides the response sequence; the quarantine notification is its starting evidence, not a clean bill of health.
Credentials can escape through more than a public commit: fake developer-tool downloads can steal cloud secrets. Understanding the exposure route helps prevent a replacement key from following the same path.
References
- Margaret Kelley. “From Exposure to Lockdown: How AWS Neutralizes Compromised IAM Credentials through Managed Policies.” Unit 42, September 21, 2026. Research report and test evidence.
- Amazon Web Services. “AWSCompromisedKeyQuarantineV3.” AWS Managed Policy Reference, edited March 16, 2026; accessed September 22, 2026. Current policy and restrictions.
- Amazon Web Services. “What can I do if I notice unauthorized activity in my AWS account?” AWS re:Post, accessed September 22, 2026. Account-compromise response guidance.
