SCP enforcement gaps in AWS Bedrock Mantle expose IAM trust assumptions

At a glance

What this is: Sonrai Security documents an AWS Bedrock Mantle access-control gap where long-lived API keys tied to Service Specific Credentials could bypass SCP enforcement before the issue was fixed.

Why it matters: It matters because cloud IAM teams cannot assume that one control path enforces all credential types equally, especially as new AI and infrastructure APIs expand the privilege model.

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.

👉 Read Sonrai Security's analysis of the Bedrock Mantle SCP bypass

Context

Cloud policy enforcement only works if every authentication path is evaluated against the same boundary conditions. In this case, the issue was not a broken identity model in the abstract, but a mismatch between Service Control Policies and long-lived Bedrock API keys backed by Service Specific Credentials, which created a gap in least-privilege enforcement for cloud identity security.

For IAM and PAM teams, the real lesson is that new service-specific credentials can change the control surface even when the policy language looks stable. When infrastructure and AI services introduce alternate authorization paths, central governance must validate whether those paths inherit the same restrictions, logging, and exception handling as the default flow.

That makes this a cloud IAM problem first and an AI-adjacent problem second. The article is a typical example of how quickly platform evolution can expose assumptions in org-level access controls, especially where service-specific credentials are treated as a narrow edge case rather than a governance boundary.

Key questions

Q: What breaks when service-specific credentials are not evaluated the same way as standard cloud access keys?

A: Central policy can look correct while enforcement silently diverges across authentication paths. That creates a governance gap where one credential class is denied and another is allowed, even though both reach the same service. Teams should test each credential type separately and treat inconsistent deny behavior as a control failure, not an exception.

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. In cloud programmes, long-lived credentials are especially risky when they can reach new endpoints or alternate auth paths that were not part of the original control design. That is why lifecycle review matters as much as privilege scope.

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. The right signal is whether explicit deny, logging, and revocation behave consistently across short-term keys, bearer tokens, and service-specific credentials. If they do not, the service has introduced a policy gap that needs separate governance.

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.

Technical breakdown

Service specific credentials and bearer token paths

Service Specific Credentials are credential objects tied to an IAM user for a specific AWS service, rather than general purpose access keys. In Bedrock's case, long-lived API keys are backed by these credentials and can be used to call model endpoints through bearer-token style authentication. That means the request path is not identical to a SigV4-signed API call, even if it ultimately resolves to the same principal and entitlement set. When a platform introduces a second authentication path, policy evaluation has to account for both the identity that created the credential and the identity that owns it.

Practical implication: map every service-specific credential type to its exact enforcement path before assuming SCP coverage.

Why SCP logic can diverge across new service endpoints

Service Control Policies sit above individual accounts, but they still depend on how a service surfaces the principal and action being evaluated. Sonrai's testing showed that Bedrock Mantle originally exposed a case where long-lived keys were not fully constrained by the expected SCP logic, even though short-term keys and standard SigV4 requests were denied correctly. This is a classic control-integration failure, not a missing policy language problem. The policy existed, but enforcement did not consistently follow the alternate credential path when a new endpoint and new IAM namespace were introduced.

Practical implication: test SCP behavior against every new service namespace and credential type, not just the original API.

Long-lived keys expand the identity blast radius

Long-lived API keys and service-specific credentials are difficult because they outlive the moment of issuance and can be reused without the same review cadence as short-lived credentials. In cloud identity terms, they increase persistence, widen the audit window, and complicate revocation. That matters even more when the credential is attached to a user who can create or attach further access. The article shows that the operational risk is not just unauthorized use of the model endpoint, but the possibility that org-level controls may be bypassed through a credential class that teams treat as peripheral.

Practical implication: reduce reliance on long-lived service-specific credentials and verify that revocation, logging, and policy checks work on those credentials specifically.

Threat narrative

Attacker objective: The objective is to use an alternate credential path to reach restricted Bedrock Mantle inference actions despite org-level denial.

1. Entry occurred through valid long-lived Bedrock API keys backed by Service Specific Credentials rather than through exploit code or stolen passwords.
2. Escalation happened when those keys were able to reach Bedrock Mantle actions despite an SCP denial that should have blocked the request path.
3. Impact was the ability to invoke restricted model endpoints and bypass centralized org-level access restrictions until AWS corrected enforcement logic.

Breaches seen in the wild

• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Long-lived service-specific credentials create identity blast radius that is easy to underestimate. These credentials are narrow in theory but durable in practice, which means they can survive longer than the control assumptions that were written for short-lived access. In NHI governance terms, persistence plus alternate authentication paths is where least privilege starts to drift. Teams need to account for revocation scope, log visibility, and exception handling at the credential-class level, not just the user level.

Centralized enforcement breaks down when new access paths inherit old trust assumptions. SCPs were designed for a world where authorization decisions stay within the expected request pipeline. That assumption fails when a service exposes long-term bearer-token behavior through a distinct IAM namespace and credential mechanism. The implication is that governance teams have to rethink how they validate inheritance across service-specific authentication paths, because policy intent alone does not prove enforcement parity.

Cloud identity programmes need a dedicated control for alternate service credential paths. This incident is a reminder that service-specific credentials are not merely implementation detail. They are a separate governance surface with their own issuance, scope, and enforcement questions. The practitioner conclusion is simple: if the credential class can bypass your assumed path, then your identity control model is incomplete.

Named concept: alternate-path policy drift. This is the gap that appears when a new service or credential type inherits the appearance of central enforcement without receiving the same evaluation logic. In Bedrock Mantle, the drift existed between the stated SCP boundary and the actual long-lived key path. The field takeaway is to test drift at the point where identity, endpoint, and policy interpretation meet.

From our research:

• 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.
• For a broader control model, see Ultimate Guide to NHIs for how lifecycle and least privilege should be applied across machine identities.

What this signals

Alternate-path policy drift: cloud teams should now assume that every new service namespace can introduce a second enforcement path that behaves differently from the first. When a platform adds bearer-token or service-specific credential support, the identity programme has to validate the real request flow, not the documented intent. That is the difference between a policy that exists and a policy that actually governs.

With 70% of organisations already granting AI systems more access than human employees in equivalent roles, per the 2026 Infrastructure Identity Survey, the larger pattern is not just over-privilege. It is governance lag, where new identity classes and new credential paths arrive faster than review, exception, and enforcement models can absorb them.

Practitioners should expect infrastructure and AI identity controls to converge around the same question: does the alternate path inherit the same deny logic as the default path? That is where cloud IAM, NHI governance, and agentic access control now meet in operational practice.

For practitioners

• 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. Validate both allow and explicit deny behavior, because enforcement gaps often show up only on the alternate path.
• Inventory service-specific credentials separately Track service-specific credentials as a distinct identity class with owner, purpose, and revocation state. Do not bury them inside generic IAM user reporting, because their lifecycle and blast radius differ from standard access keys.
• Deny service-specific credential creation where possible Use SCPs or equivalent org policies to restrict iam:CreateServiceSpecificCredential except for approved exceptions. If the business requires a long-lived credential, attach an explicit review process and a named owner to the exception.
• Rehearse policy bypass detection in sandbox accounts Build repeatable tests that probe whether a new API, bearer token flow, or service namespace honors the same deny statements as existing paths. Capture the result as evidence for cloud IAM change control and drift review.

Key takeaways

• Cloud IAM failures often emerge at the boundary between policy design and enforcement across alternate credential paths.
• Long-lived service-specific credentials widen identity blast radius because they can outlive the control assumptions written for short-lived access.
• Practitioners should validate every new service namespace against real authorization outcomes before they rely on org-level policy coverage.

Key terms

• Service Specific Credential: A service-specific credential is a credential issued for one named cloud service rather than for broad, general use. It can simplify access to a single endpoint, but it also creates a distinct lifecycle, revocation, and enforcement surface that must be governed separately from standard access keys.
• Service Control Policy: A Service Control Policy is an organization-level guardrail that sets maximum permissions in a cloud environment. It does not replace identity policy, but it should consistently constrain every supported authentication path, including alternate credential types and new service namespaces.
• Long-lived API key: A long-lived API key is a credential intended to remain usable beyond a short session window. In identity governance, that persistence increases the chance of stale access, hidden exposure, and inconsistent enforcement unless the key is tracked, tested, and revoked with discipline.
• Alternate-path policy drift: Alternate-path policy drift is the gap that appears when a new credential type or service endpoint behaves differently from the default access path. The policy may look identical on paper, but enforcement, logging, or revocation can diverge in practice, weakening the control model.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Sonrai Security: Cracks in the Bedrock, bypassing SCP enforcement with long-lived API keys. Read the original.