Enterprise MCP governance outgrows LLM proxy controls in 2026

At a glance

What this is: This is a how-to analysis of why enterprise teams move beyond LiteLLM toward an MCP platform when AI workloads need governed tool access, per-request identity, and Kubernetes-native operations.

Why it matters: It matters because IAM, PAM, and platform security teams need to govern AI agents and tool use as identity problems, not just as LLM routing problems.

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.

👉 Read Stacklok's analysis of enterprise MCP governance beyond LiteLLM

Context

MCP governance is the control problem here, not LLM routing. LiteLLM is useful when the requirement is simple provider abstraction, but enterprise programmes eventually run into identity, audit, isolation, and lifecycle questions that a proxy was never designed to answer.

In practice, the gap appears when teams need per-request identity, budget enforcement at the infrastructure layer, governed tool access for agents, and container boundaries that prevent one session or namespace from expanding its blast radius into another. That is the point where LLM proxy thinking stops matching the operational reality of agentic AI.

For security leaders, the central question is whether the platform can prove who authorised each tool invocation, what data or services were reached, and how policy is enforced across Kubernetes-native deployments. That is an IAM and NHI governance question as much as an infrastructure question.

Key questions

Q: How should security teams govern AI agents that call internal tools from Kubernetes?

A: They should separate runtime containment from identity governance. Kubernetes can isolate execution, but the tool boundary still needs delegated identity, per-request authorization, and action-level logging. Without those controls, the agent behaves like an unscoped service account with model-driven output, which makes attribution and revocation much harder.

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. At that point, the organisation is no longer just routing model calls. It is governing non-human access paths that require identity controls.

Q: What breaks when shared proxy credentials are used for AI workloads?

A: Shared proxy credentials break auditability, containment, and accountability. They make it difficult to prove which identity authorised a call, which agent or team consumed the resource, and whether one session could influence another. That creates governance debt that grows as agents and tool servers proliferate.

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.

Technical breakdown

Why an LLM proxy is not an MCP governance layer

An LLM proxy normalises calls across model providers, but it does not govern the tool layer that agents use to reach data and actions. MCP introduces a separate control plane for tool registration, request authorisation, and scoped access to external systems. That distinction matters because an agent can be well-routed at the model layer and still be over-privileged at the tool layer. A proxy that only handles API calls cannot express which MCP server may be invoked, which data source is in scope, or whether the request should be denied by policy.

Practical implication: Separate model routing from tool governance and treat MCP access as a distinct authorisation domain.

Per-request identity changes the credential model

Enterprise MCP architectures replace shared upstream keys with per-request identity tokens issued through OIDC or OAuth 2.0. That means the authorisation decision happens at call time, the identity is resolved at the edge, and the audit trail can bind each tool invocation to a subject. The practical difference is that the platform can avoid exposing upstream credentials to the calling session and can log a verifiable identity for each action. In governance terms, this is a shift from stored secret mediation to request-scoped identity enforcement.

Practical implication: Require request-scoped identity resolution and auditability for every agent tool call.

Why container isolation matters for multi-tenant AI workloads

A single shared proxy process creates a shared blast radius when multiple teams, agents, or tool servers use the same runtime. Container-per-server isolation reduces the chance that one compromised session, runaway process, or misconfigured server can move laterally into another tenant’s environment. In Kubernetes, this becomes a platform design choice rather than a hardening afterthought. It also aligns runtime separation with the way security teams already think about namespace boundaries, service segmentation, and workload ownership.

Practical implication: Use workload isolation and namespace-aware policy to prevent one agent or tool server from affecting others.

NHI Mgmt Group analysis

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.

Per-request identity is the decisive control change for AI agents: the moment an agent can reach tools, databases, and internal services, shared keys become a governance liability. Binding each request to a resolved identity through OIDC or OAuth 2.0 turns agent activity into something audit teams can actually reconstruct. The implication is that AI infrastructure must be designed around verifiable subject identity, not reusable proxy credentials.

Container isolation is identity containment, not just runtime hygiene: multi-tenant AI platforms fail when one session can influence another through shared process or filesystem scope. Isolated MCP servers reduce the blast radius of credential misuse and policy failure, which is why workload identity and runtime separation now belong in the same design conversation. Security teams should stop treating isolation as a platform detail and start treating it as identity boundary enforcement.

Platform engineering now owns AI governance, and that changes the control surface: when AI workloads move into Kubernetes, GitOps, CRDs, metrics, and namespace policy become part of identity enforcement. This is the same lifecycle problem IAM teams already manage for other non-human identities, but the control plane is now built around agents, tool registries, and request-scoped authorisation. Enterprises need governance models that match that operating reality.

Ephemeral credential trust debt: shared proxy secrets and virtual keys create an assumption that a credential can safely persist long enough to be reused across calls, teams, and sessions. That assumption fails when AI agents need scoped, per-request access to tools and data, because the reuse window becomes the vulnerability. The implication is that enterprises should measure how much trust they are still extending to static proxy-mediated credentials.

From our research:

• 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.
• For related governance depth, OWASP Agentic Applications Top 10 provides the control categories practitioners should map to agent tool access.

What this signals

Ephemeral credential trust debt: enterprise AI platforms are accumulating governance risk wherever static proxy credentials, shared keys, and virtual keys are still being reused across requests. The control issue is not just exposure, but duration. When access paths are long-lived, audit gaps and lateral movement opportunities become structural rather than exceptional.

The reader-level implication is that platform teams should align agent governance with NIST Cybersecurity Framework 2.0 and treat identity resolution, isolation, and audit trails as operational requirements, not optional hardening. If an organisation cannot prove who authorised a tool call, it does not yet have mature MCP governance.

The forward signal is that tool access governance will become a core identity workstream, not an AI add-on. As agent use scales, organisations will need lifecycle controls, namespace boundaries, and policy enforcement that map cleanly to the way non-human identities are created, constrained, observed, and retired.

For practitioners

• 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. If a single proxy is doing all three jobs, split the control domains before agent sprawl creates hidden privilege paths.
• 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. Do not let calling sessions reach upstream credentials stored in shared proxy databases.
• 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. Treat isolation failure as a blast-radius problem, not just a hardening issue.
• Move budget enforcement into the platform layer Set policy at the gateway or authorisation layer so team-level spend cutoffs and request denials happen before model execution. If cost attribution still depends on custom application code, the governance model is not mature enough for enterprise use.
• Audit lifecycle ownership for AI agents and tool servers Assign clear ownership for onboarding, policy review, secret issuance, revocation, and decommissioning across agent identities and MCP servers. Unowned lifecycle events are where access outlives the business purpose that justified it.

Key takeaways

• Enterprise AI governance breaks when teams rely on model proxies that do not control tool access, identity resolution, or workload isolation.
• The most material risk is not LLM routing itself, but the governance debt created by shared credentials, weak audit trails, and multi-tenant blast radius.
• Practitioners should evaluate MCP platforms on request-scoped identity, Kubernetes-native lifecycle control, and container isolation, not on proxy convenience alone.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Per-Request Identity: Per-request identity means each call carries a verified enterprise identity that can be authorised, logged, and audited individually. For agentic systems, this is more useful than shared proxy credentials because it ties tool use to a subject, not to an opaque session or virtual key.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Ephemeral Credential Trust Debt: Ephemeral credential trust debt is the hidden risk that appears when short-lived tokens create a false sense of safety while permissions remain broad. The credential expires quickly, but the underlying blast radius stays large unless identity scope, revocation, and audit controls are also tightened.

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.

👉 Stacklok's full post covers Kubernetes-native deployment, request identity, and audit control details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.