Implement tenant isolation for agents

Tenant context must come from authenticated authority and survive every agent handoff.

01 / The operating case

What changes in a real workflow?

A support agent for tenant A passes a tenant B customer ID to a shared MCP server.

Trace the authority boundary
  1. 01Authority origin
  2. 02Task and grant
  3. 03Current decision
  4. 04Observed outcome

02 / Decision contract

What the executor must check

Bind tenant to principal and task, propagate a verified tenant claim, include tenant predicate in every data query and reject argument overrides.

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

An object ID alone is treated as sufficient access to another tenant’s record.

Evidence to retain

Record authenticated tenant, target tenant, query predicate, denial and data-return status.

04 / Canonical scope

Why this reference stands alone

MCP cross-tenant isolation focuses one server; this guide owns end-to-end implementation.

Illustrative implementation artifact

Tenant binding invariant

trustedTenant = authenticatedPrincipal.tenant
reject if task.tenant != trustedTenant
resource = lookup(tenant=trustedTenant, id=request.objectId)
reject if resource missing
// downstream query includes trustedTenant predicate

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation