gentic news

Posted on Jul 1 • Originally published at gentic.news

3 MCP Gateway Security Gaps LiteLLM's Audit Found (And How to Fix Them in

#ai #opensource #programming #machinelearning

LiteLLM's audit revealed 3 MCP gateway gaps: fail-open resolver, unpinned servers, opt-in least-privilege. Fix them in Claude Code with version pinning and allowed_tools.

Key Takeaways

LiteLLM's audit revealed 3 MCP gateway gaps: fail-open resolver, unpinned servers, opt-in least-privilege.
Fix them in Claude Code with version pinning and allowed_tools.

The Audit That Found What 'Does It Work?' Misses

Most teams wiring an LLM gateway to MCP tools ask one question: does it work? A production-readiness audit of LiteLLM—a widely deployed open-source LLM proxy—showed that question isn't enough. The real test is: when the authorization check throws an unexpected exception, does the gateway deny the call or allow it?

That single line of behavior separates a mature platform from an incident waiting for a quiet Tuesday.

The audit, run by Willian Pinho, scored LiteLLM across seven dimensions: tool-access governance, fail-close behavior, MCP onboarding, observability, multi-LLM routing, secrets, and production-readiness. Result: four green, three yellow, zero red. "Production-ready with caveats."

Here are the three yellow flags—and exactly how to fix them in your Claude Code setup.

Yellow #1: The Fail-Open Authorization Resolver

Every per-level permission resolver in LiteLLM fails closed: on an unexpected exception it logs and returns an empty set, which resolves to "no access" downstream. That's the correct posture.

The exception is the top-level wrapper get_allowed_mcp_servers(), which returns the allow-all server set on an unexpected error instead of an empty list. The blast radius is bounded to servers an operator already marked as public, but fail-open in an authorization resolver is the single highest-risk class in the framework.

The fix: Patch that one function to return an empty set on exception. It's a one-line change plus a regression test.

Yellow #2: Unpinned Third-Party MCP Servers

LiteLLM's curated catalog launches stdio servers with floating commands like npx -y @sentry/mcp-server, with no version, digest, or checksum pin. That's a tampered-package away from a supply-chain incident—OWASP's LLM03.

The fix in Claude Code: When you add MCP servers to your claude_code_mcp_config.json, always pin the version and digest. For example:

{
  "mcpServers": {
    "sentry": {
      "command": "npx",
      "args": ["@sentry/mcp-server@1.2.3"]
    }
  }
}

Use @1.2.3 instead of @latest. Better yet, use a checksum or digest if available. Reject any server that doesn't provide a versioned release.

Yellow #3: Per-Tool Least-Privilege is Opt-In

Authorization at the gateway is strong—enforced on caller identity as a strict intersection of key, team, end-user, agent, and org permissions, and the model is kept out of the authorization decision entirely. That defeats prompt-injection-to-tool-call.

But absent a per-server allowed_tools allowlist, any caller with access to a server can invoke any tool on it, including write or external ones—the excessive-agency exposure OWASP tracks as LLM06.

The fix in Claude Code: Add an allowed_tools field to each MCP server definition in your config. For example:

{
  "mcpServers": {
    "database": {
      "command": "node",
      "args": ["server.js"],
      "allowed_tools": ["query", "schema_list"]
    }
  }
}

This prevents a compromised agent from calling drop_table or delete_all. Make this allowlist required at onboarding and validated in CI.

What LiteLLM Got Right (So You Know What to Keep)

Identity and secrets: Green. No inline secrets. JWT/OIDC enforced on the actual gateway call path. End-user identity propagates through to MCP handling and spend logs. For MCP tokens, the gateway supports RFC 8693 OAuth token-exchange with audience and scope binding.
Observability: Green. OpenTelemetry with dedicated GenAI semantic-convention mapping. Inbound W3C traceparent headers extracted through the standard propagator.
Routing and cost: Green. Budget caps genuinely enforced—overrun raises BudgetExceededError rather than firing an alert and letting spend continue.

The Lesson for Claude Code Users

A structured audit isn't a search for a smoking gun. On a mature target there usually isn't one. What the seven-dimension pass surfaced were the production-readiness edges that hide in a good codebase: one resolver that errs toward exposure, a supply chain that floats instead of pinning, and a least-privilege control that waits for someone to opt in.

None of these show up when you ask "does it work?" because the gateway works fine. They show up when you ask what happens at the boundaries, under error, and at the defaults most operators never change.

Action items for your Claude Code deployment:

Audit your MCP server config for unpinned versions—pin them all.
Add allowed_tools allowlists to every server.
Test what happens when your authorization resolver fails (it should deny, not allow).
Enable OIDC/JWT on the call path, not just the dashboard.
Verify end-to-end trace continuity with W3C trace context.

The audit kit that produced this runs read-only in Claude Code. If you're putting an MCP gateway in front of production tools, run the same seven-dimension pass on your own deployment.

Sources

[Updated 01 Jul via devto_mcp]

A separate production post from Sahajmeet Kaur describes three real-world MCP governance failures that mirror LiteLLM's audit findings: a support agent created 47 duplicate Jira tickets via a write-enabled MCP server; a contractor's Jira MCP token remained active three weeks after offboarding because MCP credentials weren't in the standard checklist; and a research agent executed injected instructions from a web-fetch tool [per Sahajmeet Kaur]. The post advocates for four control walls—tool-level RBAC, centralized credential management with single-token offboarding, per-invocation audit trails, and content guardrails—implemented via a central gateway rather than relying on the MCP protocol itself.

Originally published on gentic.news

DEV Community