What LiteLLM Proxy Enforces Out of the Box and What You Still Have to Build

Authentication is not authorization

A shared gateway concentrates risk, so the first distinction to draw is between authentication and authorization. Authentication answers whether a caller holds a valid credential. Authorization answers whether that caller is allowed to perform this specific action. Gateways can do the first well and still leave gaps in the second.

Two recent NVD entries show why the distinction matters for LiteLLM Proxy. CVE-2026-42271 describes endpoints that were gated only by a valid proxy API key, with no role check. When called with a stdio configuration, those endpoints attempted to connect, which spawned the supplied command as a subprocess on the proxy host with the privileges of the proxy process. NVD lists affected versions from 1.74.2 up to, but excluding, 1.83.7.

CVE-2026-35029 describes a different gap. Before version 1.83.0, the /config/update endpoint did not enforce admin role authorization. An already-authenticated user could modify proxy configuration and environment variables, register custom pass-through endpoint handlers pointing to attacker-controlled Python code, read arbitrary server files, and take over other privileged accounts.

Neither entry is a criticism of the project's design intent. Both are reminders that a valid key is an identity signal and not a permission model. Platform teams should verify both layers independently.

Treat the proxy host as a privileged control plane

Because configuration changes alter how requests are handled, the proxy's admin and configuration endpoints belong to the enforcement surface itself. If configuration can be changed by an ordinary authenticated user, every downstream policy decision is only as trustworthy as the weakest key.

Three practical steps follow from the two advisories. First, check deployed versions against the affected ranges: at least 1.74.2 and below 1.83.7 for CVE-2026-42271, and below 1.83.0 for CVE-2026-35029. Follow the NVD-listed mitigation guidance, which includes discontinuing use if mitigations are unavailable. Second, review who holds valid proxy API keys, since in affected versions any valid key was enough to reach the endpoints in the first advisory. Third, restrict the proxy process's privileges, because a spawned subprocess runs with those privileges.

Also monitor for changes to proxy configuration, environment variables, and registered pass-through handlers. An auditor will reasonably ask what shows that the control layer cannot be altered by ordinary users, and change records for the layer are part of that answer.

• Compare deployed versions with the NVD affected ranges
• Inventory and review holders of valid proxy API keys
• Run the proxy process with minimal privileges
• Record changes to configuration, environment variables, and pass-through handlers

Sorting control areas by who owns the work

The table sorts each control area by where engineering effort usually lands when a gateway serves as the shared entry point. Treat it as a planning template. Confirm each row against the documentation for the version and tier you deploy before relying on it.

• Authentication and key management: Proxy-enforced: validating a proxy API key on each request. Yours: key issuance, rotation, ownership review, and revocation processes.
• Authorization: Extension work: role-level checks on admin and configuration endpoints must be verified, not assumed. Yours: privileged access review and evidence.
• Rate limiting and budgets: Typically a gateway-level access control. Yours: deciding limits per team, model, and use case, and tying them to policy.
• Content-level policy: Extension work: redact and block decisions need organization-specific rules applied consistently across every model.
• Tool and MCP call control: Left to the adopting team: allow or deny decisions on individual tool calls, based on who is calling, what is requested, and the data involved.
• Escalation and evidence: Left to the adopting team: human approval workflows, tamper-resistant records, retention, and data residency handling.

Content policy and tool calls need decisions, not just hooks

Content-level enforcement has two parts: a mechanism and a policy. A gateway can offer places to attach checks before or after a model call. The policy still has to be written: which data classes must be redacted, which requests must be blocked, and what differs by team, model, or provider. Applying that consistently across many models is the engineering work, and it needs an owner who can change rules without redeploying every consumer.

Tool calls and MCP servers raise the stakes. A model response that triggers a tool is an action, not text. Per-call policy has to evaluate the specific tool, its arguments, the calling identity, and the context, then return a decision such as allow, redact, block, or escalate. Key-level access to a gateway does not make that decision. Configuring which servers are reachable is a coarser control than deciding whether this call, with these arguments, should proceed.

The settled-standards question also applies here. A January 2026 Federal Register request for information asks what technical controls, processes, and practices could ensure or improve the security of AI agent systems, and how mature those methods are. Teams should expect to make design choices without a finished reference architecture.

Escalation and audit-ready evidence

Human approval is a workflow, not a flag. It needs a defined trigger, a routing target, a timeout behavior, and a record of who decided what. The NIST AI RMF MAP 2.2 excerpt points to documenting how system output may be utilized and overseen by humans, so the oversight process should exist on paper and in the execution path.

Evidence is the area where teams most often underestimate effort. Request logs and spend records show that traffic occurred. Auditors typically want to see which policy applied, what decision was made, and whether the record could have been altered afterward. That implies four design requirements regardless of tooling: records that capture the decision and not only the request, protection against modification, retention periods set by your obligations, and storage in the regions your data residency rules require.

The advisories above add one more requirement. Evidence about the control layer itself, such as configuration history and privileged access, belongs in the same record set as evidence about the traffic it handled.