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.
Why This Matters for Security Teams
Multi-tenant MCP deployments turn identity into a boundary problem, not just an authentication problem. If tenant context, client registration, and token issuance are blended into the gateway, the gateway becomes an accidental control plane that can leak privileges across customers. That is especially risky for AI-driven workloads because request patterns are dynamic, tool use is chained, and access decisions must reflect tenant, intent, and data sensitivity at runtime. Current guidance from the OWASP Top 10 for Agentic Applications 2026 reinforces that agentic systems need stronger runtime control than static app-layer assumptions.
NHI Management Group has also found that identity sprawl is already the norm, not the exception: in the Ultimate Guide to NHIs, 97% of NHIs carry excessive privileges and 5.7% of organisations have full visibility into service accounts. In practice, many security teams encounter cross-tenant exposure only after an agent, connector, or service account has already inherited more access than intended.
How It Works in Practice
The safest design is to separate identity responsibilities by function. The MCP gateway should broker requests and enforce policy at request time, but it should not own tenant onboarding, consent, token minting, or long-term credential lifecycle. Those tasks belong to the identity provider or a dedicated control plane that understands tenant boundaries and downstream resource ownership.
For multi-tenant deployments, teams typically need four layers working together:
-
Tenant-aware client registration so each client or agent instance is bound to a specific tenant context.
-
Short-lived tokens or workload credentials issued per tenant and per session, rather than shared secrets reused across tenants.
-
Request-time authorisation that evaluates tenant, scope, tool, and data classification before the gateway forwards the call.
-
Separate lifecycle controls for rotation, revocation, and offboarding when a tenant, connector, or agent is removed.
This aligns with the emerging best practice described in OWASP Agentic AI Top 10: avoid letting the application tier act as both broker and policy authority. It also maps cleanly to NHI governance lessons from Ultimate Guide to NHIs, where long-lived secrets and excessive privilege are the usual failure pattern. For implementation, use workload identity, strong tenant claims, and policy-as-code so authorisation is evaluated with full context instead of inferred from a static role.
When done well, the gateway validates the request, the identity provider asserts who the client is and which tenant it belongs to, and downstream systems receive only the minimum delegated permission needed for that call. These controls tend to break down when one gateway fronts many tenants but shares a single credential pool because tenant isolation then depends on application code behaving perfectly under load and change.
Common Variations and Edge Cases
Tighter tenant isolation often increases onboarding friction, operational overhead, and policy complexity, so organisations have to balance clean segregation against developer experience and supportability. There is no universal standard for this yet, especially when MCP is used across internal teams, partners, and embedded SaaS integrations.
One common variation is shared infrastructure with tenant-scoped tokens. That can work if token audiences, claims, and policy checks are enforced consistently, but it becomes fragile when downstream tools do not honour tenant context. Another edge case is delegated access for managed service providers or admin users, where consent and approval flows need to be explicit and time-bound rather than implied by broad operator roles.
For agentic workloads, the risk is higher because behaviour is not fully predictable. An agent may chain tools, retry failures, or pivot into a new data path that was not anticipated at design time. Current guidance suggests using short-lived credentials, workload identity, and runtime policy evaluation rather than relying on static RBAC alone. The 52 NHI Breaches Analysis shows why this matters: identity failures often become breach paths when lifecycle controls lag behind access growth. That approach is most likely to fail in highly federated environments where tenant metadata is inconsistent across IdP, gateway, and downstream resource providers.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Agentic systems need runtime authorization, not static gateway trust. |
| CSA MAESTRO | A3 | MAESTRO stresses secure agent identity and scoped delegation across tenants. |
| NIST AI RMF | AI RMF governance applies to tenant isolation, accountability, and oversight. |
Separate identity issuance from the gateway and enforce least-privilege delegation per tenant.
Related resources from NHI Mgmt Group
- Why do multi-tenant applications expose weaknesses in identity architecture?
- How should security teams design authentication for multi-tenant SaaS apps?
- Who should own the design of a multi-tenant identity control plane?
- How should teams design multi-tenant authorization so tenant data stays isolated?
