TL;DR: Long-lived Bedrock API keys backed by Service Specific Credentials could bypass some SCP enforcement for Bedrock Mantle until AWS corrected the logic, according to Sonrai Security, showing how newly introduced auth paths can outpace centralized controls. The lesson is that org-level policy assumptions must be tested against every credential type, not just the default path.
NHIMG editorial — based on content published by Sonrai Security: Cracks in the Bedrock, bypassing SCP enforcement with long-lived API keys
By the numbers:
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
A: Central policy can look correct while enforcement silently diverges across authentication paths.
Q: Why do long-lived service credentials increase cloud identity risk?
A: They expand persistence, weaken revocation urgency, and create more opportunities for stale or overlooked access to survive.
Q: How can security teams know whether org-level policies really cover new cloud services?
A: By testing authorization outcomes for every credential path that the service supports, not just the default one.
Practitioner guidance
- Test every new credential path against org policy Run explicit authorization tests for short-term keys, long-term service-specific credentials, and SigV4 calls whenever a new AWS service or namespace appears.
- Inventory service-specific credentials separately Track service-specific credentials as a distinct identity class with owner, purpose, and revocation state.
- Deny service-specific credential creation where possible Use SCPs or equivalent org policies to restrict iam:CreateServiceSpecificCredential except for approved exceptions.
What's in the full article
Sonrai Security's full blog post covers the operational detail this post intentionally leaves for the source:
- The exact Bedrock Mantle request paths and IAM namespace differences that created the enforcement gap.
- The full reproduction steps for short-term keys, long-term keys, and SigV4 testing across denied actions.
- The sample SCP statements used to block long-term bearer tokens and service-specific credential creation.
- AWS's disclosure timeline and the remediation sequence that closed the issue.
👉 Read Sonrai Security's analysis of the Bedrock Mantle SCP bypass →
AWS Bedrock Mantle SCP bypass: what it means for IAM teams?
Explore further