MCP Server Security in Multi-Tenant Environments

MCP adoption's outpacing of security infrastructure

One deployed MCP server can handle every tenant's AI agent traffic at once, sharing the same infrastructure while keeping credentials, tool definitions, and context windows fully apart. That separation is the whole game, and it's exactly where most implementations fall down. Get it wrong and one customer's agent ends up reading another customer's data, calling tools with the wrong permissions, or leaking a token that was never supposed to leave the building.

Picture an apartment building. The plumbing and wiring run through shared walls, but every unit still needs its own lock and its own key. Nobody inspects an MCP deployment the way a building inspector walks a construction site, though. If a team didn't build tenant isolation on purpose, it doesn't exist. Nobody finds out until the wrong tenant's agent pulls up a project it was never supposed to see.

Most engineering teams still think in single-tenant terms, because that's how the first wave of MCP servers got built. Credentials get baked into environment variables at boot. There's no need for namespace separation when it's one agent talking to one set of permissions. Authentication gets treated as the upstream API's job, not something the MCP layer has to handle.

None of that holds once a server starts serving more than one tenant. Three isolation layers appear that a normal API almost never has to think about: tool definitions, context windows, and per-tenant credential vaults. The MCP spec is stateless by design, so any context spanning multiple calls has to live in whatever layer the implementer builds on top, and that layer has to be tenant-scoped from day one. Authentication and authorization aren't even the protocol's job to begin with. The spec says so directly: the exact mechanism for authenticating and authorizing requests sits outside its scope. That's a deliberate choice, and it hands the hardest part of the job to whoever builds the server.

The growth curve backing all this is steep by any measure. SDK downloads are running past 97 million a month, more than 10,000 active servers are out in the wild, and client support now spans ChatGPT, Claude, Cursor, and other major AI platforms. This is infrastructure now, full stop, not some niche protocol a handful of teams are experimenting with.

Wiz Research found MCP servers running in at least 80% of the cloud environments it scanned, and 5% of those environments had at least one MCP server exposed directly to the internet. That's a meaningful chunk of production infrastructure running a protocol that, by its own spec, doesn't require authentication.

The NSA addressed this directly. Its May 2026 Cybersecurity Information Sheet on MCP centered on the gap between how fast the protocol is being adopted and the security controls in place to protect it. That's the government's own security arm confirming what the vulnerability data already shows.

What's actually missing at the protocol level comes down to four gaps, and each one lands hard:

• No required authentication. It's optional, and plenty of servers skip it.
• No defined way to map a session to a verifiable identity.
• No role-based access control built into the protocol itself.
• No enforced session expiry, which opens the door to replay attacks and reuse of old sessions.

Every one of those gaps has to be closed by whoever builds the server. The protocol won't do it for anyone.

The documented vulnerability landscape: what attacks on MCP infrastructure look like

Credentials cause the most damage on this list, and they're also the easiest fix, so start there. Astrix Security looked at 5,200 open-source MCP server implementations and found that 53% of them rely on static credentials, meaning API keys and personal access tokens, instead of OAuth. Those keys sit in environment variables and typically go unrotated for extended periods. That exact failure mode causes two of the incidents below: because static credentials sit unrotated for months, they create the conditions those incidents exploit.

Command injection dominates the CVE data, and it isn't close. Of the 30-plus MCP-related CVEs filed in early 2026, 43% involved command injection: a single, well-understood vulnerability class that keeps recurring because MCP servers often pass user or agent input straight into shell commands or subprocess calls without sanitizing any of it.

Two supply chain incidents show what happens when that risk hits a shared server instead of a single-tenant one.

The maintainer of the official Postmark MCP server added BCC logic that silently copied every outgoing email to an attacker-controlled address before the backdoor was caught and disclosed. The attack surface opened the moment the tool description entered the model's context. The poison wasn't sitting in a code path a human would normally audit, it was in the text the AI reads to decide what the tool does.

Smithery had a path-traversal bug in its deployment platform that exposed an overprivileged deployment token, one that granted access to more than 3,000 hosted MCP applications and their customers' API keys. No evidence of malicious exploitation appeared before the fix shipped, which is the good outcome here. But the blast radius the bug could have reached shows what's at stake when one credential sits upstream of thousands of tenants.

Cross-tenant leakage has already happened in production, not just in some lab writeup. In June 2025, Asana's MCP server integration failed at cross-tenant isolation, and one organization's projects were potentially exposed to another. Asana pulled the feature offline for close to two weeks while it fixed the underlying issue and reset every user connection. The pattern behind failures like this one is well understood by now: session context that never gets cleared between requests lets one tenant's data bleed into the next tenant's session, and a developer who forgets a tenant filter in a database query can hand one customer's records to another customer's search results with a single missing WHERE clause.

The threat classes that matter most when tenants share a server

Four threat classes recur once multiple tenants share infrastructure. None of them are unique to MCP in concept, but MCP's design, models trusting tool descriptions as operational truth, gives each one a fresh way in.

