AWS Security makes an inscrutable choice
AWS has come under fire from cloud commentator Corey Quinn after a Truffle Security report found hundreds of leaked AWS root keys remain active and valid, exposed via public GitHub repositories. Rather than disabling compromised credentials outright, AWS applies a "Quarantine Policy" that blocks a limited set of actions to avoid disrupting legitimate customer workloads, but Quinn argues this half-measure leaves attackers with more than enough access to cause serious harm.
Quinn details how the quarantine policy fails to close off dangerous permissions, including full control over RDS databases, the ability to run root commands on EC2 via SSM, and using sts:AssumeRole to bypass restrictions entirely by assuming other roles. Attackers could also disable CloudTrail logging, send spam or fraudulent texts via SES and SNS, flood S3 buckets with data and lock them using COMPLIANCE-mode Object Lock retention (removable only by deleting the whole AWS account), and read secrets via Secrets Manager, SSM Parameter Store and KMS decryption. Quinn contends AWS's stated aim of not breaking customer environments is misguided given the scale of damage still possible.
- Truffle Security found hundreds of leaked AWS root keys still active
- AWS's quarantine policy blocks some actions but leaves major gaps
- Attackers can still assume roles, delete logs, lock buckets, steal secrets
New here? Start with this
Amazon Web Services (AWS) provides rented computing, storage and other online services to organisations. An AWS root key is a powerful credential tied to an account; if it is exposed publicly, someone else may be able to use it to access or change resources. GitHub is a website where people publish and share code, and secrets can sometimes be accidentally included in public repositories.
AWS can restrict a key it believes has been exposed, while leaving it active to avoid interrupting legitimate services that rely on it. Security researchers examine whether those restrictions prevent misuse, and cloud commentator Corey Quinn has criticised the limits of AWS’s approach. The issue matters because a stolen key may affect databases, stored information, account settings and services used by customers.
Both sides, in good faith
The strongest fair case each way — we don't pick a winner.
The case for
AWS's quarantine policy attempts to balance critical security concerns with operational realities by limiting dangerous actions whilst preserving service continuity. Immediately disabling all compromised root keys could devastate legitimate customers unaware of exposure; the quarantine approach reduces immediate attack surface and provides time for targeted remediation. This reflects the difficult reality that security does not exist in isolation from the substantial business impact of widespread service disruption.
The case against
The quarantine policy is fundamentally inadequate because exposed root keys retain access to catastrophic attacks—full RDS control, EC2 command execution, S3 destruction, CloudTrail disabling, and account assumption—that can obliterate customer environments. Security must take absolute priority; customers would reasonably prefer temporary service disruption to potential total account compromise. A partially-restricted compromised credential provides insufficient protection, and AWS should prioritise customer security over convenient operational continuity.