How should teams govern MCP access when multiple tenants share the same user identity?

Why This Matters for Security Teams

When multiple tenants share the same user identity, the real security problem is not authentication, but tenant-scoped authorisation. A single login can be legitimate and still become unsafe if the platform lets the user or agent choose an organisation after token issuance, because downstream MCP tools may inherit the wrong context. That turns a routine session into cross-tenant data exposure or tool misuse.

For MCP deployments, tenant selection must be treated as a policy decision with audit impact, not a UI convenience. This is especially important because current research from The State of MCP Server Security 2025 shows that only 18% of MCP server deployments implement any form of access scoping for tool permissions. In practice, that means many teams are relying on identity alone while skipping the control that actually separates organisations. Guidance from the NIST Cybersecurity Framework 2.0 reinforces that access must be bounded, monitored, and continuously validated. In practice, many security teams discover tenant bleed only after shared accounts have already touched the wrong tools or datasets.

How It Works in Practice

The safest pattern is to resolve tenant context before any privileged token is minted, then bind that tenant to the session in a trustworthy claim that the MCP server can enforce. That claim should be treated as an input to authorisation, not as a decorative label. The MCP server then maps the claim to a tenant-specific policy set, tool catalogue, and SSO route so the same user identity can still be constrained differently by organisation.

This is where static IAM breaks down. Shared identities, especially in multi-tenant platforms, do not follow a stable access pattern. A user may act for one tenant in the morning and another tenant minutes later. If the system uses a long-lived token or a cached role without re-checking tenant context, the wrong permissions can persist across requests. Current guidance suggests combining real-time policy evaluation with short-lived credentials so authorisation follows the active tenant at request time.

• Establish tenant selection before token issuance.
• Embed the active tenant in a signed claim or token attribute.
• Enforce tool allowlists per tenant inside the MCP server.
• Re-evaluate access when the tenant changes, not just when the user logs in.
• Log tenant, tool, and decision context for each request.

This approach aligns with NHI governance principles in the Ultimate Guide to NHIs, especially the lifecycle and access-boundary model. It also fits the emerging agentic control model described in the OWASP Agentic AI Top 10, where runtime context matters more than static role assignment. These controls tend to break down when teams let a front-end tenant picker drive backend authority without reissuing or revalidating the access token.

Common Variations and Edge Cases

Tighter tenant isolation often increases session complexity, requiring organisations to balance lower blast radius against more frequent token churn and stronger audit logging. That tradeoff becomes visible in delegated admin models, support workflows, and federated SSO setups where one person legitimately operates across many tenants.

There is no universal standard for how the tenant claim should be encoded, but best practice is evolving around three rules: the claim must be tamper-resistant, the MCP server must verify it independently, and the policy engine must deny any tool call that is not explicitly allowed for that tenant. For shared service identities, teams should avoid reusing a generic access token across tenants and instead issue tenant-scoped credentials with short TTLs. If the platform supports agentic workflows, the same rule applies to non-human actors: the active tenant must be part of the runtime decision, not just the login event.

Edge cases often appear in support consoles, break-glass access, and migration periods where one identity legitimately spans multiple organisations. In those situations, teams should require explicit tenant switching, re-authentication for high-risk tools, and immutable logs that preserve which tenant was active at the time of each call. The Top 10 NHI Issues and the OWASP Non-Human Identity Top 10 both point to the same operational reality: identity alone is not enough when the authority boundary changes by tenant.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• Who is accountable for access compliance when multiple teams share identity governance?
• How should security teams govern access when AI agents and humans share the same apps?