Adding Model Context Protocol Permissions to a LiteLLM Proxy

Why MCP access needs its own permission model

MCP servers behave differently from conventional APIs. OWASP's secure MCP development guidance notes that they operate with delegated user permissions, dynamic tool-based architectures and chained tool calls, which increases the potential impact of a single vulnerability. A model that can call one tool can often reach others through the results of the first call.

When model and tool traffic share one LiteLLM Proxy, the proxy becomes the natural place to decide who reaches what. That is useful, but it also concentrates risk. A broad grant at the proxy applies to every caller that inherits it, and loosely defined permissions tend to expand over time. OWASP's MCP Top 10 names this as MCP02, Privilege Escalation via Scope Creep.

The practical consequence is that server access, tool access, credentials and evidence are separate problems. Treating them as one setting is how MCP access ends up either over-permissive or assembled from ad hoc configuration that nobody can audit.

Step 1: Register servers and scope key and team access

Start from deny-by-default. Register each MCP server individually, and give each one the minimum permissions its function needs. OWASP's MCP Security Cheat Sheet recommends exactly this, and it advises against sharing broad credentials across servers.

Then map callers to servers. Virtual keys identify applications or services, teams group them, and users sit behind both. Decide which level owns the grant. Team-level grants are easier to review but tend to be broader. Key-level grants are tighter but multiply the number of entries to maintain. A workable pattern is to grant at team level for shared, low-risk servers and at key level for anything that can write, delete or send data externally.

Write the decision down for each server: owner, purpose, permitted teams and keys, and review date. That record is what makes periodic recertification possible, which is the direct countermeasure to scope creep.

• Register each MCP server separately with its own minimal permission set
• Grant access by key or team, starting from no access
• Record an owner and a review date for every grant
• Keep administrative and stdio-capable endpoints off ordinary caller paths

Step 2: Scope permissions per tool

Server-level access is too coarse for most cases. A single MCP server may expose read tools and write tools, and a caller that needs one rarely needs the other. OWASP's AI Agent Security Cheat Sheet recommends granting agents the minimum tools required for their task and applying least privilege to all agent tools and permissions. In practice that means an allow-list of tools per caller, not a block-list of known-dangerous ones, so that new tools added to a server are not exposed automatically.

Tool scoping also limits the damage from prompt injection. OWASP lists direct and indirect injection as a threat: malicious instructions in user input or external content such as web pages, documents and emails can hijack agent behavior. A tool allow-list does not stop the injection, but it bounds what a manipulated model can do. Test this directly. Feed the agent content containing hostile instructions and confirm it cannot reach tools outside its scope.

Be clear about the limit of allow-lists. They decide whether a tool may be called, not whether a particular call with particular arguments is appropriate. Argument-level decisions, such as which record or which recipient, need inspection at call time.

Step 3: Handle identity and credentials deliberately

The proxy sits between the caller and the MCP server, so the server sees the proxy unless identity is carried through. There are two broad designs. In the first, the proxy authenticates to each server with a shared service credential. This is simple, but every caller then acts with the same authority on the server, and the server cannot tell them apart. In the second, the proxy forwards or exchanges a per-caller credential, so the server can apply its own authorization. This preserves attribution but adds token handling the proxy must do correctly.

The main risk in both designs is a confused deputy: a component with broad authority acts on behalf of a caller that lacks it. Avoid broad shared credentials, scope any credential to the single server it is meant for, and do not forward a token to a server it was not issued for. For the token flows themselves, follow the MCP authorization specification rather than improvising.

Protect the proxy's own identity layer as carefully. One NVD entry, CVE-2026-114612, describes a proxy flaw in which a forged administrator credential led to arbitrary commands through an MCP stdio endpoint. Whatever product you run, track its security advisories, check deployed versions, and keep stdio-capable endpoints out of reach of ordinary callers.

What to enforce at the proxy and what to leave to the server

Not every control belongs in the same place. The split below is a starting point, and the right answer depends on how much you trust each server and who maintains it.

• Server reachability: Proxy: decides which keys and teams may connect. MCP server: not involved if the proxy blocks the request.
• Tool allow-lists: Proxy: limits which tools a caller may invoke. MCP server: should still refuse operations the credential cannot perform.
• Argument and content inspection: Proxy or execution path: inspects what is sent, for example secrets or personal data. MCP server: validates its own inputs.
• Per-user authorization: Proxy: forwards identity. MCP server: applies delegated user permissions to the data it holds.
• Evidence of the call: Proxy or execution path: records caller, grant and outcome. MCP server: keeps its own operational records.

Step 4: Produce evidence, and where Trussed fits

Regulated teams are eventually asked two questions: what was this caller allowed to do, and what did it do. Answering them requires a record per tool call that includes the caller identity, the permissions in effect at that moment, the tool and arguments, and the outcome. A permission list read today does not prove what applied last quarter, so grants need to be versioned and tied to each recorded call. Configuration plus request logs rarely add up to this without deliberate work.

This is where policy enforcement in the execution path becomes a separate evaluation item. Trussed is one option. It enforces policy at runtime on individual tool calls, including calls to MCP servers: allow, redact, block, rate limit, or escalate for human approval. Enforcement happens in the path, not reviewed after the fact, and it generates audit-ready evidence mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. It can be deployed self-managed in the customer cloud, with configurable retention and data residency, and has run in continuous production in a regulated enterprise for more than 18 months.

Whichever approach you choose, evaluate it on four points: whether decisions are made per tool call, whether human escalation is supported for high-impact actions, whether evidence is durable and attributable to an identity, and whether the data stays in your environment.