Enterprise MCP governance outgrows LLM proxy controls in 2026

At a glance

What this is: Stacklok’s analysis says enterprise MCP governance now needs controls that LLM proxies do not provide, including per-request identity, tool policy, isolation, and Kubernetes-native operations.

Why it matters: IAM, platform, and security teams need to know where LLM proxy controls stop, because agentic workflows shift the control point from model routing to governed tool use and auditable identity.

Context

Enterprise MCP governance is the problem of controlling which identities can invoke which tools, under what policy, and with what audit trail across AI workloads. A proxy that only normalises model calls can still leave credential handling, tool authorisation, and tenant isolation outside the governed path.

That gap becomes visible when AI usage moves from single-team experiments to shared infrastructure. The article frames the issue around per-request identity, budget enforcement, MCP tool access, and Kubernetes lifecycle management, which are all operational control points rather than model-routing features.

Key questions

Q: What breaks when an LLM proxy is used for governed MCP tool access?

A: An LLM proxy can still route model calls while leaving tool authorisation, identity resolution, and audit evidence outside the control plane. That creates a gap where teams may think requests are governed even though the platform cannot prove who invoked a tool, what credentials were used, or how far the request could reach.

Q: Why do MCP workloads need per-request identity instead of virtual keys?

A: Per-request identity binds each tool invocation to a resolved subject, which makes policy enforcement and audit records materially stronger than shared virtual keys. Virtual keys help with routing and coarse spend tracking, but they do not by themselves establish who authorised the action or whether upstream credentials stayed hidden from the caller.

Q: How do teams know when LLM proxy controls are no longer enough?

A: The threshold is usually when teams need enforceable tenant isolation, per-agent budget cutoffs, tool-level policy, and a complete audit trail for every invocation. At that point, the proxy is only one layer of the stack, and the real governance problem has moved to workload identity and execution boundaries.

Q: Should enterprises compare MCP governance platforms and LLM proxies as substitutes?

A: No. They address adjacent but different layers: proxies normalise model traffic, while MCP governance controls tool access, runtime isolation, and platform policy. The practical decision is whether the organisation needs both layers, and how much operational debt it can tolerate by keeping them separate.

Technical breakdown

Per-request identity changes the authorisation model for MCP tool calls

An LLM proxy typically sits in front of model APIs and can record usage, but it does not inherently bind each call to a resolved enterprise identity. An MCP governance layer instead treats every request as an authorised action from a known subject, usually via OIDC or OAuth 2.0 against an enterprise IdP. That makes the credential lifecycle part of the platform, not a sidecar database concern. In practice, this matters because the audit question is no longer only what model was called, but which identity authorised a tool invocation and whether the upstream credentials were exposed to the caller.

Practical implication: Design authorisation around resolved identity and per-request issuance, not around virtual keys and shared proxy state.

Container isolation limits blast radius across MCP servers

Stacklok’s article contrasts a single proxy process with isolated containers for each MCP server. That distinction matters because tool servers often touch different data sources, namespaces, and permissions, so one compromised or runaway session should not inherit the whole environment’s trust boundary. Container isolation also changes failure containment for multi-tenant deployments, because filesystem, process, and network scope can be kept separate per server or team. For enterprises running agentic workflows in Kubernetes, isolation is not just a runtime preference; it is a governance control that defines how far a mistake can propagate.

Practical implication: Separate MCP servers by container, namespace, and policy boundary so one workload cannot inherit another’s access scope.

Kubernetes-native lifecycle control is becoming part of AI governance

The article’s Kubernetes Operator, CRDs, and GitOps emphasis shows that platform teams now expect AI infrastructure to behave like other managed services. Declarative configuration matters because MCP gateways, registries, runtime components, and policy objects need versioned change control, repeatable deployment, and observable drift management. A proxy that can run on Kubernetes is not the same as a system designed for Kubernetes operations. The governance issue is whether AI control planes can be owned, audited, and rolled back using the same operational discipline as the rest of the platform stack.

Practical implication: Treat MCP governance objects as declarative infrastructure so policy, registry state, and runtime changes follow the platform’s standard lifecycle.

NHI Mgmt Group analysis

LLM proxy control is the wrong abstraction once agent workloads need governed tool use: The article shows that provider routing and spend tracking do not answer the governance questions enterprises now face. Once agents invoke MCP tools, the primary control surface shifts from model access to identity, policy, and execution scope. That is why proxy-era design cannot be stretched indefinitely without leaving audit and authorisation gaps.

Per-request identity is the point where access control stops being symbolic and becomes evidentiary: A virtual key can route traffic, but it does not by itself prove which identity authorised a tool call. When the platform resolves identity on every request, upstream credentials can be governed at issuance time and audit logs can become meaningful evidence. The practitioner takeaway is that the identity token, not the proxy key, has become the control object.

Identity blast radius is now a platform design problem, not just a secrets problem: The article’s container-per-server model matters because shared proxy processes collapse failure boundaries across teams, namespaces, and tools. If one credential or session is compromised, the containment model determines whether the impact stays local or spreads across the agent estate. That makes isolation, not just rotation, a core governance variable for MCP deployments.

Kubernetes-native governance is becoming the baseline for enterprise AI operations: The article makes a clear case that AI infrastructure is maturing into platform engineering territory. GitOps, CRDs, and observability are no longer optional conveniences once MCP workloads move into production and span multiple teams. Practitioners should read this as a signal that AI governance will increasingly be measured by operational consistency, not by how many model providers a proxy can reach.

Budget enforcement is moving from reporting to control enforcement: Spend visibility alone does not satisfy a finance or platform owner when individual teams or agents can exceed limits. The more mature model is to enforce budget at the platform layer before requests hit the model, with identity-linked attribution and hard cutoffs. That shifts cost governance from retrospective accounting to active policy enforcement across agent workloads.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Identity blast radius: The article points to a control boundary problem that many AI programmes have not yet named explicitly. When MCP servers share a proxy-style runtime, one compromised session can affect unrelated teams unless the platform enforces container and namespace separation.

Enterprises should expect AI governance to shift toward platform engineering patterns, especially when MCP usage spreads beyond one team. That means identity, policy, observability, and lifecycle management will be judged together rather than as isolated controls, and proxy-only designs will increasingly look incomplete.

For practitioners

• Map MCP requests to enterprise identity Require every model or tool request to resolve through OIDC or OAuth 2.0 so the platform can log the authenticated subject and enforce policy per call.
• Separate tool servers by blast radius Run MCP servers in isolated containers with namespace-specific network and filesystem permissions so one server cannot inherit another team’s trust boundary.
• Move budget enforcement into the platform layer Apply team or agent spend limits before requests reach the model, and tie enforcement to identity rather than to a shared virtual key ledger.
• Adopt declarative lifecycle management Manage MCP gateway, registry, runtime, and policy objects through GitOps and Kubernetes-native CRDs so changes are versioned, reviewable, and reversible.

Key takeaways

• Enterprise MCP governance is no longer just about routing model calls. It now depends on identity, tool policy, isolation, and platform lifecycle control.
• A single proxy process can create a shared blast radius that is too coarse for multi-team agent deployments. Container boundaries and declarative operations change that risk profile.
• The practical dividing line is whether an organisation needs audit-grade control over tool invocation and credentials. If it does, proxy controls alone are not enough.

Key terms

• MCP governance: MCP governance is the set of policies, controls, and oversight used to manage how AI agents use the Model Context Protocol to reach tools and data. It defines approved connections, authentication, authorization, logging, data handling, and change control so agent actions remain traceable, bounded, and aligned with security and compliance requirements.
• Per-request identity: An access model in which each tool call carries the initiating user’s identity and authorization context rather than a shared backend credential. For MCP, this is what preserves attribution and reduces the blast radius of server compromise.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Kubernetes-native Lifecycle Management: The practice of deploying and operating infrastructure through declarative Kubernetes resources, versioned changes, and platform workflows. For MCP governance, it means policy, runtime, and registry components can be controlled like any other production service.

Deepen your knowledge

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