Multi-Tenant Boundary

A Multi-Tenant Boundary is the security boundary between distinct customer or user tenants in a shared system — the line that separates tenant A's data, configuration, and authority from tenant B's. The boundary is foundational to SaaS architecture and is enforced at multiple layers: database row-level security, API request scoping, network segmentation, identity scoping. In MCP-connected agents, the boundary must additionally be enforced at the agent host level — at the layer where MCP servers are invoked and tool authority is granted — rather than trusting connector-level enforcement alone.

The June 2025 Asana MCP cross-tenant access bypass, documented in the MCP Breach Index 2025–2026 and analysed in detail in the OWASP ASI03 explainer, illustrated why connector-level enforcement is not enough. The Asana MCP server's tool authority was over-broad: a single connection could read across tenant boundaries that should have been isolated at the tool level. The fix was scope-narrowing on the server side — but a properly-architected agent host would also have enforced per-tenant identity governance independent of the connector's claims, blocking the cross-tenant access regardless of what the server itself enforced.

Why Connector-Level Enforcement Is Not Enough

Three properties make connector-level multi-tenant enforcement insufficient. The connector itself can be compromised. A trojanised connector cannot be trusted to enforce its own scoping; the host must do it. Connector configurations drift from intent. A connector that was correctly scoped at install can be reconfigured to relax scoping later. The host should enforce a tenant boundary that does not depend on the connector's current configuration. Compositional risks cross connectors. When multiple MCP servers connect to the same agent host, each could individually enforce tenant scoping while the composition allows tenant-crossing behaviour through unintended chains.

The structurally sound pattern is defence in depth: the connector enforces its own scoping (good), and the host enforces tenant scoping independently (necessary). The host's enforcement is the load-bearing layer because it does not depend on the connector's correctness or honesty.

Implementation Patterns

Effective host-level multi-tenant enforcement requires distinct agent identities per tenant (the agent acting on behalf of tenant A has a different identity than the agent acting on behalf of tenant B), explicit tenant context on every tool invocation, refusal of any tool call whose tenant context does not match the connection's authorised tenant, and tenant-scoped audit logging that makes cross-tenant attempts visible immediately.

For deeper guidance, see the OWASP ASI03 explainer and the MCP Security Audit service description.