Notifications
Clear all
Topic starter
20/08/2026 5:36 pm
TL;DR: As AI clients like Claude, Cursor, and VS Code connect to more internal tools, the article argues that the single-gateway question is really about authentication, policy enforcement, and auditability, according to Obot. For IAM teams, the practical decision is not routing topology but where centralized control becomes necessary to stop OAuth drift, duplicated scopes, and inconsistent trust boundaries.
NHIMG editorial — based on content published by Obot: single MCP gateway or multiple MCP servers and the governance trade-offs between them
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Obot's analysis of single gateway versus multiple MCP servers →
Single MCP gateway or multiple servers: where governance really starts?
Explore further
20/08/2026 6:22 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP gateways are governance decisions, not just routing choices
