TL;DR: A July 2026 Darktrace disclosure shows an exposed LiteLLM AI gateway with standing Amazon Bedrock access turned one server compromise into a far wider identity risk, according to Cakewalk's analysis. The core issue is not the gateway category itself but whether it holds persistent credentials, because runtime policy at the gateway can either collapse or concentrate blast radius.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Cakewalk's blog post: AI gateway security depends on what the gateway is allowed to hold, and a gateway with standing credentials can turn one exposed server into a much larger access problem.
Why it matters: For IAM, PAM, NHI, and agentic AI teams, the key issue is whether the gateway concentrates access safely at runtime or concentrates blast radius through persistent credentials.
Context
AI gateway security is about the control point where agent and application requests meet model access, policy enforcement, and credential handling. In this article, the governance problem is not AI traffic itself but whether the gateway holds standing access that can be reused if the server is exposed.
The source article uses a July 2026 Darktrace disclosure as the catalyst: a LiteLLM gateway exposed to the internet held standing Amazon Bedrock access and lacked meaningful caller verification. That makes the question one of NHI and agent access governance, not just infrastructure hardening.
The broader issue is that gateway designs are becoming the runtime choke point for agentic systems. If that choke point stores persistent credentials, it can amplify rather than contain identity risk.
Key questions
Q: What breaks when AI agents keep standing credentials?
A: The access model breaks because the agent can continue acting after the human has moved on, the workflow has shifted, or the original approval is no longer relevant. Standing credentials turn delegated authority into unattended authority, which is especially risky when agents can retry, chain tools, and move quickly across systems.
Q: Why do AI gateways need runtime policy instead of static access rules?
A: Static rules cannot reflect the short-lived, context-sensitive nature of agent requests. Runtime policy lets the gateway evaluate each action at the moment it occurs, which is the only point where caller, intent and target can be checked together. That is what keeps policy aligned with agent behaviour.
Q: How do teams know whether a gateway is really reducing blast radius?
A: A gateway is reducing blast radius only if compromise leaves little or nothing reusable behind. If the host still contains standing cloud credentials, the gateway is centralising risk rather than controlling it. The strongest signal is whether access can be injected just in time and revoked immediately after use.
Q: Should organisations treat AI governance and AI security as the same thing?
A: No. Governance answers who approved the system, what data it may use, and which policy applies. Security answers whether an attacker can misuse the system, steal data, or abuse credentials. The two functions need different owners, different evidence, and different response workflows.
Technical breakdown
Why standing credentials change the gateway threat model
An AI gateway becomes materially different when it stores persistent credentials instead of brokering access ephemerally. In the source case, the gateway could call Amazon Bedrock through an instance profile, which meant any process on that server inherited usable access. That is not just an exposure issue. It is a trust design issue, because the gateway’s security boundary now includes the value of every credential it carries. In identity terms, the gateway stops being a policy checkpoint and becomes a credential container with network reach.
Practical implication: treat gateway-held credentials as part of the attack surface, not as an implementation detail.
How runtime policy turns the gateway into an enforcement point
The architectural distinction in the article is between forwarding traffic and governing each call as it happens. A runtime policy layer can inspect the requested action, the calling context and the target system before access is allowed. That matters because agents and applications produce many short-lived requests, and the control only works if each request is evaluated independently. The gateway is therefore less about routing and more about decision-making. If the policy engine fails open, or if the gateway does not re-check every request, the model is effectively back to static trust.
Practical implication: design the gateway so every request is evaluated before credentials are injected or downstream access is granted.
Why app-by-app enforcement leaves a governance gap
The article contrasts gateway-level control with app-specific hooks. App-by-app enforcement only protects systems that have already implemented the control, which creates inconsistent coverage and weak auditability. A central gateway can standardise policy across many tools, but only if it controls credential use rather than simply proxying traffic. For NHI governance, the important point is that policy location and credential location are not the same thing. Putting controls at the gateway without removing standing access still leaves the highest-value secrets in one place.
Practical implication: evaluate whether the gateway is enforcing policy centrally or merely centralising credentials.
Threat narrative
Attacker objective: The attacker sought to turn control of the exposed gateway into access to cloud resources, model services and adjacent AWS identity actions.
- Entry began with an internet-exposed server that Darktrace observed receiving repeated login attempts, suggesting brute-force pressure against the gateway itself.
- Credential access followed because the server held standing Amazon Bedrock access through an instance profile, so compromise of the host exposed cloud permissions already attached to it.
- Impact was limited in the disclosed case to cryptomining, but the attacker also attempted to invoke models and create AWS users, showing the much wider blast radius available through the gateway.
Breaches seen in the wild
- 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
Persistent access at the gateway was the real failure, not the gateway pattern itself: The source incident shows why the control question is whether the gateway holds credentials that survive a single request. When a gateway keeps standing access, one host compromise can become model access, cloud access and downstream identity exposure. Practitioners should judge gateway design by what remains usable after compromise, not by whether policy exists in front of the request.
Runtime governance is the only control point that matches agent behaviour: Agent and application calls are short-lived, repetitive and context-sensitive, which makes static approval models too blunt. A gateway can work as an enforcement layer only if it evaluates each call at the moment of use and does not rely on pre-authorised access surviving between sessions. That is why runtime governance now matters as much as authentication did in earlier identity models.
Gateway centralisation creates both control and concentration: The same architecture that makes a gateway attractive to attackers also makes it the best place to enforce policy consistently. The governance mistake is to centralise traffic while leaving credentials persistent and reusable. The implication is a named concept we should keep using: identity concentration risk. It describes the point where operational convenience turns into a single, high-value access reservoir.
AI gateway security and MCP gateway governance are converging but not identical: An AI gateway mediates model calls, while an MCP gateway can mediate what agents do inside applications. That distinction matters because the control objective changes from protecting model access to governing task execution and tool use. Practitioners need to separate model transport security from agent action governance, or they will assume one control layer covers both.
Zero standing access remains the decisive benchmark for non-human identity control: The article reinforces that persistent credentials are the problem class, not just exposed interfaces. If a gateway can inject credentials only at the moment of approved use, then compromise has far less to steal. The field should treat zero standing access as the default governance expectation for AI gateways and agent-facing control points.
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: Agentic AI Security Guide
What this signals
Identity concentration risk: The more a gateway concentrates model access, downstream permissions and audit logging in one place, the more important zero standing access becomes. A breach at the control point should not expose reusable credentials or ungoverned tool calls, because the value of the gateway is supposed to be enforcement, not inheritance.
The operational test for these environments is simple: if compromise still leaves reusable cloud permissions behind, the control point is wrong. That is why runtime governance and credential residency need to be evaluated together rather than as separate projects.
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. That trend makes gateway-held credentials a recurring governance problem, not a one-off incident pattern.
For practitioners
- Remove standing credentials from gateway hosts Ensure the gateway does not retain reusable cloud, model or downstream application credentials on the server itself. Credentials should be injected only for the approved action and should not persist between calls.
- Enforce per-call policy decisions Require a policy decision for every agent or application request before access is granted, with no fail-open path if the policy engine is unavailable.
- Separate model access from task governance Map which controls protect model-provider connectivity and which controls govern agent actions inside applications. Do not assume an AI gateway alone covers tool use, downstream writes or destructive actions.
- Audit gateway exposure as an identity issue Review internet exposure, authentication strength and credential residency together, because a gateway that forwards requests but holds standing permissions can amplify breach impact.
Key takeaways
- The article shows that AI gateway compromise becomes far more serious when the gateway holds standing access, because the host then carries reusable privilege into the breach.
- The disclosed Darktrace incident illustrates how a single exposed server can connect cryptomining activity with broader cloud and model access risk.
- The control that matters most is whether the gateway can enforce per-call decisions without persisting credentials between sessions.
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, OWASP Agentic AI 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-02 — Secret Leakage | The incident hinges on exposed gateway credentials and reusable cloud access. |
| NHI-05 — Overprivileged NHI | Standing Bedrock access gave the gateway more privilege than the task needed. | |
| NHI-07 — Long-Lived Secrets | Persistent instance-profile access made the compromise much more valuable. | |
| Recommendation — Remove exposed gateway secrets and ensure credential material is never retained on the host. Right-size gateway privilege so each call receives only the access it actually requires. Eliminate long-lived gateway secrets and replace them with just-in-time access where possible. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent-facing gateways fail when privileged access can be reused across runtime actions. |
| Recommendation — Bind agent requests to least-privilege runtime decisions and prevent privilege reuse across sessions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The case centers on credential lifecycle and reuse in the gateway layer. |
| Recommendation — Apply authenticator management controls to rotate, constrain and revoke gateway credentials promptly. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The gateway needs explicit authorization decisions for each call and entitlement. |
| Recommendation — Review and enforce entitlements so gateway access is authorized at the point of use. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The incident pattern involves credential exposure and downstream operational impact. |
| Recommendation — Map gateway exposure to credential access and impact techniques to prioritise detection and containment. | ||
Key terms
- AI Gateway: A control point that sits between AI applications and the models, tools, or data they call. In practice, it can authenticate requests, enforce policy, inspect runtime behaviour, and stop unsafe actions before they spread into connected systems.
- Standing Access: Standing access is persistent privilege that remains available without fresh approval or contextual checks. In NHI environments, standing access usually appears as long-lived tokens, reusable service accounts, or broad roles attached to automation. It is convenient operationally, but it expands risk when conditions change or secrets leak.
- Runtime Governance: Runtime governance is the set of controls that verify what a system or agent is actually doing after deployment. It combines monitoring, authorization checks, and access validation so teams can detect drift, misuse, or excessive privilege in motion rather than assuming build-time policy still holds.
- Identity concentration risk: The exposure created when too many applications depend on one external identity control plane. A breach, outage, or jurisdiction problem in that plane can cascade across every downstream system that trusts it.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on August 26, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org