If you push an AWS access key to a public repository, there is a decent chance Amazon knows before you do. Palo Alto Networks' Unit 42 published research on September 21 documenting how AWS detects exposed IAM credentials and what it does about them. In their test, a quarantine policy landed on the affected user within ten seconds of exposure.
That is genuinely impressive engineering, and it is also the detail most likely to be misread. The quarantine is a deny list attached to a still-valid credential. It buys you time. It does not end the incident, and treating it as though it does is the actual risk in this story.
What is confirmed
Unit 42 describes the detection path as GitHub's secret scanning partner programme—a scheme dating to 2018 that AWS joined in 2020. GitHub scans public repositories and npm packages for recognisable credential patterns and notifies the issuing provider when it finds a match.
On notification, AWS attaches a managed policy named AWSCompromisedKeyQuarantineV3 to the affected IAM user. Unit 42 traces the lineage: V1 was released on August 11, 2020 and V2 on April 21, 2021. The current version denies more than 60 permissions across 17 services through explicit deny statements, with examples including iam:CreateUser, iam:CreateRole, ec2:RunInstances, lambda:CreateFunction, s3:DeleteObject and bedrock:InvokeModel.
In Unit 42's test scenario the policy was attached within ten seconds of the credential being exposed. They also give defenders a concrete detection: a AttachUserPolicy event in CloudTrail, sourced from IAM, whose request parameters reference the quarantine policy ARN. If you see that event and did not make the change yourself, AWS is telling you something.
The sentence that matters
Unit 42 is explicit that the policy works by enumeration: anything not listed in the deny statements remains permitted. That is the whole shape of the control, and it has two consequences worth stating separately.
First, the policy is weighted towards stopping an attacker from building and destroying—creating principals, launching compute, deploying functions, deleting objects. Those are the actions that cost money, establish persistence or cause damage, and blocking them is the right first move for an automated system acting without context.
Second, and this is the part to brief your team on: a deny list cannot enumerate every way to read something. For an organisation whose exposure is data rather than compute spend, the actions you would most want blocked are the hardest for a generic policy to cover safely, because blocking reads would break the legitimate workloads of a customer who merely made a mistake. Quarantine is AWS protecting the blast radius it can see. The data behind that key is your problem.
And the key itself is still valid. Quarantine attaches a restriction to the user; it does not deactivate the credential, and it does not tell the attacker to go away.
What remains unknown
The ten-second figure comes from a single controlled test, timestamped December 19, 2025 at 18:50:05 UTC. It is a demonstration that the pipeline can be fast, not a service-level guarantee, and it should not be planned around. Unit 42 publishes no statistics on how often quarantine is triggered in the wild or how often it arrives before an attacker does.
It is also worth being clear about scope: this detection path depends on the credential appearing somewhere GitHub scans. A key leaked into a private repository, a container image, a build log, a support ticket, a screenshot or a paste site is outside it. The absence of a quarantine notice is not evidence that a key is safe.
What to do when quarantine fires
- Deactivate and delete the access key yourself, immediately. Do not wait, and do not treat the quarantine policy as the remediation. The quarantine restricts; only deletion revokes.
- Establish what the key did before the restriction landed. Pull CloudTrail for that access key ID from its creation, not just from the exposure. Look for reads and enumeration, not only writes:
List*,Get*andDescribe*calls are how an attacker works out what they have. - Separate the probe from the attacker. Unit 42 notes that a
GetCallerIdentitycall from GitHub's address space is part of the validation flow. A similar call from anywhere else is somebody checking their prize. - Find the leak, then check for siblings. A key in a public repository is rarely alone. Scan the full history of that repository and the others in the same account for further credentials, and remember that deleting a file does not remove it from the clone.
- Assume anything that key could read was read unless CloudTrail shows otherwise. Then work through the downstream consequences: what those objects contained, whose data it was, and whether you have a notification obligation.
- Remove the reason a long-lived key existed. This is the only step that makes the next incident smaller. IAM Roles Anywhere, OIDC federation to your CI provider, instance roles and short-lived session credentials all remove the artefact that can be committed in the first place.
The uncomfortable question this raises
If a third party's scanner is what tells you a credential leaked, then your own detection did not fire. That is worth sitting with. Pre-commit hooks and CI secret scanning that fails the build are cheap; discovering the problem from a provider notification means the credential was already public.
The same logic applies one step further out. Keys reach repositories because someone needed to give a credential to someone else and the repository was the convenient place to put it. Fix the convenient place and the commits stop happening.
Where Secretus fits—and where it does not
Secretus can reduce plaintext exposure when an authorized person must hand over a small, temporary value—a replacement access key, a short-lived credential during an investigation—through a channel that does not retain it the way chat, tickets and repositories do.
It is not a secrets manager, not a scanner, and has no view of AWS. It cannot deactivate a key, cannot read CloudTrail, cannot tell you whether a quarantine policy was attached, and will not find what you have already published. Deletion, log review and moving off long-lived keys are the substance here.