Tenant-scoped MCP connectors

Intent

This pattern assumes a multi-tenant platform whose identity provider records which tenants each user belongs to, as in multi-tenant Cognito auth. It names one tenant in each connector's URL when a user adds it, and settles the caller's right to that tenant before the server reads a single MCP message. This enables three outcomes:

1. The boundary between tenants holds even when the model is manipulated, because the model has no say in it.
2. Outsiders learn nothing. A caller without access to a tenant can't list its tools, or tell whether it exists.
3. Access becomes an operational control. You can turn the server on or off for any one tenant straight away, with no deploy.

Motivation

Multi-tenant platforms have long kept tenants apart through the session: a portal holds an active tenant, and the user changes it with a switcher. An MCP host has neither, so nothing in a request says which tenant it's for. The common fix is a tenant argument on every tool, which creates two failures:

1. The model chooses the tenant. Tenant isolation, the guarantee a multi-tenant platform can least afford to lose, now rests on text a prompt injection can influence.
2. Every tool carries its own check. One missed check on one new tool becomes a broken access control failure across clients.

This pattern takes the decision away from the model. The tenant comes from the connection and the right to it from verified claims, so nothing said in a conversation can change either. The check runs once, ahead of the protocol, so it covers every tool by default, including tools added later, and it applies the rules the rest of the platform already enforces.

Applicability

Use this pattern when:

1. A multi-tenant platform exposes an MCP server.
2. Some users hold more than one tenant, so the login alone doesn't say which to serve.
3. MCP hosts have no way to switch tenant, as a portal would.
4. The tenant boundary must hold even if the model is manipulated.

Do not use this pattern when:

1. Every user holds exactly one tenant. Take the tenant from the token, and use one URL for everyone.
2. The platform is single-tenant.

Structure

Participants

Constraints and trade-offs

1. Each tenant is a separate connection. A user with several tenants adds one for each, and a question spanning tenants needs them all connected.
2. Losing access isn't instant. Membership travels in the token, so someone removed from a tenant keeps access until it expires, while turning off a whole tenant applies straight away.
3. Reading the tenant on every call keeps the off switch immediate, and caching that read would trade some of that speed for fewer calls.
4. This pattern protects the boundary between tenants, not the rules within one. Where users in the same tenant see different data, combine it with LLM agents that act as the user.

Part of how I deliver

On a multi-tenant platform, this is how I keep every client apart once AI is connected to it. It's one of many patterns I bring through contract delivery, and it builds on the same platform patterns that keep your tenants apart everywhere else.

Related