Cloud teams usually treat leaked access keys as a prevention problem: do not commit secrets, block the push, rotate keys, and move on. Unit 42's new research on AWS IAM credential exposure is a useful reminder that the response side matters just as much.
According to Unit 42, AWS can automatically attach the AWSCompromisedKeyQuarantine managed policy when it is notified that an IAM access key has been publicly exposed, including through GitHub's secret-scanning partner program. In Unit 42's test, the quarantine policy was attached within seconds of a public GitHub exposure.
That speed is good news. It also creates an operational question: would your team know the quarantine happened, understand what it blocked, and have a clean runbook for replacing the credential without breaking production?
What Unit 42 reported
Unit 42 reviewed how AWS responds to exposed long-term IAM access keys, with a focus on the AWSCompromisedKeyQuarantine managed policy and how that policy has evolved over time. The research also walks through the GitHub secret-scanning integration that can notify service providers when secrets appear in public repositories.
The important finding for defenders is the timeline. During Unit 42's exposure test, AWS attached the quarantine policy rapidly after the key appeared in a public GitHub repository. GitHub generated its own notification shortly afterward, and AWS generated Health and Support notifications inside the affected account.
The quarantine policy is designed to limit common abuse paths after a credential is exposed. It does not replace incident response. It buys time, reduces likely blast radius, and creates a signal that defenders should immediately investigate.
Why this matters
Long-term IAM access keys are still one of the easiest cloud footholds to abuse. They get copied into code, stored in local environment files, pasted into support tickets, embedded in CI jobs, and forgotten in developer workstations. If the IAM user behind the key has broad permissions, a single leak can turn into data theft, persistence, resource abuse, or destructive activity.
For SMBs and government contractors, the risk is bigger than a surprise cloud bill. A leaked cloud key can expose customer data, contract data, build artifacts, backups, email archives, or controlled unclassified information. It can also create compliance and reporting problems if the organization cannot reconstruct what happened quickly.
The useful lesson from Unit 42's research is not "AWS will fix this for you." The lesson is that cloud providers may take protective action before your team even sees the alert. Your monitoring and response process needs to recognize that provider-driven action as an incident trigger.
What defenders should do
- Treat quarantine attachment as an incident. If AWSCompromisedKeyQuarantine appears on an IAM user, assume the credential was exposed and begin containment, review, and rotation.
- Alert on managed-policy attachment events. Monitor CloudTrail for policy attachment activity involving AWSCompromisedKeyQuarantine and related support or health notifications.
- Rotate the key, do not just remove the policy. The exposed access key should be disabled and replaced only after confirming where it was used and what depends on it.
- Map key ownership before a crisis. Every long-term access key should have an owner, purpose, workload, last-used review, and documented rotation path.
- Prefer temporary credentials. Use roles, federation, workload identity, OIDC for CI/CD, and short-lived tokens wherever possible instead of static user keys.
- Enable secret scanning where code lives. Public scanning helps, but private repositories, internal Git platforms, CI variables, and developer machines also need coverage.
- Search beyond GitHub. Environment files, container images, deployment bundles, ticket attachments, chat logs, and backup exports can all leak credentials.
- Review CloudTrail for use before and after exposure. Look for unusual regions, new principals, access denied spikes, reconnaissance calls, storage enumeration, and resource creation.
Hunting and response checklist
If a leaked AWS key is suspected, defenders should move quickly but avoid blind cleanup that destroys evidence. A practical first pass:
- Identify the IAM user and access key ID involved.
- Check when the key was created, last used, and from which regions or services.
- Review CloudTrail events tied to the principal before and after the exposure window.
- Disable the exposed access key, then replace it through the documented application owner path.
- Inspect recent changes to IAM, S3, EC2, Lambda, Secrets Manager, STS, CloudFormation, and billing-related services.
- Confirm whether the key existed in public code, private code, local files, CI logs, artifacts, or container images.
- Remove the secret from the source and rotate any downstream credentials that may have been accessible.
- Document the timeline, owner, impact assessment, and corrective actions.
Bulwark Black assessment
Provider-side quarantine is a strong safety net, but it is not a security program. It is a signal that your secret-management process failed somewhere and that your cloud response process now matters.
The mature posture is straightforward: reduce static keys, constrain the permissions that remain, scan aggressively, alert on quarantine and key-use anomalies, and maintain a tested rotation runbook. The organizations that handle this well will not be the ones with zero leaked secrets. They will be the ones that can detect, contain, rotate, and prove impact quickly.
For government contractors, that proof matters. When cloud credentials touch contract systems or sensitive data, evidence of disciplined access control, logging, incident handling, and corrective action is part of the security story.