AWS quarantine leaves exposed keys active and privileged

At a glance

What this is: Truffle Security shows that AWS quarantine policies do not revoke exposed keys and can leave high-risk permissions in place, creating a gap between containment and actual credential invalidation.

Why it matters: IAM and cloud security teams need to treat leaked key handling as a revocation problem, because partial deny lists can still leave secrets, compute, data, and cross-role access reachable.

By the numbers:

• The article says 894 of the 929 quarantined keys still had dangerous grants outside AWS quarantine deny lists.
• Truffle Security reports that 738 keys had an older quarantine policy listed without V3.
• The dataset included 929 keys that still authenticated and had quarantine listed on their IAM users.
• Creation dates were available for 926 keys, and their median age was 3.6 years.

👉 Read Truffle Security's analysis of AWS quarantine gaps and exposed key revocation

Context

AWS key quarantine is a partial restriction model, not a revocation model. When a leaked key remains attached to an IAM user, the account can still retain rights that sit outside the quarantine deny list, which means the identity can stay operational even after detection.

For identity teams, the issue is not whether the leaked key is noisy or visible, but whether it has actually been invalidated. Non-Human Identity governance has to treat exposed cloud keys as credentials with lifecycle obligations, not just as access events that can be softened with a policy attachment.

The practical consequence is that a quarantined credential may still read secrets, run commands, or reach other roles if the surrounding permissions and trust relationships remain intact. That makes AWS key handling an IAM and NHI governance problem, not only a cloud configuration problem.

Key questions

Q: What breaks when AWS quarantine is used instead of actual key revocation?

A: Quarantine can leave the credential active, so the leaked key may still authenticate and use any permissions that sit outside the deny list. That means the organisation may believe the incident is contained while the identity remains operational. The failure is lifecycle, not visibility: the access path is narrowed, but the identity is not ended.

Q: Why do leaked cloud keys still create risk after a deny policy is attached?

A: Because effective access in AWS is determined by more than one policy layer. If a permission is not explicitly denied, an existing grant, trust relationship, or resource policy can still make the action succeed. The risk persists wherever the deny list does not fully cover the identity's reachable permissions.

Q: How should teams prioritise revocation versus partial containment for exposed AWS keys?

A: Revocation should come first, because containment only reduces the set of usable actions while revocation ends the credential's utility. If a leaked key is still valid, the attacker can keep probing for surviving permissions, alternate policy paths, or cross-role access. The safest sequence is contain briefly, then invalidate decisively.

Q: What should security teams check before assuming a quarantined key is harmless?

A: They should verify the exact policy version attached, the remaining grants on the IAM user, and any role trust or resource-based permission that still permits use. A quarantined key can still reach data or commands if another control layer allows it. Harmlessness has to be proven, not inferred from the quarantine label.

Technical breakdown

Why quarantine is not the same as key revocation

Quarantine in this context is a deny policy attached to the IAM user that owns the key. That changes which API actions are blocked, but it does not delete the credential, remove existing grants, or invalidate sessions that may already be possible through other paths. The distinction matters because revocation ends the identity's utility, while quarantine only narrows it. If the user still has permissions outside the deny list, the key can remain operational for those actions. Practical implication: treat quarantine as a containment layer, not as proof that a leaked key is no longer usable.

Practical implication: Use quarantine only as an interim containment step and verify that the credential is actually revoked.

How residual permissions preserve dangerous access paths

The article shows that quarantine leaves uncovered actions such as secret reads, command execution, and some data operations. That happens because AWS evaluates the request against multiple layers: the identity policy, any explicit denies, resource-based policies, trust policies, and service-specific controls. If the quarantine policy does not deny an action, an existing grant can still allow it. This is why a leaked key can still retrieve secrets, invoke Run Command, or assume another role even after quarantine is attached. Practical implication: map every uncovered action to its effective permission path before assuming the leak is contained. See the AWS IAM Policies and Roles Guide.

Practical implication: Trace every surviving permission path, including role trust and resource policies, before declaring the incident contained.

Why older quarantine versions create uneven protection

AWS has issued three separate quarantine policies over time, and the article shows that the original, V2, and V3 do not provide the same restrictions. A key with an older version can miss later deny rules even if it is technically quarantined. That creates version skew inside the same response pattern, which means two leaked keys can appear equally handled while one still preserves broader access than the other. Practical implication: compare the exact policy version attached to each exposed key instead of assuming the quarantine label means uniform protection.

Practical implication: Audit the exact quarantine policy version on each exposed key and normalize it to the current restriction set.

Threat narrative

Attacker objective: The attacker wants to convert a leaked AWS key into broader cloud access, data exposure, or operational disruption before the organisation fully revokes it.

1. Entry begins when an exposed AWS access key is discovered in a public repository or other public source and remains valid enough to authenticate.
2. Credential abuse follows when the attacker uses the quarantined key to reach actions that sit outside the deny list, including secret access, command execution, or cross-role movement.
3. Escalation occurs if the attacker assumes a trusted role, modifies policy versions, or reaches stored data and backups that quarantine does not fully block.
4. Impact is the theft, manipulation, or disruption of cloud resources even though the key was supposedly quarantined.

