Least Common Mechanism in Shared MCP Deployments

MCP is infrastructure now, not an experiment, and most organizations building on it haven't caught up to what that means for isolation. Anthropic's ecosystem numbers tell the story: tens of thousands of active public servers, SDK downloads in the tens of millions per month, GitHub MCP repositories growing several hundred percent in roughly a year. Stacklok's 2026 software report found over 40% of surveyed organizations already running MCP servers in limited or broad production. That's a fast adoption curve for a protocol that launched with essentially no authentication framework.

What a shared MCP deployment actually looks like on the ground is consistent enough that I stopped being surprised by it. An enterprise team centralizes internal tooling behind one server to cut operational overhead. A SaaS vendor exposes a single hosted server to all their customers. A platform team hands multiple internal squads access to the same tool registry. The motivation is always legitimate. Efficiency, velocity, less duplication. The structural problem shows up later, usually when something breaks.

The MCP specification was designed to prioritize interoperability. Isolation was left to individual implementations, and that was not a small omission. Nothing in the protocol defines how to scope tool access per tenant, how to prevent cross-tenant data access, how to audit which tenant's data a given invocation actually touched, or how to enforce data residency per principal. These aren't edge cases. They're foundational requirements of any multi-tenant system. Scale arrived before isolation primitives did, and most organizations are discovering that gap only after it costs them something.

Shared Credentials as the Most Structurally Obvious LCM Failure

Over half of open-source MCP server implementations analyzed in recent security research rely on static credentials: API keys and personal access tokens rather than OAuth, long-lived, rarely rotated, typically stored in environment variables or.env files. I've seen this enough times that the surprise is gone. The implications still matter enough to say plainly.

Shared credentials mean every agent and every user in the deployment accesses the resource through the same identity. That's a shared mechanism in the exact sense Saltzer and Schroeder described. There's no per-principal audit trail, so reconstructing who did what after an incident is largely guesswork. A leaked credential grants access to every user's tools, not just the one that was compromised. And rotating that credential, which is the only real remediation, is disruptive enough that it frequently doesn't happen quickly, so the exposure window stretches longer than it should.

How we got here makes sense if you remember the timeline. MCP launched with no authentication framework at all. OAuth 2.0 support came several months later, then refined again after that. By the time any auth standard existed, the ecosystem had already scaled substantially with zero authentication baked in. The shared-credential pattern calcified before anyone had a principled alternative ready, and inertia did the rest.

The LCM correction isn't a stronger password on the shared credential. It's a per-principal credential: scoped, audience-bound, individually revocable. The goal is simple. Revoking one principal's access should affect only that principal.

Token Passthrough: When the Shared-Credential Failure Travels Across Service Boundaries

The MCP specification is explicit here, and implementations frequently ignore it anyway. Servers must not accept tokens that were not issued specifically for them. When a server calls an upstream API, the upstream token must be separately issued by the upstream authorization server. The spec says this. The gap between what the spec requires and what gets deployed is where the real risk lives.

Token passthrough is probably the most common enterprise design failure I encounter in MCP deployments. A token issued for Service A gets forwarded raw to Service B, where it now functions as a credential across an authorization context it was never scoped for. One leaked token becomes a skeleton key for the chain. Rate limits keyed on audience get bypassed because the downstream sees a token issued for a different principal. The audit trail records the wrong identity, and the actual actor is invisible to anyone reviewing logs after the fact.

This is the confused-deputy problem, formulated by Norm Hardy in the late 1980s, expressed in MCP terms. A downstream agent holding broad authority gets directed by a less-privileged or malicious party to exercise that authority on the attacker's behalf. The agent isn't compromised in any traditional sense; it's functioning correctly, just on behalf of someone who shouldn't have access to what it can reach.

Invariant Labs documented a concrete version of this: an agent holding a single token spanning both public and private GitHub repositories was steered by a malicious public issue into reading private-repo data. One over-scoped, reused credential crossing a trust boundary. That's the whole story. The fix is audience-bound, purpose-scoped tokens issued per server per invocation context, never forwarded raw.

Session State and Context Windows as Hidden Shared Mechanisms

