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

At a glance

What this is: Obsidian Security’s analysis shows that chained LiteLLM flaws can turn a low-privilege account into admin access and code execution, with downstream agent tool injection as a second-order risk.

Why it matters: IAM and security teams need to treat AI gateways as privileged control points because weak route logic and field-level authorization can collapse both operator trust and agent trust.

Context

LiteLLM is an AI gateway, so it sits between applications, models, provider keys, and in some deployments downstream agents and MCP-style tooling. When a gateway concentrates authentication, routing, logging, and code execution hooks, a single authorization mistake can become a full trust boundary failure rather than a narrow bug.

This article is about the governance gap created when route-level checks and object-level authorization are assumed to be equivalent. For AI gateway identity design, the key question is not only who can reach an endpoint, but what privileged action that endpoint can still perform once the caller is inside.

Key questions

Q: What breaks when AI gateway route checks are treated as enough authorization?

A: Route checks only control whether a caller can reach an endpoint. If the gateway also accepts caller-controlled scope fields, the same identity can widen its own access after the route check passes. The result is a policy boundary that looks enforced at the edge but fails at the data that actually defines privilege.

Q: Why do AI gateways need field-level authorization for role changes?

A: Because a user may be allowed to reach an update endpoint without being allowed to change the security attributes inside the object. When privilege fields are writable, access management collapses into self-service escalation. Field-level authorization keeps privilege state from being modified by the same identity it is meant to constrain.

Q: How should security teams decide whether AI guardrails belong in the gateway or in a separate layer?

A: Teams should place guardrails where they can actually enforce policy at runtime with the least duplication. If the gateway already controls routing, authentication, and observability, native guardrails often reduce integration work and improve auditability. Separate layers make sense only when they add a materially different control capability or when existing gateways cannot inspect the relevant requests.

Q: What should teams do when an AI gateway could steer downstream agents?

A: Review the trust chain from gateway to agent to tool and identify where a compromised middle layer could rewrite prompts, inject tool calls, or expose stored credentials. The practical test is whether downstream systems trust the gateway’s output as if it were authoritative. If they do, the gateway is an identity dependency, not just a relay.

Technical breakdown

Why route checks can be weaker than field-level authorization

LiteLLM’s first failure mode was an authorization bypass caused by trusting caller-supplied allowed_routes values as if they were a safe restriction. That pattern matters because route authorization answers only whether a caller may reach an endpoint, while field-level authorization answers what the caller may change once the endpoint is reached. If an application persists user-controlled route scope without validating it against the caller’s true role, the permission list becomes a grant rather than a boundary. In gateway design, that is especially dangerous because routing, key management, and privilege administration all live close together.

Practical implication: validate caller-supplied route scope against the caller’s role before storing or reusing it.

How a missing field-level check becomes privilege escalation

The second flaw was a field-level authorization gap on user update handlers, where user_role could be changed by a caller that should not have been able to write that attribute. This is a classic privilege escalation pattern: the endpoint is reachable, but the sensitive field is not separately protected. In identity systems, the difference between object access and attribute access is decisive. If a low-privilege identity can write its own role field, the system has effectively delegated admin authority to the same subject it was meant to constrain. In an AI gateway, that turns management endpoints into escalation primitives.

Practical implication: separate endpoint reachability from attribute write permission, especially for role and privilege fields.

Why executable guardrail code turns an AI gateway into a control plane

The third issue was server-side code execution through custom guardrail handling, where user code was compiled and executed inside the proxy process. Once an AI gateway can execute code, it stops being only a broker and becomes part of the control plane. That changes the blast radius from credential exposure to arbitrary response tampering, token theft, and tool-call manipulation against downstream agents. In practical terms, a gateway with executable extensions can steer agent behaviour, not just observe it. That is why AI gateway security and agent security are now coupled at the privilege boundary.

Practical implication: treat any executable gateway extension as privileged code that requires the same control scrutiny as admin-managed infrastructure.

Threat narrative

Attacker objective: The attacker’s objective is to turn a low-privilege gateway account into host-level control, then use that position to steal secrets, tamper with agent traffic, and steer downstream tools.

