TL;DR: AWSCompromisedKeyQuarantine blocks classic Bedrock invocation but still leaves AWS Bedrock Mantle inference reachable through a different service prefix, according to Plerion's research and account testing. Deny lists only protect the surfaces they already know, so new inference endpoints shift abuse and billing risk into logging and policy gaps.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Plerion's blog post: Bedrock Mantle creates a separate inference path that bypasses AWSCompromisedKeyQuarantine because the deny policy does not cover the new service prefix.
Why it matters: IAM and cloud security teams need to treat new model endpoints as fresh access surfaces, because quarantine policies and audit controls lag behind service expansion.
Context
Cloud AI services often split one business capability across multiple service endpoints, and that creates a control problem when security policies key off an older prefix instead of the actual runtime path. In AWS, a key can be quarantined for classic Bedrock access while a separate inference surface remains available, which means the access decision and the observability decision can diverge.
This is fundamentally an identity and authorization issue, not only an AI platform issue. When workload access is governed by static deny lists, every new API surface has to be discovered, classified, and monitored before it becomes an abuse path. That pattern is atypical only in the sense that the vendor shipped a second inference plane; the governance failure is common.
Key questions
Q: What signs suggest cloud AI inference has been abused after key exposure?
A: Look for unexpected model-request spend, requests from unfamiliar identities or regions, and inference activity that appears after a key has been quarantined or rotated. In cloud AI services, abuse often shows up as successful completions, token usage, or billing drift rather than obvious interactive login failures.
Q: Why do quarantine policies miss some cloud AI services?
A: Quarantine policies miss some cloud AI services because access is often mediated by short-lived tokens, service accounts, or API calls that bypass browser-style controls. They also fail when the service is reached through indirect paths such as integration APIs, managed identities, or embedded model endpoints. Effective quarantine needs network restrictions, token revocation, and explicit allow-lists.
Q: How does least privilege apply to model invocation APIs?
A: Least privilege means each caller gets only the minimum permissions needed to invoke specific model operations, such as inference, fine-tuning, or embedding requests. The control should be enforced with scoped API tokens, RBAC or ABAC, and separate credentials for read, write, and admin functions. The link phrase model invocation APIs fits naturally here.
Q: What is the best way to monitor cloud AI access paths?
A: The best way to monitor cloud AI access paths is to log every control-plane and data-plane request, then correlate identities, tokens, and source locations. Focus on data events, API calls, service account use, permission changes, and unusual model invocations. That gives a traceable path from the human or workload identity to the AI service it reached.
Technical breakdown
Why service prefixes matter in cloud AI authorization
Cloud services often expose the same business function through distinct API namespaces, and policy engines usually evaluate those namespaces independently. In this case, classic Bedrock calls require bedrock:InvokeModel, while Mantle inference uses bedrock-mantle:CreateInference with its own service authorization reference. That means an explicit deny on one service prefix does not automatically constrain the other. The security lesson is that authorization scope follows the service and action names actually in use, not the human idea of “the model endpoint.” See the Amazon Bedrock Security Guide.
Practical implication: Map every AI inference surface to its exact service prefix before assuming a single deny policy covers it.
Why quarantine policies trail new cloud services
Quarantine policies are reactive controls. They are built from known abuse paths, updated after incidents, and only effective when the provider keeps them current. A leaked key that can still invoke a newly introduced API can remain useful even after the quarantine policy is attached, especially when the service is launched with its own endpoint, signing name, and action set. The gap is not that quarantine stopped working, but that the control scope lagged behind the service surface. See the Cloud Credential Compromise Playbook.
Practical implication: Assume any provider quarantine policy is incomplete until you validate it against the current service catalogue.
How logging gaps turn AI inference into invisible spend
CloudTrail data events are often disabled because they cost extra and require deliberate configuration. For AI inference surfaces, that means successful and attempted requests can disappear from the normal audit trail even when the service is actively being abused. If model access, cost exposure, and investigation evidence all depend on data-event logging, then missing telemetry becomes a governance failure rather than a nuisance. The article's finding is that control coverage and visibility must be designed together, not treated as separate decisions.
Practical implication: Enable data-event logging for every inference surface you allow, and verify the records before relying on them for detection.
Threat narrative
Attacker objective: To keep using paid AI inference on someone else's cloud account after the leaked credential is quarantined.
- Entry occurs when a leaked cloud access key is attached to an IAM user that can reach AI inference services.
- Credential access is then abused through a service prefix that is not included in the quarantine deny list, allowing the attacker to keep invoking models.
- Impact follows as the attacker consumes model capacity on the victim account while the owner absorbs the usage cost and investigation delay.
Breaches seen in the wild
- LLMjacking campaign 2024 to 2026: Attackers use stolen cloud credentials and API keys to run AI models on victims' accounts. How LLMjacking grew from 2024 to 2026 and how to stop it.
- LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
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
Cloud quarantine only works when the service map is complete: a deny policy that names one inference API but not the newer one creates a false sense of containment. The control is doing exactly what it was written to do, which is why the failure is governance, not execution. Practitioners should treat new AI endpoints as new authorization domains until proven otherwise.
Bedrock Mantle exposes a service-prefix governance gap: the problem is not just leaked credentials, but the assumption that one cloud provider policy can keep pace with every new model surface. That assumption collapses when the provider introduces a separate endpoint with a separate action namespace and separate logging behaviour. AI model access controls need continuous recertification whenever the platform adds a new runtime path.
Invisible AI consumption is an identity and cost-control problem: when model requests are not captured as data events, security teams lose both detection and attribution. That makes billing anomalies one of the few practical signals of abuse, which is too late for reliable response. The right response is to govern inference access as a monitored identity pathway, not as an optional platform feature.
Static deny lists create lag, not assurance: every time the cloud vendor adds a new endpoint, the policy baseline starts behind the threat surface. That is why security teams should expect policy drift as a normal condition of cloud AI adoption, not an exception. The operational conclusion is to verify current controls against current services, not against yesterday's quarantine rules.
From our research library:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Read next: Cloud Credential Compromise Playbook
What this signals
Inference-surface drift: cloud AI adoption now creates a control problem where the security boundary changes faster than the deny list. The next governance step is to verify every active inference surface against current policy and telemetry, because a missing service prefix is enough to turn containment into partial coverage.
Plerion's findings also point to a broader operational signal: organisations will need to monitor AI platform spend and request patterns as security telemetry, not just finance data. When access controls and logs do not cover a new inference path, billing anomalies may be the first indicator of misuse.
Credential exposure now maps directly to AI consumption risk: leaked cloud keys no longer imply only storage or compute abuse. They can become a route to rented model capacity, hidden inference traffic, and unbudgeted AI use unless teams govern the full endpoint catalogue.
For practitioners
- Validate every AI inference endpoint against current deny policies Inventory all model invocation surfaces, then test whether quarantine policies block each action and service prefix before relying on provider-managed containment.
- Turn on data-event logging for AI inference Enable CloudTrail data events for AWS::BedrockMantle::Project and equivalent resource types so successful requests, failed probes, and spend anomalies are visible.
- Revoke and replace any leaked cloud keys immediately Assume the quarantined credential remains a usable path until you rotate the access key, verify all downstream sessions are dead, and confirm no alternate inference surface is still open.
- Treat new AI services as separate authorization domains Review every newly introduced model endpoint, signing name, and action namespace as if it were a new application, because provider quarantine and SCP logic do not automatically inherit across prefixes.
Key takeaways
- Cloud AI platforms can expose more than one inference surface, and a quarantine policy that covers only the older path leaves an abuse route open.
- The control failure is not limited to key leakage; it is the mismatch between fast-moving service namespaces and slower-moving deny lists and logs.
- Security teams should validate every model endpoint, enable data-event logging, and treat billing anomalies as an investigation signal for compromised credentials.
Related NHI Mgmt Group resources: LLM Provider API Key Security and LLMjacking Guide · Amazon Bedrock Security Guide · Cloud Workload Identity Guide · Cloud Credential Compromise Playbook
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 CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | A quarantined cloud key still authenticates to a separate AI inference surface in this pattern. |
| NHI-02 — Secret Leakage | The article centres on leaked cloud keys being reused for AI inference abuse. | |
| NHI-05 — Overprivileged NHI | A key that can reach multiple inference surfaces has broader access than the business needs. | |
| Recommendation — Test whether each AI endpoint accepts credentials that your quarantine policy still leaves valid. Scan for exposed cloud secrets and revoke them before they can reach alternate model endpoints. Scope NHI permissions to the exact inference services and actions each workload requires. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Stolen keys enable model access and billable resource abuse after compromise. |
| Recommendation — Map leaked-key abuse to credential access and watch for downstream resource consumption and exfiltration. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The problem is an entitlement gap between classic Bedrock and Mantle inference actions. |
| Recommendation — Review access entitlements for every AI endpoint and remove broad permissions that span old and new prefixes. | ||
Key terms
- LLMjacking: Abuse of cloud AI services through stolen machine credentials rather than human user accounts. The attacker uses valid non-human identities such as API keys or tokens to enumerate model access, invoke endpoints, and create cost, data, or policy exposure under the victim's tenancy.
- Service Prefix: Service Prefix is a naming convention used at the start of a service name to group related systems, functions, or environments. In cloud and platform administration, prefixes help operators organise resources, apply policy, and distinguish application services from shared infrastructure, but the prefix itself is only a label and does not define access or trust.
- Access Key Quarantine: Access Key Quarantine is the temporary isolation of an access key after exposure, suspected misuse, or failed rotation. The key is blocked, monitored, or replaced while dependent systems are reconfigured, so the old secret cannot continue to authenticate without review.
- Cloud Credential Compromise: Cloud Credential Compromise is the unauthorised use or theft of cloud credentials such as access keys, session tokens, certificates, or service account secrets. It usually means an attacker can impersonate the identity tied to those credentials and reach cloud resources until the credentials are revoked or rotated.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and agentic AI identity. It gives practitioners a common control vocabulary for cloud access, privilege, and lifecycle decisions.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org