AWS attached the AWSCompromisedKeyQuarantineV3 managed policy within 10 seconds of an access key being pushed to a public GitHub repository during a controlled test.
How AWS automatically quarantines exposed IAM credentials
AWS runs automated processes to secure long-term IAM access keys that are reported as exposed. The service attaches an AWS-managed policy named AWSCompromisedKeyQuarantine to the IAM user associated with the exposed key rather than immediately disabling the key. According to the V3 managed policy description, the policy “Denies access to certain actions, applied by AWS in the event that an IAM user's credentials have been compromised or exposed publicly. 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. Do NOT remove this policy. Instead, please follow the instructions specified in the support case created for you regarding this event.”
The practical effect: AWS attaches a Deny-based managed policy that blocks specific actions. In IAM evaluation logic an explicit Deny in such a policy overrides any explicit Allow the user might have, so attachment of the quarantine policy can prevent misuse without modifying the user’s original permissions.
Real-world timeline: a public GitHub push and the AWS response
Palo Alto Networks tested the process by creating a new IAM user, generating an access key, and pushing that key to a public GitHub repository. Key timestamps (UTC) from the CloudTrail record in the test were:
- Dec. 19, 2025 17:28:39 — CreateUser (IAM user TestUser)
- Dec. 19, 2025 17:29:44 — CreateAccessKey for TestUser
- Dec. 19, 2025 17:34:23 — GetCallerIdentity test using the new key
- Dec. 19, 2025 18:50:05 — Access key and secret pushed to public GitHub repo
- Dec. 19, 2025 18:50:15 — CloudTrail shows AttachUserPolicy attaching AWSCompromisedKeyQuarantineV3
- Dec. 19, 2025 18:50:16 — GitHub sends an email notification about the detected secret
- Dec. 19, 2025 18:50:17 — AWS Health alert (Risk IAM quarantine) appears in the console (no CloudTrail event)
- Dec. 19, 2025 18:50:26 — AWS email notification mirrored in a support ticket created in the account
Notably, the AttachUserPolicy event is recorded in CloudTrail with the PolicyArn in requestParameters; by contrast, the Health alert and Support case creations in this test did not generate CloudTrail events. CloudTrail records management events by default for 90 days, and these AttachUserPolicy events are therefore a reliable log source for early detection.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildHow the managed policy evolved — V1 to V3
AWS introduced AWSCompromisedKeyQuarantine on Aug. 11, 2020, released V2 on April 21, 2021, and published V3 on Aug. 21, 2024. The earliest version focused on limiting 28 actions across five services. V2 expanded the Deny list to include Amazon S3 (adding 11 S3 permissions) and 16 additional permissions across the original services; across V2 releases AWS ultimately added 61 denied permissions covering 17 services.
V3 replicated the additions made in V2 v4 and v5 and did not add more permissions beyond those. AWS uses both minor updates (altering policy statements under the same managed policy name) and major updates (creating a new managed policy with a vX suffix); after a new major version is released, AWS stops attaching older versions. Beginning with AWSCompromisedKeyQuarantineV2, the Support service includes the support ticket with attachment details.
AWS explicitly designed this quarantine policy as a balance: it denies a set of risky actions rather than applying AWSDenyAll, which would block all activity and disrupt legitimate processes that still use the key.
GitHub secret scanning, validity checks, and identifying exposed keys
GitHub’s secret scanning partner program, expanded to include AWS in 2020, scans public repositories by default and can scan private repositories when enabled by owners. GitHub added validity checks in January 2023 and push protection in August 2023. For AWS keys, these validity checks perform an STS GetCallerIdentity call to confirm whether a detected credential is active; those GetCallerIdentity API calls appear in the CloudTrail logs for the account that owns the key.
GitHub’s automated checks present characteristic network artifacts: the CloudTrail entries show IP addresses resolving to the GitHub ASN and a user agent identifying the call as an automated process. GitHub updated that user agent in early October 2025 — the earlier string ended with “Please-contact-secret-scanning-github.com-for-more-info.” and the newer string ends with “For-questions-on-our-processes--please-contact-secret-scanning-github.com.” Both user-agent patterns are listed by Palo Alto Networks and can be used to detect GitHub validity checks.
Push protection has limits: it may not scan overly large pushes (e.g., public repositories exceeding 50 MB or pushes containing thousands of files) and, when a single code push contains more than five exposed secrets, it will only alert on five. These gaps create scenarios where secrets could be missed by push protection alone.
What this means for cloud engineering teams, security teams, and incident responders
- Cloud engineering teams: monitor console and account emails and coordinate with security so Health and Support alerts (which may not create CloudTrail events) are handled by the security team rather than only by engineering.
- Security teams and incident responders: create detections for IAM AttachUserPolicy events in CloudTrail where PolicyArn references AWSCompromisedKeyQuarantine, and alert on STS GetCallerIdentity calls originating from GitHub ASN IP addresses with the GitHub secret-scanning user-agent strings. Aggregate support cases with AWS Systems Manager Explorer to avoid missed email-based notifications.
The AWSCompromisedKeyQuarantine workflow is an operational countermeasure: it acts fast, records the attachment in CloudTrail, and produces console Health and Support artifacts that require follow-up. Security teams that pair these automated quarantines with CloudTrail-based alerts and GitHub validity-check indicators will be better positioned to detect exposures and begin an investigation before adversaries can act.
