Isolation · multi-tenant
MCP Tenant Isolation: Preventing Cross-Tenant Access
The usual pattern is one server, one broad credential, and a tenant id the model passes in. That works until the model infers the tenant from a document containing somebody else’s account number.
The short answer
MCP tenant isolation prevents an agent acting for one tenant from reaching another tenant’s data. The standard pattern — one shared credential with a tenant filter applied from a model-supplied parameter — fails because a language model infers that parameter from context that may contain another tenant’s identifiers. Tenant must be bound to the calling identity and injected by the enforcement point, with any request whose parameter disagrees refused. Four isolation models, five indirect leakage paths, and a ten-minute test that proves it holds.
Key takeaways
- 01A cross-tenant read is not a bug report. It is a disclosure with notification obligations and a customer conversation.
- 02Never let the model choose the tenant. Bind tenant to the token and inject it; refuse any request whose parameter disagrees.
- 03Credential-per-tenant is the strongest model because no parameter error can cross a boundary the credential cannot see.
- 04Filtering inside each tool means every tool re-implements isolation, and the weakest implementation sets your posture.
- 05Caches, embeddings, error messages and rate-limit state are all cross-tenant leakage paths that pass a naive test.
- 06Test it in ten minutes: authenticate as tenant A, pass tenant B’s identifier, confirm refusal and a logged attempt.
The pattern that fails
It is the natural design and it appears in most first implementations. One MCP server serves every tenant. It holds one credential broad enough to see all of them. Each tool takes a tenant_id parameter, and the implementation filters on it.
For a conventional API with a human-written client, this is merely fragile. For an agent it is unsafe in a specific way: the caller supplying tenant_id is a language model, and it derives that value from context. That context routinely contains other tenants’ identifiers — in a support thread, a shared document, a search result, a previous tool response.
So the failure does not require an attack. An agent handling a ticket that quotes another customer’s account reference can reasonably conclude that reference is the relevant tenant. The filter then works exactly as designed, against the wrong tenant.
And the consequence is categorically different from other agent failures. A wrong refund is an error with a remedy. A cross-tenant read is a disclosure: notification obligations, a customer conversation, and in several jurisdictions a regulator.
Key facts
- ▸If the model supplies the tenant, the model can supply the wrong tenant — and no attack is required.
- ▸A cross-tenant read is a disclosure event, not a defect.
- ▸Filtering correctly on the wrong identifier is still a breach.
Four isolation models
In descending order of strength and ascending order of convenience, which is the usual shape of this trade.
| Model | How it works | Strength | Cost |
|---|---|---|---|
| Credential per tenant | The server holds a separate credential per tenant; each can only see its own data | Strongest — no parameter error can cross a boundary the credential cannot see | Credential management at tenant scale; needs backing-system support |
| Instance per tenant | A separate server deployment per tenant | Strongest, plus blast-radius containment | Operationally heavy; only viable for a small number of large tenants |
| Tenant bound to identity | One credential, but tenant derived from the token claim and injected by the enforcement point; disagreeing parameters refused | Strong, and practical at any scale | Requires per-user or per-tenant tokens and a gateway that injects |
| Filter inside the tool | One credential; each tool applies the filter from a supplied parameter | Weak — every tool re-implements it and the weakest wins | Cheapest, and the one to move away from |
For most estates, tenant bound to identity is the right answer: it holds at scale, needs no per-tenant credential sprawl, and removes the model from the decision entirely. Use credential-per-tenant where the backing system supports it and the data is sensitive enough to justify the management overhead.
The critical property of the third model is where the binding happens. The enforcement point injects the tenant from the token and rejects any request carrying a different one. If instead the tool reads the token and derives the tenant itself, you are back to per-tool implementation with a better-sounding description.
Binding tenant to identity, concretely
Four mechanics. Together they mean the model never gets a vote on whose data it touches.
Put the tenant in the token
A verified claim, issued by your identity provider, not something the client asserts. Per-user OAuth carries the user’s tenant; a per-tenant service token carries its own. See MCP OAuth security.
Inject at the enforcement point
The gateway sets tenant_id from the claim before forwarding, overwriting whatever arrived. The tool receives a value it can trust because it did not come from the model.
Refuse on disagreement rather than silently overwriting
If the request carried a tenant that differs from the claim, refuse and log the attempt with both values. Silent overwriting is safe but discards the signal — and a disagreement is exactly what you want to see.
This is the difference between a control that works and a control that works and tells you something. A pattern of disagreements from one agent means its context is being contaminated, which is worth investigating before it matters.
Make the tool refuse an absent tenant
Defence in depth: a tool receiving no tenant must fail closed rather than defaulting to all. Defaults that mean “everything” are how a misconfiguration becomes a breach.
Five indirect leakage paths
Direct reads are the obvious path and the easiest to close. These five bypass the tenant filter entirely because they involve shared state rather than shared queries — and all five pass a naive isolation test.
- 01Caches keyed without tenant. A response cache keyed on the query but not the tenant serves tenant A’s data to tenant B on a cache hit. Include the tenant in every cache key, without exception.
- 02Shared embeddings or retrieval indexes. A semantic index built across all tenants returns nearest neighbours regardless of ownership. Either partition the index per tenant or filter after retrieval — and filtering after retrieval still leaks through result counts and scores.
- 03Error messages carrying data. “Record 5512 belongs to tenant Acme” confirms both existence and ownership. Errors should be generic to the caller and specific in the log.
- 04Rate-limit and quota state. Shared counters let one tenant infer another’s activity level, and let a noisy tenant starve a quiet one. Per-tenant ceilings solve both.
- 05Model context carried across turns. An agent serving multiple tenants in one long session can retain tenant A’s data in context when it begins acting for tenant B. Start a fresh context per tenant, and treat any agent session spanning tenants as a design defect.
The last one is the most under-appreciated and the most specific to agents. Conventional multi-tenant systems have no equivalent of a component that remembers the previous request in detail. If an agent session can span tenants, isolation at the data layer does not prevent disclosure at the reasoning layer.
Built on this thinking
Tenant comes from the token, not from the model
Barzel Central Gateway resolves per-user OAuth/OIDC identity before any tool call and injects tenant from the verified claim, refusing and logging any request that carries a different one — so isolation is enforced once at the edge rather than re-implemented in every tool.
Testing isolation in an afternoon
Six tests. Each should end in a refusal that appears in the log, and the last three are the ones that find real problems.
| Test | Method | Pass condition |
|---|---|---|
| Direct parameter substitution | Authenticate as tenant A, pass tenant B’s id | Refused; both values logged |
| Absent tenant | Authenticate as A, omit the tenant parameter | Refused, not defaulted to all |
| Credential scope check | Use the server’s credential directly against the backing system for tenant B | Refused by the backing system, not only by your gateway |
| Cache probe | Query as A, then the identical query as B | B receives B’s data, not a cache hit on A’s |
| Retrieval probe | Search as B for a distinctive string only present in A’s data | No results, and no difference in result count or timing |
| Session carry-over | Serve A, then B in the same agent session | B’s turn contains no residue of A’s data |
Test three deserves emphasis because it distinguishes real isolation from configured isolation. If the server’s credential can see tenant B and only your gateway prevents it, then a bug, a misconfiguration or a direct connection reaches B’s data. If the credential itself cannot see B, no amount of application-layer error does.
Five mistakes worth naming
Tenant as a model-supplied parameter
The whole article. The model infers it from context that may contain another tenant’s identifiers.
Filtering in each tool
Every tool re-implements isolation and the weakest implementation sets your posture. Enforce once, outside.
Cache keys without tenant
Passes every direct test and leaks on the first cache hit.
Specific error messages
“Not found” and “not yours” must be indistinguishable to the caller.
Agent sessions spanning tenants
Data-layer isolation does not prevent disclosure at the reasoning layer. Fresh context per tenant.
What isolation does not cover
Tenant isolation stops an agent reaching the wrong tenant. It does nothing about an agent doing the wrong thing within the right tenant — a correctly-scoped agent can still delete the correct customer’s records. Isolation is a boundary, not a judgement, and the controls for the second problem are entirely different.
It also cannot help where a tenant’s own data legitimately contains another tenant’s information: a shared document, a marketplace transaction, a referral. Those cases need a data-classification answer rather than an isolation answer, and they are the ones most likely to be argued about after an incident because both parties had a legitimate claim to the record.
And the model itself is not tenant-aware. If the same fine-tuned model or the same cached prompt prefix serves several tenants, information can move through the model rather than through your data layer. That is a deployment-topology question — separate contexts, separate caches, and for the highest-sensitivity tenants, separate inference — and no amount of enforcement-point work substitutes for it.
Frequently asked questions
What is MCP tenant isolation?
Enforcement that an agent acting for one tenant cannot read, modify or infer another tenant’s data through a shared MCP server. It matters more than in conventional multi-tenant systems because the caller choosing the tenant is a language model inferring it from context.
Why is a model-supplied tenant id unsafe?
Because the model derives it from context that routinely contains other tenants’ identifiers — a support thread quoting an account reference, a shared document, a previous tool response. No attack is required; the filter works correctly against the wrong tenant.
What are the isolation models for multi-tenant MCP?
Four: credential per tenant, which is strongest because no parameter error can cross a boundary the credential cannot see; instance per tenant, which adds blast-radius containment at high operational cost; tenant bound to identity and injected by the enforcement point, which is strong and practical at scale; and filtering inside each tool, which is weakest.
How do you bind tenant to identity?
Put the tenant in a verified token claim, have the enforcement point inject it before forwarding, refuse rather than silently overwrite when a request carries a different value, and make tools fail closed when no tenant is present rather than defaulting to all.
Should a disagreeing tenant parameter be overwritten or refused?
Refused, and logged with both values. Silent overwriting is safe but discards the signal — a pattern of disagreements from one agent means its context is being contaminated, which is worth investigating before it matters.
What are the indirect cross-tenant leakage paths?
Five: cache keys that omit the tenant, shared embedding or retrieval indexes, error messages that confirm existence or ownership, shared rate-limit and quota counters, and model context carried across turns when one agent session serves several tenants.
Why is an agent session spanning tenants a problem?
Because data-layer isolation does not prevent disclosure at the reasoning layer. An agent that retains tenant A’s data in context when it begins acting for tenant B can disclose it regardless of how well the data access was filtered. Start a fresh context per tenant.
How do you test MCP tenant isolation?
Six tests: substitute another tenant’s id, omit the tenant entirely, use the server’s credential directly against the backing system for another tenant, probe the cache with an identical query, search for a string present only in another tenant’s data, and check session carry-over. Each should end in refusal with the attempt logged.
Which isolation test matters most?
Using the server’s own credential directly against the backing system for another tenant. If it succeeds and only your gateway prevents access, then a bug or a direct connection reaches that data. If the credential itself cannot see the other tenant, no application-layer error can.
Does tenant isolation protect against everything?
No. It stops an agent reaching the wrong tenant, not an agent doing the wrong thing within the right one. It also cannot resolve records legitimately containing two tenants’ data, and it does not address information moving through a shared model, cache or prompt prefix rather than through your data layer.
Glossary
- Tenant isolation
- Enforcement that an agent acting for one tenant cannot read, modify or infer another tenant’s data through a shared Model Context Protocol server.
- Tenant binding
- Deriving the tenant from the authenticated identity rather than from a request parameter, so the caller cannot select which tenant it acts for.
- Confused-tenant problem
- A model supplying the wrong tenant identifier because it inferred it from context containing another tenant’s data.
- Indirect leakage
- Cross-tenant disclosure through shared state such as caches, embeddings, error messages or rate-limit counters rather than through a direct data read.
- Blast radius of a credential
- The complete set of tenants a single credential can reach, which for a shared multi-tenant credential is all of them.
Sources and further reading
Broken object-level authorization is a long-documented API weakness and OWASP’s treatment is authoritative. The confused-tenant framing, the four isolation models and the indirect leakage paths as they apply to agents are our own.
- 01 · OWASPOWASP API Security Top 10 ↗Broken object-level and function-level authorization, which reappear unchanged at the tool layer.
- 02 · OWASPOWASP Application Security Verification Standard ↗Input-validation, authorization and logging requirements restated here in MCP terms.
- 03 · NISTNIST SP 800-53 Rev. 5 ↗Access control and audit control families that MCP-layer controls have to satisfy.
- 04 · European UnionGDPR — Regulation (EU) 2016/679 ↗Lawful basis, data minimisation and processing records that agent estates inherit.
- 05 · MCP projectModel Context Protocol — specification ↗Normative source for tool schemas, capability negotiation and the authorization model.
- 06 · NISTNIST SP 800-207 — Zero Trust Architecture ↗The policy decision point / policy enforcement point split this architecture borrows directly.
- 07 · OWASP GenAI Security ProjectOWASP GenAI LLM Top 10 (2026) ↗Consensus risk list; excessive agency and prompt injection are the entries governance exists to bound.
- 08 · ISOISO/IEC 42001 — AI management systems ↗The management-system standard auditors increasingly map AI governance evidence against.
Last reviewed 2 September 2026. External links open in a new tab; we do not control their content.
Cite this article
Alex, M. (2026). MCP Tenant Isolation: Preventing Cross-Tenant Access. Real Biz Digital. https://realbizdigital.net/insights/mcp-tenant-isolation/
Try the mechanics on a live server
To watch a real tools/list response before you point a client at anything that governs production — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
Barzel Central Gateway is this layer, sold as a running product
Twenty-five tools covering identity-aware policy, tool routing, risk scoring, approvals, routebooks, workflow simulation and SIEM evidence. Ten policy inputs, six enforcement outcomes, per-user OAuth/OIDC. The Community tier is free, so an evaluation costs an afternoon rather than a purchase order.
| Plan | Price | Included | Right for |
|---|---|---|---|
| Community | Free | 1,000 tool calls/mo · full policy engine, registry, audit | Evaluating the estate, or a single team proving the path works |
| Starter | $10/mo | 10,000 calls/mo | One or two production agents against a handful of servers |
| Team | $79/mo | 100,000 calls/mo | A platform team governing an estate of 5–20 servers |
| Business | $149/mo | 250,000 calls/mo | Estate-wide governance with SIEM evidence and multi-team routing |
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.