TL;DR: Enterprises outgrow LiteLLM when they need per-request identity, container isolation, tool governance, and Kubernetes-native lifecycle controls for MCP workloads, according to Stacklok. The deeper issue is that LLM proxy design does not satisfy governed agent access, auditable credential handling, or platform-level enforcement across teams.
NHIMG editorial — based on content published by Stacklok: Why Enterprises Move Beyond LiteLLM: The Case for an Enterprise MCP Platform in 2026
By the numbers:
- 80% 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.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern AI agents that call internal tools from Kubernetes?
A: They should separate runtime containment from identity governance.
Q: When does an LLM proxy become insufficient for enterprise AI governance?
A: An LLM proxy becomes insufficient when the programme needs per-request identity, tool-level policy enforcement, container isolation, auditability, or lifecycle controls across many agents and teams.
Q: What breaks when shared proxy credentials are used for AI workloads?
A: Shared proxy credentials break auditability, containment, and accountability.
Practitioner guidance
- Map the agent control plane separately from LLM routing Document which systems handle model selection, which handle tool authorisation, and which resolve identity for each request.
- Require per-request identity for every tool invocation Bind each MCP call to a resolved enterprise identity through OIDC or OAuth 2.0 and log the subject, policy decision, and target server.
- Enforce namespace and server isolation in Kubernetes Run MCP servers in isolated containers with minimal permissions, then align network, filesystem, and service access boundaries to namespace ownership.
What's in the full article
Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:
- Specific Kubernetes Operator and CRD deployment model for managing MCP components.
- Per-request OIDC and OAuth 2.0 identity handling details for upstream credential issuance.
- OpenTelemetry and Prometheus integration specifics for audit and observability.
- Platform-level policy examples for token budgets, namespace isolation, and tool registries.
👉 Read Stacklok's analysis of enterprise MCP governance beyond LiteLLM →
MCP governance vs LLM proxies: where enterprise control breaks down?
Explore further
LLM proxies and MCP platforms solve different identity problems: routing model traffic is not the same as governing tool invocation. LiteLLM-style proxies can simplify provider access, but they do not answer the identity question that matters to security teams: who authorised the action, what tool was invoked, and what policy allowed it. Practitioners should treat MCP governance as a separate layer in the identity stack, not as an extension of model routing.
A few things that frame the scale:
- 80% 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, according to AI Agents: The New Attack Surface report.
- 52% of companies can track and audit the data their AI agents access, which leaves 48% with no reliable compliance or breach-investigation visibility.
A question worth separating out:
Q: Should organisations replace LiteLLM with an enterprise MCP platform?
A: Organisations should replace or supplement LiteLLM when their real requirement is governed tool access rather than simple model proxying. If the CISO needs identity-linked audit trails, the platform team needs GitOps and Kubernetes-native lifecycle management, or finance needs enforced team budgets, an MCP platform is the better control surface.
👉 Read our full editorial: Enterprise MCP governance outgrows LLM proxy controls in 2026