Tool poisoning and rug-pulls are at the top of the list. A tool description, parameter schema, or even a response can carry instructions the model treats as trustworthy context, and MCP has no built-in way to catch that. Invariant Labs demonstrated this in April 2025: a single poisoned tool description exfiltrated SSH private keys and MCP configuration files with zero user interaction required. A separate prompt-injection technique also demonstrated exfiltration of data from a private repository. OWASP's MCP Top 10 lists this as MCP03:2025, grouped with rug pulls and tool shadowing under attacks on the capability supply chain. The rug-pull variant is sneakier still. CVE-2025-54136 documented a case in Cursor IDE's MCP tooling where a tool looked completely legitimate at the moment a user approved it, then changed its own description on a later run. In a shared server, a single poisoned tool description doesn't just fool one user, it poisons the reasoning context for every tenant whose agent calls that tool.

Tool shadowing works differently but ends up just as dangerous. A malicious MCP service can register a tool using the exact same name as a legitimate one, and without namespace isolation or some way to verify the source, the client might call the fake version instead. The malicious tool then buries "global rules" inside its own description, and the model treats those rules as system-level preconditions that apply to other tools too. Multiple tenants sharing one reasoning context means this kind of semantic poisoning doesn't stay contained. It crosses tenant lines without anyone noticing.

Confused deputy attacks through OAuth proxies happen when an MCP server holding broad, ambient authority gets tricked into acting on behalf of someone it was never supposed to serve. This is why the June 2025 MCP spec update prohibits token passthrough: forwarding an upstream token to a downstream service means that service ends up trusting a credential it was never issued to see. In a shared server this gets especially dangerous, since a confused deputy can redirect one tenant's elevated credentials toward another tenant's connected systems.

Cross-tenant session bleed is the one threat on this list that's specific to multi-tenant setups. A single-tenant server has no other tenant's context sitting nearby to leak into, so the risk simply doesn't exist there. It appears in two forms: session context that doesn't get cleared between requests, letting one tenant's state linger into the next tenant's session, and a missing tenant filter in a query, where a single overlooked WHERE clause hands one tenant's records to another tenant's results.

Authentication and credential architecture that separates tenants

Fixing credentials comes first, because it's both the most common failure and the most fixable one on the table. That 53% figure, open-source MCP servers running on static API keys or personal access tokens instead of OAuth, is the exact weakness the Smithery incident ran into. Static keys don't rotate, they sit in plaintext environment variables, and they never expire on their own. Closing off just this one issue removes a huge share of the realistic attack surface.

OAuth 2.1 with PKCE is the required authorization framework for remote MCP servers under the current spec, and that hasn't changed. What has changed is Dynamic Client Registration, now deprecated in favor of Client ID Metadata Documents. Teams still relying on DCR need to migrate off it soon. CVE-2026-32211, filed against Azure MCP Server, traced back to the auth layer being missing entirely, not misconfigured, just absent from the deployment. The direct fix in cases like that is per-client consent paired with a hard rejection of token passthrough. This isn't only a concern for servers facing the public internet, either: the NSA's May 2026 guidance flags weak or missing authentication as a significant risk in the ecosystem, precisely because it widens the door for unauthorized agents to invoke sensitive tools they were never cleared to touch.

Token passthrough deserves its own callout, since it's the direct defense against confused deputy attacks. The June 2025 spec is explicit on this: when an MCP server needs to call an upstream API, it has to act as its own OAuth client to that service and get a separate token, rather than just forwarding the token it received from the MCP client. RFC 8693 token exchange is one pattern implementations use to pull this off, though the spec does not mandate it as the only option. If this step is skipped, a credential issued for one specific audience can end up reaching systems it was never meant to touch.

Credential opacity is easy to overlook, but it matters just as much. Raw API tokens, refresh tokens, and vendor secrets should never enter the model's context window or the MCP client's visible state. The moment a token appears in a tool-use log, a prompt cache, or an agent trace, it's sitting somewhere built for readability, not secrecy. Worse, a token inside the context window becomes a prompt injection target: a malicious input can trick the model into reading that token back out, or into using it to perform an action nobody authorized.

Authorization, tool scoping, and runtime access control across tenant boundaries

OWASP's MCP Top 10 names two categories that map directly onto everything above. MCP01:2025 covers token mismanagement and secret exposure: hard-coded credentials, tokens that never expire, secrets sitting in model memory or protocol logs where an attacker can pull them out through prompt injection, a compromised context window, or a debug trace nobody thought to lock down.

The second category is excess permissions, and it's the quieter of the two failures. Temporary or loosely scoped permissions inside MCP servers have a way of growing over time instead of shrinking, and agents end up holding far more capability than the task in front of them actually requires. Weak scope enforcement is what turns a narrow, reasonable grant, read this one file, into something that allows repository modification or system-level control nobody signed off on.

The fix, across both categories, comes down to the same discipline every time: scope every tool grant to what the task needs, expire it the moment the task ends, and keep the credential doing the work as far from the model's visible context as the architecture allows. None of that happens by accident. Every gap covered here, from token passthrough to session bleed to a missing tenant filter, traces back to a decision somebody didn't make on purpose. Multi-tenant MCP doesn't really punish bad actors so much as it punishes silence, the security model that never got built.