Early MCP spec versions introduced session IDs that pinned a client to whichever instance handled its initialization handshake. Horizontal scaling then required either session affinity or real cross-instance state sharing, both of which concentrate shared state in ways that create LCM exposure. Later spec revisions moved to stateless HTTP transport, which helped at the transport layer. It didn't resolve isolation at the data layer, which is where the harder problem actually lives.

The context window gets less attention than credentials, and it deserves more. In a multi-user or multi-tenant agent, every tool response, every document retrieval, every query result lives in the same context window for the duration of that session. There's no protocol-level boundary separating one user's retrieved data from another's. A single agent serving multiple users can surface one user's personally identifiable information into another user's response if context isn't explicitly flushed and scoped between interactions. I've seen this surface in support conversations in ways that are genuinely uncomfortable for everyone involved, including the customers who piece together what they're actually looking at.

Long-lived memory features compound this. Agent memory stores that persist across sessions can carry data from one session into a future one, so a prior user's context contaminates a subsequent user's experience. This isn't hypothetical; cross-tenant context exposure has been documented in early MCP deployments. Mitigation requires scoped context windows, ephemeral memory by default, and isolation enforced at the protocol or gateway layer rather than delegated to application logic, because application logic is inconsistent by nature.

What session isolation actually demands, framed through LCM: not just ending a session cleanly, but ensuring no state channel persists between principals who should be mutually untrusted.

Ambient Tool Authority and the Shared Registry Problem

When an agent connects to an MCP server, OAuth scopes authorize the session against the server's entire tool surface. There's no per-invocation scoping in the base protocol. An agent connected to ten MCP servers holds the union of all permissions granted across all ten: ambient authority that grows with each new connection, regardless of what any individual task actually requires.

Ambient authority is a shared mechanism in LCM terms. The tool registry is a common resource every connected agent draws from, and no agent's authority over it is individually scoped to its actual task. A coding agent that needs to read one file for context holds read permission over every file the tool allows, not just the relevant one. If two agents share a server, one agent's over-broad permissions become a vector for the other to exploit through prompt injection or tool chaining. This is the obvious attack surface, not a subtle one.

The shared tool registry, without a scoped view per tenant or per agent, means every new server added to the deployment expands the attack surface for all connected agents simultaneously. Adding tooling is supposed to be additive; under ambient authority, it's also multiplicative in terms of exposure. Those aren't the same thing, and conflating them is how deployments accumulate risk they don't notice until they're auditing an incident.

LCM demands the inverse. Each agent should see only the tools it has an affirmative reason to use, scoped at connection time, not inherited by default. Authority should be conferred explicitly, not assumed.

What LCM Failures Look Like When They Reach Production

These aren't theoretical risks. They're documented incidents, and the list is long enough now to establish a pattern.

The Asana MCP incident is the most thoroughly documented multi-tenant isolation failure in MCP deployments so far. A logic flaw in Asana's MCP server caused data from one customer's instance to surface in other organizations' AI assistants. Roughly a thousand customers were potentially affected, and the feature stayed offline for approximately two weeks while the issue was addressed. The root cause was state that should have been scoped per organization leaking across request boundaries: a textbook shared-mechanism failure where tenant context wasn't isolated at the session layer.

A privilege escalation via MCP in the WordPress AI Engine plugin affected more than 100,000 sites before a patch was issued. The Invariant Labs GitHub incident, already covered in the token section, is worth anchoring here as a production incident: an over-scoped token crossing a trust boundary, exploited through a malicious public issue to access private repository data.

The Postmark MCP supply chain incident is perhaps the most instructive. An unofficial server with meaningful weekly download volume was modified to silently BCC all outgoing emails to an attacker's address. Users of a shared tool with no mechanism to audit tool behavior at the invocation level had no visibility into the exfiltration while it was happening. No one was watching, because the architecture didn't create a place to watch from.

What connects every one of these incidents: the exploited path was a mechanism multiple parties shared and that no single party was responsible for auditing. That isn't a coincidence. That's the structural condition Saltzer and Schroeder were warning against.

Applying LCM to MCP Architecture: The Structural Decisions That Create Isolation

Applying LCM to MCP architecture produces a small set of structural decisions that follow directly from the principle. None are exotic.