1. Entry began when a default low-privilege user could create or update keys with attacker-chosen allowed_routes values, bypassing the intended route boundary.
2. Escalation followed when user update handlers failed to protect the user_role field, allowing that same identity to promote itself toward proxy_admin privileges.
3. Impact came when custom guardrail code could execute server-side, giving the attacker arbitrary code execution on the LiteLLM host and access to downstream agent tooling paths.

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.
• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

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

AI gateways concentrate trust, so they must be governed as privileged control planes, not as simple routing middleware. LiteLLM shows that route authorization, key management, role assignment, and extension execution can all collapse into a single compromise path when one layer assumes another has already done the hard work. For practitioners, the lesson is to classify the gateway itself as a high-value identity enforcement point, not just a transport layer.

Field-level authorization is the missing discipline in many gateway designs. Route checks answer whether a caller is allowed to arrive, but they do not prove which attributes that caller may modify after arrival. LiteLLM’s role update flaw shows why an endpoint that handles identity state needs independent attribute controls, especially where that state determines broader access rights. Practitioners should treat writable privilege fields as their own enforcement surface, not as ordinary profile data.

Executable extension points are a trust boundary, not a convenience feature. Once a gateway can compile or run custom code, it inherits the risk profile of an admin-managed runtime, including arbitrary execution, secret access, and response tampering. In AI systems, that means gateway compromise can become model compromise and agent compromise in one chain. Security teams should stop assuming that an AI relay is passive just because its purpose is mediation.

Gateway compromise creates downstream identity drift across MCP and agent workflows. When the middle layer can rewrite responses or inject tool calls, the identity being trusted by the agent is no longer the one the human operator thinks they approved. That breaks the assumption that delegated tool use remains bounded by the original authentication context. Practitioners need to reason about trust inheritance across the gateway, provider, and agent layers as one continuous identity problem.

LiteLLM is a named example of a broader AI gateway trust gap. The category now includes route authorization, role mutation, guardrail execution, and downstream tool steering in a single attack surface. That combination is exactly why AI gateway governance has to be treated as an identity architecture problem, not only an application security problem. The practical conclusion is to review every control that assumes mediation equals containment.

From our research library:

• Patching addresses only about 10% of privilege escalation techniques, while privilege management covers about 65%, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: Zero Trust for AI Agents

What this signals

Gateway trust debt: When an AI relay owns routing, key handling, and extension execution, the blast radius is no longer limited to the model call itself. Practitioners should assume that any compromise of the gateway can become a compromise of identity, prompts, and tool invocation across the surrounding stack.

The operational signal is straightforward: if a gateway can both store privilege data and execute code, then access review cadence alone will not contain the risk. Teams need to move assurance earlier, at issuance and at write-time, because the dangerous state is created before any downstream review cycle can catch it.

For practitioners

• Audit route-scope writes before issuance Check every key creation and key update path that accepts allowed_routes or equivalent scope fields. Reject any caller-supplied route list that is broader than the caller’s own role permits, and verify the same logic on regenerate and service-account key flows.
• Separate role updates from profile updates Treat user_role, org_admin, proxy_admin, and similar privilege fields as restricted attributes with their own authorisation checks. Do not rely on the fact that a user can update a profile object to imply permission to change the privilege model inside that object.
• Remove executable trust from guardrail paths Review every custom-code or guardrail endpoint that compiles or executes input inside the proxy process. If a gateway can run code, isolate that path as privileged admin functionality and assume host-level compromise if it is misused.
• Inventory downstream trust dependencies Map which agents, MCP services, provider keys, and internal tools trust the gateway’s responses or headers. Identify any path where a compromised gateway could inject tool calls, alter prompts, or expose stored secrets to downstream systems.

Key takeaways

• LiteLLM’s vulnerability chain shows that AI gateway trust boundaries fail when route scope, role mutation, and code execution are handled as separate concerns.
• The article links the risk to CVSS 9.9 impact and to downstream tool injection, which means compromise extends beyond the gateway process itself.
• The control lesson is to protect privilege fields and executable extensions with separate enforcement, because a single edge check is not enough.

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.
• AllowedRoutes: AllowedRoutes is a Gateway listener setting that controls which namespaces may attach Routes to that listener. It provides a namespace-level admission rule for route attachment, letting platform teams delegate ingress responsibilities without opening the Gateway to every Route in the cluster.
• 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.

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.