Breaches seen in the wild

• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.
• Amazon AWS Hacked Accounts Crypto-Mining: Compromised IAM credentials across multiple AWS accounts fuel large-scale crypto-mining campaign.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Quarantine without revocation is a control illusion: The article shows that AWS can block selected actions while leaving the underlying credential alive and still useful. That is not the same as ending exposure, because the identity remains capable wherever the deny list does not reach. The practitioner lesson is that partial restriction can reduce noise without reducing the real attack surface.

Residual permission paths are the real governance gap: The dangerous issue is not the quarantine label, but the surviving grants attached to the same identity. Those grants can still enable secret retrieval, command execution, role assumption, and data access if surrounding controls allow it. NHI governance has to account for effective access, not just policy intent.

Policy version drift creates uneven trust boundaries: AWS quarantine policies are not uniform across versions, and older attachments can miss newer restrictions. That means two leaked keys under the same response umbrella may have very different blast radii. The implication is that governance teams must track the exact policy version as part of identity lifecycle control, not merely the fact that quarantine exists.

Credential invalidation debt: The article exposes a structural failure in many response models: they assume containment can substitute for revocation. It cannot, because the credential stays active until the lifecycle is explicitly closed. Practitioner teams need to recognise that exposed keys remain an active identity problem until the trust relationship is fully ended.

Assume-role paths widen the blast radius beyond the leaked key itself: A quarantined IAM user can still reach other identities if trust relationships remain in place. That means the initial key is only the first identity layer in the compromise chain, not the boundary of the incident. The practitioner takeaway is that third-party and cross-role trust must be governed as part of NHI exposure response.

From our research library:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to the State of Secrets Sprawl 2026.
• Read next: Ultimate Guide to NHIs — What are Non-Human Identities

What this signals

Credential invalidation, not policy attachment, is the control that matters: Teams that rely on quarantine-style containment are still assuming that partial denial is equivalent to revocation. In practice, exposed keys can remain viable long enough to be used against secrets, data, or cross-role trust, so the control objective has to shift to ending identity utility rather than merely reducing it.

A programme that can identify leaked credentials but cannot invalidate them quickly enough has a governance gap, not a detection gap. That gap becomes more visible as cloud access paths widen across roles, snapshots, backups, and server control planes.

The article's scale matters because it shows that response quality, not just exposure detection, determines whether a secret remains exploitable.

For practitioners

• Revoke exposed keys, do not just quarantine them Treat quarantine as temporary containment and immediately remove the credential from active use, including any linked sessions, trust paths, and dependent applications.
• Inventory the surviving permissions on each leaked key Check the exact grants that remain outside the deny list, including secret reads, command execution, data access, and any assume-role path that can extend reach.
• Standardise on the current quarantine policy version Compare all quarantined keys against the newest deny rules and reapply policy where older versions leave gaps in the restriction set.
• Test whether resource policies still permit the action Validate the complete request path, because an explicit deny in quarantine does not matter if another attached policy or trust relationship still allows the operation.

Key takeaways

• AWS quarantine policies can narrow access without actually ending a leaked key's usefulness.
• The article shows that hundreds of quarantined keys still retained dangerous grants and long-lived exposure.
• Practitioners should treat exposed AWS keys as revocation events, not containment-only events.

Related NHI Mgmt Group resources: Ultimate Guide to NHIs: What are Non-Human Identities · AWS IAM Policies and Roles Guide · Cloud Workload Identity Guide

Key terms

• AWS key quarantine: A partial containment policy that attaches deny rules to an IAM user while leaving the access key itself active. It reduces what the credential can do, but it does not invalidate the key or necessarily remove other permissions already attached to the identity.
• Credential Revocation: Credential revocation is the process of disabling a secret, token, or key so it can no longer authenticate or authorize action. It is the operational half of detection, because exposed credentials remain dangerous until they are invalidated and replaced across every dependent system.
• Residual permission path: An access route that remains usable after a control is applied because another policy layer, trust relationship, or resource permission still allows the action. For NHI governance, residual paths are why containment labels can overstate real security.
• Long-Lived Secret: A long-lived secret is a credential, token, API key, or certificate that remains valid for an extended period without frequent renewal. In NHI environments, it creates durable exposure because one leaked secret can keep granting access long after the original use case has changed.

What's in the full report

Truffle Security's full post covers the operational detail this analysis intentionally leaves for the source:

• The full list of uncovered AWS actions that quarantine leaves available, including secret access, command execution, and data operations.
• The policy-version comparison showing how the original, V2, and V3 quarantine definitions differ in practice.
• The dataset methodology behind the 929 quarantined keys and how the authors matched policy names to AWS definitions.
• The deeper examples of how S3, DynamoDB, RDS snapshots, Lambda packages, and role trust paths remain reachable.

👉 Truffle Security's full post details the uncovered AWS actions, policy version gaps, and surviving access paths.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.