MCP gateways are governance decisions, not just routing choices

At a glance

What this is: This is an analysis of when a single MCP gateway makes sense versus multiple MCP servers, and its core finding is that the decision is really about authentication and governance rather than routing.

Why it matters: For IAM, NHI, and platform teams, this matters because MCP integration can quickly create duplicated identities, inconsistent scopes, and fragmented audit trails if governance is not centralized at the right point.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Obot's analysis of single gateway versus multiple MCP servers

Context

MCP gateways sit at the point where AI clients, tools, and internal services meet, so the architecture choice is really an identity and access question. If the gateway centralises authentication, policy, logging, and token validation, it can reduce duplication. If it does not, the environment often ends up with scattered trust decisions and inconsistent tool access across servers.

That matters because MCP adoption is expanding faster than many governance models can absorb. Teams connecting AI clients to internal tools need to decide whether each server will carry its own auth logic or whether a central boundary will enforce identity policy once and route internally. For practitioners, the issue is not infrastructure elegance but control over non-human access.

Key questions

Q: How should teams decide between a single MCP gateway and multiple servers?

A: Choose a single gateway when you need centralised authentication, consistent scopes, and auditability across multiple tools. Choose multiple servers when different teams need independent deployment and isolation, but keep identity policy centralised if you still need uniform governance. The right answer is usually determined by ownership and compliance pressure, not by routing convenience.

Q: Why do MCP environments become harder to govern as they scale?

A: They become harder to govern when each server implements OAuth, logging, and policy differently. That creates scope drift, duplicated configuration, and inconsistent evidence for access review. The governance problem is not the number of servers alone, but the number of places where trust decisions are independently redefined.

Q: What breaks when AI tools are exposed through loosely governed MCP servers?

A: Loose governance lets model-driven tools cross from context retrieval into state-changing actions without enough oversight. That can expose sensitive data, trigger unauthorized system changes, or widen lateral movement paths. The failure is a control boundary mismatch between what the AI can ask for and what it can safely do.

Q: How do security teams keep MCP ownership flexible without losing control?

A: Let teams own their internal MCP servers, but centralise the identity layer at the gateway. That preserves deployment autonomy while keeping token validation, audit logging, and policy enforcement consistent. This is the operating model that scales best when both security and engineering need to move quickly.

Technical breakdown

Why MCP gateways become an authentication boundary

A true MCP gateway is more than a traffic router. It becomes the place where OAuth, token validation, access policy, logging, and identity mapping are enforced before AI clients reach internal servers. That design is attractive because it keeps each backend server focused on business logic while one boundary handles identity decisions. Without that boundary, every server must recreate the same auth logic, which creates drift in scopes, audit records, and operational behaviour.

Practical implication: treat the gateway as the control point for authentication and policy, not as an optional routing convenience.

How OAuth changes MCP server governance

OAuth introduces a full identity lifecycle for MCP access, including client registration, redirect handling, token issuance, scope design, and revocation. When those functions are implemented separately across multiple MCP servers, the environment becomes harder to govern because each server can define trust differently. That creates inconsistent access semantics for the same AI client and makes access review and compliance evidence much harder to produce.

Practical implication: centralise OAuth where possible so scope design, token handling, and audit evidence stay consistent across MCP servers.

When multiple MCP servers are the right operating model

Multiple servers make sense when different teams own different tools, need independent deployment cycles, or require stricter isolation between domains. This is not a microservices purity argument. It is a governance and operating model choice that lets teams move independently while still preserving control at the boundary. The important point is that decentralised backends do not mean decentralised identity policy if the gateway remains the policy enforcement layer.

Practical implication: separate server ownership where needed, but keep identity enforcement and auditability centralised at the gateway.

NHI Mgmt Group analysis

The MCP gateway question is an identity governance question before it is an architecture question. The article is right to push back on the idea that this is just a routing decision. In practice, the decision determines where authentication is enforced, how scopes are standardised, and whether auditability is coherent across tools. For IAM and NHI teams, the gateway becomes the governance boundary that decides whether MCP access is managed or merely connected.

Centralisation only works when it reduces trust drift, not when it adds another unmanaged layer. Multiple independently configured MCP servers can create duplicated OAuth logic, inconsistent scopes, and weak evidence for access review. The named concept here is MCP trust drift: a slow divergence between intended policy and the way each server actually authenticates and authorises AI clients. Practitioners should read that as a sign that the control plane is fragmenting.

Hybrid MCP models are the most realistic pattern for growing enterprises. The article’s strongest point is that centralised authentication does not require centralised tool ownership. That separation lets security teams hold the policy line while product teams keep deployment autonomy. In identity terms, this is the same governance pattern used in mature IAM programmes: one policy boundary, many operational owners.

MCP sprawl will expose the same lifecycle failures seen in other NHI estates if ownership is unclear. Once multiple servers and AI clients proliferate, the hard problem is offboarding, scope review, and revocation across independently run services. That is why the discussion belongs alongside OWASP NHI and zero trust thinking rather than generic platform engineering. Practitioners should assume governance debt will grow unless identity decisions stay centralised.

From our research:

• From our research: 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to the 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks.
• For a broader view of identity governance pressure points, see Top 10 NHI Issues for the patterns that most often drive control breakdowns.

What this signals

MCP adoption is starting to behave like every other identity sprawl problem: once access is distributed across too many control points, governance becomes a reconciliation exercise instead of a policy exercise. Teams should expect the same failure pattern to appear in audit, offboarding, and scope review unless the gateway is treated as a formal control boundary.

MCP trust drift: when each server defines its own token handling and scope semantics, the organisation no longer has one identity policy, it has many local interpretations of the same policy. That is where operational inconsistency turns into security debt.

The practical next step for most enterprises is to align MCP governance with established identity architecture thinking, including zero trust and NHI lifecycle controls, rather than treating AI tool connectivity as a separate discipline. The more clients and servers you connect, the more important it becomes to keep identity, logging, and revocation centralised.

For practitioners

• Define the authentication boundary first Decide whether the gateway or each MCP server owns OAuth, token validation, and access policy before scaling tool connections.
• Standardise MCP scopes centrally Create one scope model for AI client access so tools do not drift into inconsistent permissions across independently managed servers.
• Separate ownership from policy enforcement Allow different teams to run their own MCP servers while keeping identity mapping, logging, and audit evidence in a shared control layer.
• Review offboarding and revocation paths Check how quickly an AI client, token, or server access path can be removed when a tool is retired or a team changes ownership.

Key takeaways

• The MCP gateway debate is fundamentally about identity control, because routing alone does not solve authentication or scope consistency.
• Distributed MCP servers create governance drift quickly when OAuth, logging, and revocation are implemented in different ways.
• Enterprises that want both autonomy and control should centralise policy at the gateway while allowing teams to own their back-end servers.

Key terms

• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• OAuth scope sprawl: OAuth scope sprawl is the accumulation of permissions beyond what an integration actually needs. For Slack-connected agents, it increases the amount of data the app can see and the actions it can take, which raises the blast radius if the token is exposed or misused.

What's in the full article

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

• Step-by-step guidance on when a gateway adds value versus when it only increases operational overhead
• The specific OAuth and audit patterns used to centralise authentication across multiple MCP servers
• A practical breakdown of hybrid ownership models for teams that need both autonomy and policy enforcement
• Examples of how to reduce MCP sprawl without forcing all tools into one deployment pattern

👉 Obot's full article covers the gateway model, hybrid ownership, and centralised authentication detail.

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 building or maturing an IAM programme, it is worth exploring.