> ## Content Index
> Fetch the complete content index at: https://www.thecybersignal.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Corey Quinn Says AWS's Leaked-Key Quarantine Leaves Attackers Too Much Room
- URL: https://www.thecybersignal.com/register-corey-quinn-aws-leaked-credentials-quarantine-2026/
- Published: 2026-08-23T21:30:00.000Z
- Updated: 2026-08-24T02:58:32.000Z
- Description: AWS attaches a quarantine policy to keys it detects as leaked, but Corey Quinn argues in The Register that the deny-list still lets an attacker assume other roles, destroy audit logs, read secrets, and lock storage. Treat a leaked key as a full compromise.
- Author: Nicholas Robert
- Tags: Cloud Security, AWS Security, Vendor Accountability

When AWS detects one of your access keys leaking, it does not switch the key off. It attaches a restrictive managed policy called **AWSCompromisedKeyQuarantine** and leaves the credential live. In an [August 22, 2026 column for The Register](https://www.theregister.com/security/2026/08/22/aws-security-makes-an-inscrutable-choice-corey-quinn/5291446?ref=thecybersignal.com), Corey Quinn (the Duckbill Group "cloud economist" behind the *Last Week in AWS* newsletter) argues that this containment choice is not good enough. His headline claim is blunt: the quarantine deny-list blocks the obvious bill-running abuse while leaving an attacker enough room to gut the account from the inside.

For a defender, that reframes what a leaked-key alert means. AWS quarantining a credential is a speed bump, not containment, so a key you know has leaked should be treated as an active compromise and rotated, revoked, and investigated, not filed away as "AWS has it handled." That is the information this piece adds beyond the column itself: what the policy actually restricts, where Quinn says it falls short, and the order of operations a cloud team should run when a key gets out.

## What the Quarantine Policy Actually Does

AWS Security scans public sources for exposed credentials, and when it finds one, it programmatically attaches a quarantine policy to the offending IAM principal. The current version is [AWSCompromisedKeyQuarantineV3](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCompromisedKeyQuarantineV3.html?ref=thecybersignal.com), a managed policy that denies a specific list of actions. Crucially, it does not deactivate the key. AWS states the design goal directly: "The policy aims to limit the potential damage that may be caused by fraud-related activity leading to unauthorized charges, while not impacting the existing resources." In other words, the deny-list is tuned to stop fraud and runaway billing without breaking the customer's running workloads.

The column landed the day after [BleepingComputer reported](https://www.bleepingcomputer.com/news/security/hundreds-of-leaked-aws-keys-give-full-control-over-corporate-accounts/?ref=thecybersignal.com) on [Truffle Security research](https://trufflesecurity.com/blog/leaked-corporate-aws-keys-held-full-admin-rights?ref=thecybersignal.com) finding that hundreds of leaked AWS keys, many of them root or full-admin credentials, remain active and valid, some for years. (Exact totals vary by outlet, and the underlying dataset spans years of exposure, so treat any single count as approximate.) That backdrop is what makes the shape of the quarantine policy matter: if leaked keys stay live, the only thing standing between an attacker and the account is the deny-list.

## Quinn's Case: a Deny-List Is the Wrong Shape

Quinn's argument is that an enumerated deny-list is the wrong tool for the job, because security teams have to anticipate every dangerous action, and the list has gaps. "AWS' considered position on this is wrong," he writes. Deactivating a leaked key would break workloads that depend on it, he acknowledges, "but I promise you, as a bad actor, I can do far worse to you."

He then walks through actions the quarantine policy leaves open. By his account, a quarantined credential can still call **sts:AssumeRole** to assume any other role in the account, which he says renders "the entire restriction list potentially moot." It can call **ssm:SendCommand** and **ssm:StartSession** to run commands as root on EC2 instances, inheriting that instance role's permissions. It can call **cloudtrail:StopLogging** and **cloudtrail:DeleteTrail** to turn off logging and delete the audit trail. And in a detail Quinn dwells on, **s3:PutObject** stays allowed alongside **s3:PutObjectLockConfiguration** and **s3:PutObjectRetention**, so an attacker can fill a bucket and then apply Object Lock in COMPLIANCE mode with retention set out to the year 2126\. That retention "can't be shortened or removed by anyone, including the account root and AWS Support," he writes. "The only way to remove it is to delete the entire AWS account."

The list goes further: **secretsmanager:GetSecretValue** and **kms:Decrypt** stay open ("your secrets are now my secrets"), backup and snapshot deletion via **backup:DeleteBackupVault** and **rds:DeleteDBSnapshot** are permitted, **cloudformation:DeleteStack** goes unmentioned, and **ses:SendEmail** and **sns:Publish** remain usable for spam and fraudulent messaging. Quinn is explicit that this is not exhaustive: it is "just a few things that occurred to me over the course of about an hour."

| ● AWS Leaked-Key Quarantine: Blocked vs. Still Allowed What the AWSCompromisedKeyQuarantine policy stops, and what Corey Quinn says it leaves open.                                                                                                                                                                                                                                                                                                                                              |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| What The Policy Blocks The deny-list targets fraud and cost abuse: buying savings plans, reading S3 object data, deleting S3 objects, modifying Lambda functions, and reading the CloudTrail audit log, among others. The key itself stays active.                                                                                                                                                                                                                                               |
| What Quinn Says It Still Allows sts:AssumeRole to assume any other role (his words: the restriction list becomes "potentially moot"). ssm:SendCommand and ssm:StartSession to run commands as root on EC2\. cloudtrail:StopLogging and DeleteTrail to erase the audit trail. s3:PutObject plus Object Lock in COMPLIANCE mode to fill and lock storage until 2126\. secretsmanager:GetSecretValue and kms:Decrypt to read secrets. backup and snapshot deletion, and cloudformation:DeleteStack. |
| Diagram: The CyberSignal. Actions as enumerated by Corey Quinn in The Register (August 22, 2026), referencing the AWSCompromisedKeyQuarantine managed policy. Defender-oriented summary, not a reproduction of any exploit.                                                                                                                                                                                                                                                                      |

## AWS's Side, and What Is Not Yet Confirmed

The case for AWS's approach is the one AWS itself makes in the policy documentation: deactivating a credential outright breaks every workload that relies on it, and until the customer rotates the key those workloads keep failing. Quinn concedes the point. The disagreement is about whether "don't break the customer" should outweigh "don't leave the attacker a path to destroy the account," and that is a genuine engineering trade-off, not a settled fact.

Several things are worth flagging as unconfirmed. AWS has not, as far as I can find, publicly responded to Quinn's column, so there is no AWS rebuttal or acknowledgment to weigh against it. Whether AWS plans to change the quarantine flow is Quinn's own prediction, not a company statement. He writes that AWS "is almost certainly going to change this," then adds the line that gives the piece its edge: "My question for them is simply, 'how big of a customer incident needs to happen before you do?'" There are also no named affected customers tied to this specific policy gap, and the leaked-key volumes come from third-party research rather than AWS disclosure.

None of that blunts the defender takeaway. Stolen and leaked cloud credentials have driven some of the year's largest intrusions, from the [Snowflake account-takeover campaign that hit 165 organizations](https://www.thecybersignal.com/snowflake-hacker-connor-moucka-guilty-plea-165-orgs-100m-2026/) to the alleged [theft of millions of records from Fortune 500 Azure tenants](https://www.thecybersignal.com/fortune-500-azure-mcdonalds-vodafone-tcs-kyndryl-2026/). The mechanism Quinn is describing sits upstream of exactly that kind of incident.

## What This Means for AWS Customers

The practical lesson is that quarantine is AWS's fraud brake, not your incident response. If a key leaks, the burden of containment is still yours. A concrete checklist:

- **Monitor for leaked credentials continuously.** Run secret scanners in CI and pre-commit (git-secrets, trufflehog, or GitHub push protection) so a key never reaches a public repo in the first place, and subscribe to exposure feeds so you learn of a leak before an attacker does.
- **Stop minting long-lived keys.** Prefer IAM roles and short-lived STS credentials, and use OIDC or workload identity federation for CI and third-party integrations. A credential that expires in an hour is a far smaller quarantine problem than a root access key that has never been rotated.
- **Enforce least privilege, especially on sts:AssumeRole.** Quinn's central point is that role assumption can moot the deny-list, so scope which principals can assume which roles, and audit trust policies that let a low-value key pivot to a high-value one.
- **Understand what the quarantine policy does and does not restrict.** Read AWSCompromisedKeyQuarantineV3 for yourself. Do not assume a quarantined key is a contained key: it can still touch SSM, CloudTrail, Secrets Manager, S3 Object Lock, and your backups.
- **Rotate and investigate, do not just quarantine.** Deactivate or delete the leaked key, then work the blast radius: review CloudTrail for assumed roles and new resources, check for Object Lock or retention changes on buckets, confirm backups and snapshots are intact, and verify logging was never stopped.

**My read:** This is my assessment, not a reported fact. Quinn is right that a deny-list is the wrong shape for a containment control, because it forces AWS to predict every abuse in advance and quietly fails the moment an attacker finds one it missed. The COMPLIANCE-mode Object Lock path is the detail that should worry defenders most, since it is the rare cloud action that is genuinely irreversible short of deleting the account. But I would not read the column as proof AWS is negligent. It is a reasonable design pulled toward the wrong side of a real trade-off, and the fix (deny by default and allow-list the safe actions, or actually disable the key and tell the customer loudly) is AWS's to make. Until it does, the only safe assumption is that quarantine buys you minutes, not safety, and your runbook has to do the rest.

### Primary Documents

- [The Register: AWS Security makes an inscrutable choice (Corey Quinn, August 22, 2026)](https://www.theregister.com/security/2026/08/22/aws-security-makes-an-inscrutable-choice-corey-quinn/5291446?ref=thecybersignal.com)
- [AWS: AWSCompromisedKeyQuarantineV3 managed policy reference](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCompromisedKeyQuarantineV3.html?ref=thecybersignal.com)
- [BleepingComputer: Hundreds of leaked AWS keys give full control over corporate accounts](https://www.bleepingcomputer.com/news/security/hundreds-of-leaked-aws-keys-give-full-control-over-corporate-accounts/?ref=thecybersignal.com)
- [Truffle Security: Leaked corporate AWS keys held full admin rights](https://trufflesecurity.com/blog/leaked-corporate-aws-keys-held-full-admin-rights?ref=thecybersignal.com)