Separate server instances per tenant or trust boundary eliminate shared session state and shared tool registry at the most fundamental level. The operational objection is real: more instances mean more overhead. The answer is infrastructure-as-code and automated provisioning, not collapsing isolation to manage overhead. Overhead is an engineering problem you can solve. A shared tenant boundary is an architectural liability that compounds over time.

Scoped tool exposure means each agent or tenant sees only the subset of tools its role actually requires, enforced at connection time. Not a user-level configuration option. The enforcement has to happen at the server or gateway before the session is established, because leaving it to individual agents is leaving it to inconsistency. What an AI agent can do should be a deliberate organizational decision, not an inherited default from whatever servers it happens to connect to.

Per-principal authentication contexts require OAuth 2.1 with audience-bound, purpose-scoped tokens; no shared service accounts; no token passthrough across server boundaries. Each principal needs its own credential, individually revocable without affecting anyone else in the deployment.

Context window isolation requires ephemeral memory by default, explicit flushes between sessions, and no cross-tenant caching of tool responses.

Gateway enforcement ties all of this together as a single control layer, providing real-time visibility into what each agent actually touched rather than relying on each server implementation to get isolation right independently. This is where the LCM caveat from Saltzer and Schroeder's original framing applies: a shared, well-audited gateway is shared infrastructure serving as a control surface, not a data channel. That's precisely what LCM permits and, at scale, requires.

Why a Governed MCP Gateway Is the Practical Implementation of LCM at Scale

Forrester projects that a significant share of enterprise application vendors will ship their own MCP servers before the end of 2026, and a substantial portion of Fortune 500 companies have already deployed them. Governing isolation at each server independently doesn't scale to that volume. Anyone who has tried to audit even a dozen MCP server implementations understands why. The servers proliferate faster than any team can meaningfully evaluate individual codebases.

A centralized gateway is the one place where LCM can be enforced consistently across an entire deployment without depending on each MCP server to get multi-tenant isolation right on its own. It intercepts every agent-to-server request before it reaches a tool. It enforces per-agent, per-tenant, per-tool access policy at the boundary. It produces a real-time record of what each agent accessed: not a log you reconstruct after something breaks, but operational visibility during execution, while you can still act on it.

MCP Manager, built by Usercentrics, is designed around this pattern. Gateway enforcement of access controls, scoped tool exposure per agent, and observability at the invocation level operate as the control layer between agents and the MCP servers they reach. The architecture reflects what LCM actually requires at scale: centralize the control surface, isolate the data paths.

Evaluating any gateway solution as an LCM enforcement point comes down to a specific set of criteria. Per-agent identity and authentication context, not shared service accounts. A registry of all connected MCP servers, where every server must have a registered identity before an agent can reach it. Real-time invocation logging with enough fidelity to reconstruct what data each agent touched in each session. Policy enforcement at the gateway itself, not delegated downstream where it can be quietly bypassed.

Teams that build these guardrails tend to approve new MCP server connections faster, not slower. They have a principled basis for the decision. Governance, done right, is the mechanism that lets an organization say yes with confidence, not the reason it stalls.

What "Governed" Actually Means in a Shared MCP Deployment

A governed shared MCP deployment is one where every mechanism two parties share was a deliberate decision, not an architectural accident.

It means every shared component was evaluated for whether it constitutes a data channel between principals who should be isolated. Where that evaluation produced a yes, the sharing was either eliminated or controlled. Shared control surfaces, like a gateway or a common authorization library, are maintained with visibility and clear accountability. Shared data channels, like a common credential, a shared context window, or a single tool registry without scoped views, are treated as the liabilities they are, not as conveniences.

Saltzer and Schroeder's formulation is still the clearest way to state the goal: minimize the mechanism common to more than one user. With MCP deployments scaling faster than any security baseline the ecosystem could set, that principle isn't a design preference or a compliance checkbox. It's the structural criterion that separates deployments that can be audited and trusted from ones quietly accumulating exposure no one is measuring yet.

The incidents already in the record show what happens when shared mechanisms go unexamined. The organizations doing the LCM analysis before something breaks are also the ones with the shortest path from "new MCP server" to "approved for production." That's the return on doing this right.