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.
At a glance
What this is: This is a Sonrai Security analysis of an AWS Bedrock Mantle control gap in which long-lived Service Specific Credentials could bypass some SCP enforcement logic.
Why it matters: It matters because IAM teams cannot assume centralized policy enforcement is consistent across every credential type, especially when new service-specific auth paths are introduced.
Context
AWS Bedrock Mantle introduced a new authentication and permission path that sits alongside existing Bedrock access patterns. The issue Sonrai Security examined was not general cloud misconfiguration, but a specific mismatch between centrally managed Service Control Policies and long-lived bearer credentials backed by Service Specific Credentials.
For IAM and PAM teams, the governance problem is straightforward: if a new credential form changes how authorization is evaluated, the control model must be revalidated end to end. That is especially important when the same service supports both short-lived and long-lived keys under different enforcement behaviour.
Key questions
Q: Where do SCPs fail when a cloud service adds a new credential path?
A: They fail when the policy is written for the service’s standard access flow but the new credential path is evaluated differently. Teams should assume every alternate bearer mode is a separate authorization surface until it is proven to be covered by the same deny logic.
Q: When should IAM teams re-test organization-level deny policies?
A: Re-test them whenever a cloud provider adds a new service namespace, alternate token mode, or service-specific credential type. Those changes can alter the authorization boundary even when the underlying IAM user or role model appears unchanged.
Q: What is the operational risk of long-lived API keys in cloud IAM?
A: Long-lived keys increase the chance that a credential path will outlive the assumptions built into central policy enforcement. They are especially risky when the service can evaluate them through a different authorization chain than standard signed requests.
Q: How should teams govern certificate-based non-human identities in AWS?
A: Treat each certificate as part of a lifecycle-managed identity, with explicit ownership, narrow trust scope, current revocation data, and role bindings reviewed against actual data access. That approach limits hidden access paths and makes machine credentials governable in the same way teams govern other NHIs.
Technical breakdown
How Bedrock Mantle authorization differed by credential type
Bedrock Mantle accepted multiple ways to call the service, including SigV4-signed requests, short-term bearer tokens, and long-term API keys backed by Service Specific Credentials. Those paths did not behave identically under SCP evaluation. In Sonrai Security’s testing, the same denied action could be blocked for SigV4 and short-term tokens while still succeeding through a long-term credential path before AWS corrected the logic. The technical lesson is that identity enforcement is not just about what permission exists, but which authentication surface is being used to reach the service. A centralized policy only works when every credential form is mapped into the same authorization decision chain.
Practical implication: Test every new credential type against org-level deny rules before treating the control as enforced.
Why Service Specific Credentials created a policy blind spot
Service Specific Credentials are bound to IAM users, but they behave differently from ordinary user access keys because they are service-scoped and can carry service-specific bearer semantics. In this case, the long-term Bedrock key inherited permissions from the backing IAM user, yet SCP enforcement did not consistently block the Mantle endpoint during the affected window. That is a classic control-assumption gap: the policy engine expected the identity path to resolve through the same guardrails as standard access, but the credential type changed the enforcement outcome. The result is not merely a weaker key format, but a different authorization surface that must be governed explicitly.
Practical implication: Inventory service-specific credentials separately and validate whether each one is actually covered by SCP conditions.
Why org-level policy is only as strong as its least-tested access path
Centralized controls such as SCPs are designed to express organization-wide boundaries, but they are only reliable if new services inherit those boundaries without exception. The article shows how a newly released capability can create a temporary gap between the intended deny posture and the actual evaluation logic. That matters beyond Bedrock Mantle because cloud platforms regularly add alternate invocation paths, service-specific tokens, and feature-specific namespaces. When those arrive, existing least-privilege assumptions often remain unchallenged until someone deliberately tests them. The real technical risk is control drift across authorization surfaces, not just credential leakage.
Practical implication: Re-run policy validation whenever a cloud service adds a new endpoint, namespace, or credential mode.
Threat narrative
Attacker objective: The objective is to invoke restricted Bedrock Mantle actions while bypassing centralized IAM governance controls.
- Entry occurred through a legitimate long-term Bedrock API key backed by a Service Specific Credential rather than through compromised infrastructure.
- Credential access was not the issue; the bypass used an authorised credential type that should have been constrained by SCP deny logic.
- Escalation happened when the long-term key reached the Bedrock Mantle endpoint and executed a denied model invocation despite the organization-level restriction.
- Impact was the successful execution of bedrock-mantle:CreateInference under a control path that the organisation expected to be blocked.
Breaches seen in the wild
- OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Policy enforcement is only as strong as the credential paths it actually covers. Sonrai Security’s findings show that centralized deny controls can look complete on paper while still missing a newly introduced authorization path. In cloud IAM, the gap is rarely the policy intent itself, but the assumption that every credential form resolves through the same enforcement logic. Practitioners should treat each new service authentication mode as a separate governance surface, not a minor variant of the old one.
Long-lived bearer credentials create a governance dependency on endpoint-specific evaluation. Service Specific Credentials are not just another way to authenticate. They create a parallel trust path whose behaviour can diverge from ordinary user access, which means org-wide guardrails must be tested against the exact credential type, not an abstract service account model. The practical implication is that authorization coverage must be proven per credential class, especially when long-lived keys are allowed.
Central SCP design does not eliminate the need for explicit credential-form constraints. The article demonstrates that a denied action can still succeed when the control plane assumes all access reaches it through the same enforcement route. That is a classic IAM trust assumption failure, and it becomes more visible as cloud providers add service-specific namespaces and alternate bearer-token modes. The practitioner conclusion is that organisation-wide policy has to be validated against every new access path before it is trusted as a boundary.
Bedrock Mantle exposed an identity blind spot rather than a new model risk. The issue was not that centralized policy became obsolete, but that a newly created service path sat outside the practical reach of the expected deny rule until AWS corrected it. That distinction matters because many identity programmes overestimate coverage once a policy is written. Teams should regard feature releases as governance tests, not just product updates.
What failed was the assumption that a service-scoped key cannot alter the policy decision surface. That assumption was designed for credential families whose authorization behaviour is already understood. It fails when a new bearer path is introduced and evaluated differently at the endpoint. The implication is that IAM teams must re-establish which credential forms are actually inside the policy boundary, rather than assuming the boundary is stable.
From our research library:
- 49% of IT professionals would prioritise improving privileged access management if the decision were theirs alone, according to Netwrix's 2023 Hybrid Security Trends Report.
- Read next: Agentic AI Identity Guide
What this signals
Credential-form drift is the real governance issue: when a cloud service adds a new bearer mode, the policy boundary can change even if the permission name does not. That means teams need validation at the credential layer, not just at the IAM statement layer.
Long-lived service-specific credentials deserve separate oversight because they are structurally easier to miss in policy testing and operational review. The control question is not whether the service is allowed, but whether every token form is actually inside the deny envelope.
Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs. That matters here because alternate service credentials create governance debt unless they are explicitly governed and retired.
For practitioners
- Validate every new cloud credential mode against SCP deny logic When a service introduces short-term tokens, long-term keys, or service-specific credentials, test each one against explicit organization-level denies before allowing production use.
- Separate governance for long-lived and short-lived bearer paths Treat long-lived API keys as a distinct control class, with separate approval, monitoring, and revocation checks rather than inheriting assumptions from default user access.
- Deny service-specific credential creation where it is not required If a workload does not need service-specific credentials, block iam:CreateServiceSpecificCredential at the organization level so alternate access paths cannot emerge later.
- Re-test SCPs after every service namespace expansion Any new endpoint, permission namespace, or alternate authorization mode should trigger a fresh policy verification exercise, because old deny logic may not automatically cover the new path.
Key takeaways
- This case shows that a centrally defined deny rule can still miss a newly introduced authorization path if the credential type is evaluated differently.
- The incident affected a specific Bedrock Mantle access path, but the broader lesson is that new service namespaces can expose hidden policy assumptions.
- IAM teams should test every credential form against org-level controls and restrict service-specific credential creation where it is not genuinely needed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The bypass depended on a service-specific bearer path being evaluated differently from standard access. |
| NHI-05 — Overprivileged NHI | The long-term key inherited broad permissions from the backing IAM user and managed policy. | |
| NHI-07 — Long-Lived Secrets | The issue centered on long-term API keys that persisted beyond the expected short-lived control model. | |
| Recommendation — Map alternate bearer-token paths to NHI-04 and verify they are enforced like primary authentication flows. Review NHI permission scope against NHI-05 and remove broad inherited access from long-lived service credentials. Classify long-lived service keys under NHI-07 and restrict their creation where short-lived alternatives exist. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 governs credential lifecycle controls relevant to long-term service-specific keys. |
| Recommendation — Apply IA-5 to inventory, restrict, and retire long-lived authenticators used for service access. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about authorization boundaries failing across credential types and service namespaces. |
| Recommendation — Validate PR.AA-05 across every authentication path and confirm deny rules cover service-specific credentials. | ||
| MITRE ATT&CK | TA0006;TA0004 — Credential Access; Privilege Escalation | The pattern is about abusing a valid credential path to reach restricted service actions. |
| Recommendation — Map alternate credential abuse to TA0006 and TA0004 when testing whether denied actions can still execute. | ||
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: An AWS Service Control Policy is an organisation-level guardrail that caps the maximum permissions available to accounts and identities in scope. It does not grant access on its own, but it shapes the outer boundary of what IAM policies can ever allow, which makes it central to org-wide least privilege.
- Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
- Authorization surface: The authorization surface is the set of places where an identity is allowed or denied to act after authentication. It includes policies, enforcement points, and the telemetry that records each decision. For NHIs and AI workloads, this surface often expands faster than review processes can track.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org