MCP gateways expose the identity layer gap in multi-tenant AI

At a glance

What this is: This is an analysis of why MCP gateways help with enforcement but do not solve multi-tenant identity and credential management on their own.

Why it matters: It matters because IAM, NHI, and agentic AI programmes all need a clean split between policy enforcement, token issuance, and tenant-scoped credential handling to avoid building brittle identity logic into application code.

👉 Read Descope's guide to MCP gateways for multi-tenant AI identity

Context

MCP gateway architecture becomes an identity problem as soon as one server has to support many tenants, each with different consent flows, scopes, and downstream credentials. The basic protocol is workable for a single application, but multi-tenant deployments expose the gap between request-time enforcement and identity-time decisioning.

That gap is directly relevant to NHI governance because agent connections behave like tenant-scoped machine identities, even when they are routed through AI tooling. If the identity layer cannot resolve tenant context cleanly, the organisation ends up recreating credential and policy logic in the gateway or application, which defeats central governance.

Key questions

Q: How should teams design identity for multi-tenant MCP deployments?

A: Teams should separate token issuance, consent, client registration, and credential lifecycle from the gateway itself. The gateway should enforce policy at request time, while an identity provider owns tenant context and downstream access decisions. That separation reduces the chance that application code becomes an accidental identity control plane.

Q: Why do MCP gateways not solve multi-tenant governance by themselves?

A: Because gateways enforce, but they do not decide. They can validate tokens, scopes, and routing, but they cannot independently determine which tenant issued a request, which consent flow applied, or which credential backs a tool call. Without an identity layer behind them, teams end up rebuilding governance inside the application.

Q: What breaks when tenant context is stored only in the access token?

A: The main failure is that session state becomes frozen at login. If a tenant needs different scopes, refresh behaviour, or downstream credentials later in the session, the server must work around the token rather than rely on it. That increases brittle application logic and weakens central governance.

Q: How do teams know whether an MCP architecture is ready for scale?

A: A scalable design can answer three questions clearly: who issues the token, who resolves tenant context, and who owns each downstream credential. If those answers require custom code in every service, the architecture is not yet ready for many tenants. The safer pattern centralises identity decisions and keeps routing separate.

Technical breakdown

Why tenant context breaks inside a shared MCP server

A shared MCP server can resolve tenant context from the token or from server-side lookup, but the second option is usually safer because bearer tokens persist for the life of the session. If tenant state is baked into the JWT, it is frozen at login and cannot adapt when the same agent session needs different downstream credentials or different consent logic. Once you support mixed tenants, this becomes a state-management problem as much as an auth problem. The server starts acting like the identity layer instead of consuming one.

Practical implication: keep tenant resolution out of static token claims when session state, scopes, and downstream access can vary during the life of the connection.

What MCP gateways enforce, and what they do not

MCP gateways can validate tokens, enforce scopes, route traffic, and provide observability. That is enforcement, not identity issuance. They do not decide which tenant issued the token, which consent flow applied, or which downstream credential should back a tool call. In multi-tenant setups, that means the gateway can reject bad requests but cannot independently construct the identity context needed to authorize the good ones. The missing piece is a separate identity provider that owns registration, consent, credentials, and tenant configuration.

Practical implication: treat the gateway as a policy enforcement layer and verify that an upstream identity provider owns registration, consent, and credential lifecycle.

Why per-tenant MCP servers do not remove the governance problem

A per-tenant server model gives strong compute and data isolation, but it scales the identity scaffolding linearly. Every tenant introduces its own endpoint configuration, DCR or CIMD settings, consent design, and credential set. That is manageable at a small number of tenants and rapidly becomes operationally heavy as the count rises. The architectural issue is that isolation moved from runtime code into identity operations, which means governance, not just infrastructure, becomes the bottleneck.

Practical implication: if you choose per-tenant servers, plan for identity operations at scale rather than assuming compute isolation solves governance complexity.

NHI Mgmt Group analysis

Tenant-scoped identity is the real control plane in MCP architecture. The article is really about the fact that routing only solves half the problem. In multi-tenant MCP, the harder question is which identity layer owns consent, credential isolation, and downstream authorization for each tenant. Practitioners should treat the gateway as downstream of identity governance, not as a substitute for it.

Shared MCP sessions create identity persistence that many teams underestimate. When tenant state sits in a bearer token for the life of the session, the control assumptions change. Access review, session scoping, and downstream credential selection all become harder because the token cannot be refreshed or reshaped mid-session in the way teams often expect. The implication is that session design and credential design must be aligned before scale-up.

