MCP cross-tenant isolation

A shared MCP server must keep tenant identity attached to discovery, invocation and downstream data access.

01 / The operating case

What changes in a real workflow?

A support agent for tenant A passes a customer ID that also exists in tenant B, and a shared tool queries by ID alone.

Trace the authority boundary
  1. 01Client / task
  2. 02MCP server
  3. 03Tool call + arguments
  4. 04Downstream effect

02 / Decision contract

What the executor must check

Derive tenant from authenticated context, include it in the resource key and downstream query, and deny a mismatch before returning data.

InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

Tenant ID is accepted from an untrusted tool argument or lost after a queue handoff.

Evidence to retain

Retain authenticated tenant, requested target, downstream tenant predicate and denied mismatch.

04 / Canonical scope

Why this reference stands alone

Server isolation covers workload compromise; this page owns per-tenant authorization within a shared server.

Protocol or attack trace

Tenant predicate test

Sequence

Authenticated caller belongs to tenant A and passes tenant B object ID to shared MCP search.

Negative test

Resolve tenant from authenticated context and force tenant=A in downstream query; return no B data.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation