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
Policy language did not fail here, enforcement coverage did. The article shows that a centrally written deny statement can still leave a blind spot when a new service introduces an alternate credential and endpoint model. That distinction matters for NIST CSF and zero trust programs because the control objective was present, but the implementation path was incomplete. Practitioners should treat every new cloud service as a policy-validation event, not a policy reuse exercise.
A few things that frame the scale:
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to The 2026 Infrastructure Identity Survey.
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Who is accountable when a new cloud service bypasses central access controls?
A: Accountability sits with the platform and identity owners who approved the service, the control owners who certified policy coverage, and the engineering teams that onboarded the alternate credential path. For cloud governance, the key question is whether the control was validated against the real request path before rollout. If not, the gap is a programme failure, not just a vendor issue.
👉 Read our full editorial: SCP enforcement gaps in AWS Bedrock Mantle expose IAM trust assumptions