Multi-tenant MCP exposes an identity sprawl problem, not just an integration problem. Each new customer brings its own client registration, scopes, consent flow, and credential mapping. That is a governance workload that grows with tenant count and quickly overwhelms manual operations. For IAM and NHI teams, the lesson is to measure whether the organisation is centralising identity decisions or merely distributing them into more places.

Centralised identity for MCP is becoming a category requirement, not an enhancement. Once internal and third-party MCP servers coexist, the control plane has to manage resource tokens and external OAuth tokens without leakage across boundaries. That is the point at which lifecycle management, least privilege, and tenant isolation converge. Practitioners should expect MCP governance to be judged by how well it separates policy from enforcement.

MCP gateway architecture should be evaluated against the same governance standard as any machine identity programme. The question is not whether the gateway can validate a request, but whether the identity model can explain who or what is allowed to act for which tenant, under which consent, and with which downstream credential. That is the standard teams need to apply before they scale agent connections.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to the same report.
• That trajectory makes multi-tenant identity governance a forward problem, not a future one, and the OWASP Agentic Applications Top 10 is a useful lens for evaluating where tool use, consent, and scope can break down.

What this signals

Tenant-scoped identity will become the differentiator in agent gateway programmes. As agent adoption grows, teams will need more than enforcement at the edge. They will need a control plane that can prove which tenant, which consent flow, and which downstream credential governed every tool call, or the architecture will drift into unreadable application logic.

The most useful next step is to treat MCP and agent routing as a machine identity design problem, not a plumbing exercise. That means the same discipline you would apply to workload identity, lifecycle control, and scoped access now has to extend into AI connection management and per-tenant consent.

The category is also converging with broader AI governance models, including the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10, because policy only works when the identity path is explicit and auditable.

For practitioners

• Separate enforcement from identity issuance Document which layer validates tokens, which layer issues them, and which layer owns tenant-scoped credentials. If those duties sit in the same component, the architecture is already drifting toward hidden identity sprawl.
• Model tenant context outside static token claims Use server-side resolution or an identity provider lookup when tenant state may change during a session. Avoid designs where a JWT permanently freezes consent, scope, or downstream access decisions for every tenant.
• Map every downstream credential to one tenant Ensure each customer connection resolves to a tenant-specific credential set with no shared storage path across customers. That mapping should be auditable from registration through revocation.
• Review whether your gateway can make decisions or only enforce them Test the architecture by asking which component can issue tokens, evaluate consent, and change configuration at the tenant level. If the gateway only enforces policy, an upstream identity layer still has to exist.

Key takeaways

• MCP gateways solve enforcement, but they do not replace the identity layer that issues tokens, manages consent, and resolves tenant context.
• Multi-tenant MCP becomes operationally fragile when tenant state, downstream credentials, and access policy are scattered across application code and gateway logic.
• Practitioners should evaluate MCP architectures by whether identity decisions are centralised, auditable, and separable from request-time routing.

Key terms

• MCP gateway: An MCP gateway is a routing and enforcement layer that sits in front of MCP servers and validates access before requests reach tools. It can check tokens, scopes, and policy, but it does not by itself own token issuance, consent, or downstream credential lifecycle.
• Tenant-scoped identity: Tenant-scoped identity is the practice of binding access, consent, and credentials to a specific customer or organizational boundary. In multi-tenant MCP, it keeps one tenant's token, tools, and downstream secrets separate from another's, so governance does not collapse into shared application logic.
• Client registration: Client registration is the process of creating and configuring an application or agent identity so it can request tokens and access resources. In MCP environments, registration settings often vary by tenant, which makes registration a governance control as much as an onboarding task.
• Consent flow: A consent flow is the authorization journey that records and enforces what a user or agent is allowed to access. In multi-tenant MCP, different tenants may require different consent steps, scopes, or assurance levels, so consent becomes part of identity design rather than a UI detail.

What's in the full article

Descope's full article covers the operational detail this post intentionally leaves for the source:

• A step-by-step implementation walkthrough for deciding when a single MCP server, per-tenant servers, or a gateway-plus-IdP pattern fits the environment.
• Configuration detail for DCR, CIMD, consent handling, and token issuance across tenant-specific MCP connections.
• The Golf.dev integration example showing how gateway enforcement and identity issuance are split in practice.
• Operational guidance for mapping downstream credentials and tenant context without leaking access across boundaries.

👉 Descope's full article shows how gateway routing, tenant consent, and identity issuance fit together in practice.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.