LiteLLM’s admin and RCE chain exposes AI gateway trust gaps

At a glance

What this is: Obsidian Security’s research shows that three LiteLLM flaws can chain from low-privilege access to admin control and RCE, with downstream agent compromise as the broader concern.

Why it matters: IAM, NHI, and agentic AI teams need to treat AI gateways as identity-bearing control points because a single authorization failure can widen into token exposure, tool injection, and environment-level compromise.

By the numbers:

• 83% 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.
• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in current deployments.

👉 Read Obsidian Security's analysis of LiteLLM CVE-2026-47101, CVE-2026-47102, and CVE-2026-40217

Context

LiteLLM sits in front of model providers, authentication, routing, guardrails, and audit logging, which makes it more than a convenience layer. In practice it becomes an identity and control plane for AI access, so a flaw in its authorization path can affect both human IAM and non-human identity governance.

The primary issue here is not simply a vulnerable open-source gateway. It is the way AI gateways collapse multiple trust functions into one place, then rely on route checks, field-level authorization, and code-execution boundaries to stay aligned. When those checks diverge, a low-privilege identity can inherit powers far beyond its intended scope.

That pattern is especially relevant for teams using gateways as MCP or agent brokers. Once the gateway can alter model responses or inject tool calls, downstream identity controls no longer define the real blast radius because the gateway itself becomes the point where access, execution, and privilege are decided.

Key questions

Q: What breaks when AI gateways let low-privilege users influence route permissions?

A: The gateway stops enforcing least privilege and starts widening access based on caller-controlled data. That turns a narrow route policy into a privilege grant, which can let a regular user reach admin-only handlers, modify protected settings, or chain into code execution. The fix is to keep permission assignment server-side and immutable from untrusted requests.

Q: Why do AI gateways create more risk than ordinary application proxies?

A: AI gateways often hold master keys, provider credentials, and routing authority for multiple downstream services. If one gateway is compromised, the attacker may inherit access to every connected provider and use the proxy itself to exfiltrate secrets or run malicious requests. That concentration of trust makes the gateway a high-value identity broker.

Q: How do you know whether gateway authorization policies are actually working?

A: You know they are working when policy tests cover both allowed and denied scenarios, decision logs are captured, and changes can be released without breaking expected access. A healthy setup produces repeatable results for anonymous, authenticated, and privileged users. If those cases are not tested, the policy layer is effectively ungoverned.

Q: Who is accountable when a compromised AI gateway injects tool calls into agents?

A: Accountability usually spans the platform owner, the team that exposed the gateway, and the group that trusted it as an execution intermediary. In governance terms, the gateway should be treated like a privileged identity broker, so ownership, logging, and emergency revocation need a named control owner before incidents occur.

Technical breakdown

How route authorization breaks in AI gateways

AI gateways often separate route access from endpoint behaviour. The LiteLLM issue shows why that split matters: a caller may be allowed to reach a route, yet still be untrusted for the sensitive action performed inside it. If route permissions can be written back by the caller or treated as a fallback grant, the system turns a narrowing control into a privilege expansion path. That is not just a coding bug. It is an authorization design failure where identity state, policy state, and route state are no longer coherent.

Practical implication: teams should verify that route-scoped permissions can never be user-supplied grant data.

Why field-level authorization must be independent of role checks

Field-level authorization decides which attributes a caller may change after they have reached an endpoint. In this case, the dangerous field was user_role, which should have been protected even for identities that could reach the update handlers. If a handler assumes the route gate already did the screening, the endpoint becomes a hidden privilege-escalation surface. For identity teams, this is the difference between authenticating a request and authorizing a state change. Those are not the same control.

Practical implication: review every update endpoint for protected identity fields, not just admin routes.

How exec-based guardrails become code execution surfaces

The custom-code guardrail problem is a classic NHI and platform trust issue. When a system executes caller-controlled Python with exec(), the boundary is no longer policy enforcement but runtime code execution. If builtins remain available, the sandbox is effectively absent unless it is explicitly stripped and constrained. In an AI gateway, that matters more than in a normal app because the code can sit on the path between agents, tools, and model outputs. The gateway is then not just brokering identity, it is brokering execution.

Practical implication: treat any executable guardrail as privileged code and isolate it from identity management workflows.

Threat narrative

Attacker objective: The attacker aims to turn a low-privilege gateway identity into host-level control over the AI control plane and the secrets and tools behind it.

1. Entry begins when a default low-privilege LiteLLM user abuses unvalidated allowed_routes in key-generation flows to reach routes their role should not allow.
2. Escalation follows when the user reaches administrative handlers and exploits field-level authorization gaps to promote themselves and reach custom-code guardrail functions.
3. Impact occurs when the attacker runs arbitrary code on the gateway, steals host and provider secrets, and can tamper with model responses and downstream agent tool calls.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

AI gateways are becoming identity enforcement points, not just integration layers. LiteLLM shows that the control plane between agents and models now carries route policy, key ownership, guardrails, and audit authority. When that layer fails, the breach is not limited to one service account or one API token. Practitioners should treat gateways as privileged identity infrastructure with its own governance model.

Field-level authorization is the real dividing line between access and compromise. Route gates can look healthy while update handlers silently allow privileged state changes. That means identity teams must examine write paths, not just login paths or endpoint visibility. The practical conclusion is that authorization drift often hides in the fields an attacker can edit, not the routes they can see.

Executable guardrails create an identity-to-code bridge that conventional IAM does not model well. Once a gateway accepts user-authored code, the trust boundary crosses from access management into runtime execution. That is where NHI governance and secure development controls collide. Teams that only classify the gateway as an application miss the fact that it is also a privileged execution substrate.

AI agent tool injection is a downstream blast-radius multiplier. A compromised gateway can rewrite model responses, steer agent behaviour, and insert arbitrary tool calls into connected systems. That means the gateway’s identity compromise can become a delegated compromise of every agent and service account downstream. Practitioners should re-evaluate where they place trust in agent orchestration paths.

Identity assumptions built for static request flows break when the gateway can steer runtime decisions. Least privilege, review cadence, and route restriction all assume that the caller’s power is stable and visible at the moment of review. When a gateway can alter execution flow or inject tool calls, the real authority moves after the policy decision, which is why gateway governance has to be continuous rather than one-time.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 44% of organisations have implemented any policies to govern AI agents, even though 92% agree that governing them is critical to enterprise security.
• For a control baseline, see OWASP Top 10 for Agentic Applications 2026 for a structured view of agent misuse, tool abuse, and trust boundary failures.

What this signals

Gateway governance has to move closer to runtime control. If an AI gateway can rewrite responses or inject tool calls, then policy decisions made at provisioning time are no longer enough. Teams should expect more scrutiny on where agent authority is mediated, which identities can alter execution flow, and how quickly those controls can be revoked when compromise is suspected.

Agent blast radius is now a platform design issue. The same gateway that centralises routing and logging can also centralise compromise if it is treated as a low-risk helper service. Identity programmes need to map which workloads, tokens, and tool credentials are reachable through a single broker, because that reach determines how far a breach can travel.

Runtime governance gap: This class of weakness is not just about secrets rotation. It is about the gap between an identity decision and the moment an agent actually acts. When the intermediary can steer the agent after the fact, the governance model has to account for runtime tampering, not only access approval.

For practitioners

• Separate route access from state-change authorization Audit every gateway endpoint that writes identity state, role state, or permission state. A caller should never be able to supply its own allowed_routes or equivalent grant data. Test that route reachability and write authorization are enforced by distinct checks.
• Inventory all protected identity fields Review update handlers for fields such as user_role, membership roles, service-account bindings, and token scopes. Require explicit server-side allowlists for mutable fields, and validate that low-privilege identities cannot alter privilege-bearing attributes.
• Treat executable guardrails as privileged code Move any user-authored or admin-authored runtime code out of the main gateway process where possible. If code execution is unavoidable, isolate it, strip ambient builtins, and verify that guardrail failures cannot become shell access or file access.
• Assume downstream agent abuse after gateway compromise Map which tools, SaaS connectors, and MCP pathways a compromised gateway can influence. Then limit the gateway’s authority over those tool calls so a response-tampering event cannot automatically become delegated tool execution.
• Rotate gateway-stored secrets after exposure Prioritise host credentials, provider API keys, database credentials, and any MCP tokens stored in the gateway when compromise is suspected. Validate that secret storage and retrieval paths are separated from request-time execution paths.

Key takeaways

• LiteLLM shows how a low-privilege identity can become admin and then execute code when route and field-level controls drift apart.
• The blast radius extends beyond the gateway itself because compromised AI infrastructure can inject tool calls and expose downstream agent credentials.
• Practitioners should treat AI gateways as privileged identity infrastructure and verify that permissions, protected fields, and executable paths are separately controlled.

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.
• Field-Level Authorization: An access control approach that checks permission at the individual field rather than only at the object or endpoint level. In GraphQL, this is critical because different fields can expose different sensitivity levels, and a user may be allowed to see one field but not another.
• Tool injection: Tool injection occurs when an attacker causes an AI system or intermediary to invoke tools the legitimate user did not intend. In agentic environments this can turn a compromise in the control layer into unauthorized actions in downstream services.
• Executable guardrail: An executable guardrail is policy logic that runs as code during AI processing, rather than as a static rule in an external control plane. That makes it powerful, but also high risk, because the guardrail itself becomes part of the trusted execution surface.

What's in the full report

Obsidian Security's full research covers the exploit details this post intentionally leaves at the control-analysis level:

• Line-by-line proof-of-concept walkthroughs for the allowed_routes bypass and role escalation paths.
• Code-level explanation of the custom-code guardrail sandbox escape, including the exec() and bytecode-bypass paths.
• Patch timeline and version guidance for LiteLLM v1.83.14-stable and the earlier fix releases.
• Operational recommendations for rotating provider keys, database credentials, and MCP tokens after suspected exposure.

👉 The full Obsidian Security post covers the chained exploit path, code snippets, and remediation timeline.

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 building identity controls across human, non-human, or autonomous systems, it is worth exploring.