MCP gateways are becoming the control plane for enterprise AI access

At a glance

What this is: This is an analysis of why MCP gateways are emerging as the control layer for enterprise AI, with the key finding that sprawl, dead servers, and inconsistent policy enforcement create a governance problem, not just an infrastructure one.

Why it matters: It matters because MCP sits between AI clients and tools, so IAM, PAM, and NHI teams need one place to enforce authentication, authorization, auditability, and credential boundaries across growing agent-to-tool estates.

By the numbers:

• 52% of public MCP servers are effectively dead, creating a maintenance and trust problem for enterprises adopting the protocol.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Obot's analysis of MCP gateways, sprawl, and enterprise AI governance

Context

MCP gateway governance matters because the protocol can turn one AI integration into many unmanaged tool connections very quickly. In practice, that means authentication, routing, and policy decisions are being duplicated across servers unless an enterprise inserts a central control point.

The first-order risk is NHI sprawl: each MCP server can carry its own credentials, permissions, and tool descriptions, which expands the audit burden and the blast radius at the same time. For IAM and NHI teams, the question is not whether MCP works, but whether the organisation can govern it before it becomes a shadow integration layer.

Obot’s analysis frames the gateway as a reverse proxy and policy layer, but the governance issue is broader than transport. Once tool access, credential injection, and approval logic are scattered across servers, the enterprise loses a coherent place to apply lifecycle, revocation, and inspection controls.

Key questions

Q: What breaks when MCP servers are added without a gateway?

A: Authentication, authorization, and audit responsibilities fragment across servers, which makes policy inconsistent and revocation slow. The hidden failure is that each new server expands the trust boundary and the blast radius. Without a gateway, teams usually discover the problem only after a server has already been wired to credentials and internal tools.

Q: Why do MCP servers create new risk for IAM teams?

A: MCP servers can collapse the boundary between human intent and machine execution. If they use shared credentials or broad permissions, the agent may act with more privilege than the user should have, which weakens least privilege, complicates audit trails, and increases blast radius when the server is compromised.

Q: How do you know if MCP security controls are actually working?

A: You know MCP controls are working when untrusted endpoints are blocked, privileged tool calls are minimal, and audit logs show only approved commands and data flows. If teams cannot reconstruct which server asked for what, or if secrets appear in configuration files, the control set is not operating as intended.

Q: Who is accountable when a malicious MCP server exposes enterprise data or actions?

A: Accountability sits with the organisation operating the agent, the team approving the server, and the owners of the connected systems. The important governance question is whether provenance checks, runtime policy, and audit logging were in place before the server was trusted. If they were not, the failure is shared and preventable.

Technical breakdown

Why MCP server sprawl creates an identity governance problem

MCP servers are not just endpoints. They are identity-bearing integrations that can reach internal systems, invoke tools, and carry credentials on behalf of users or agents. When teams add servers ad hoc, each one becomes a separate trust decision with its own auth path, its own access scope, and its own maintenance lifecycle. That is why dead servers matter: an abandoned server is still a security dependency if it can reach live systems. The governance failure is fragmentation, not protocol complexity.

Practical implication: Treat every MCP server as a governed NHI dependency with an owner, scope, and offboarding path before it is allowed into production.

How MCP gateways centralize authentication and authorization

An MCP gateway separates identity handling from individual server implementations. The gateway can validate OAuth, inject user-specific credentials, and apply RBAC or ABAC before requests reach downstream tools. That architecture turns per-server auth code into one enforcement layer, which reduces inconsistent policy decisions and makes revocation, audit logging, and token handling much easier to manage. The important distinction is that authentication answers who is asking, while authorization answers what that identity may do. Gateways matter because they unify both decisions.

Practical implication: Move authN and authZ decisions to a single gateway layer so revocation, logging, and policy enforcement are consistent across the MCP fleet.

Why tool description poisoning is a model-context risk

MCP tool descriptions are injected into the model context window, which means they are treated as trusted input unless a control layer inspects them first. That creates a non-obvious attack surface: a compromised or malicious server can shape model behaviour through text that looks like metadata. This is not a network-layer anomaly and not a conventional credential theft issue. It is a trust-boundary failure between infrastructure content and model reasoning. The gateway becomes useful here because it can normalize and inspect tool definitions before they reach the model.

Practical implication: Add inspection and allowlisting for tool metadata before it reaches the model context window, especially for community or third-party servers.

Threat narrative

Attacker objective: The objective is to gain durable influence over AI-mediated tool access, enabling data exposure, unauthorized tool execution, or persistent trust abuse inside the enterprise.

1. Entry occurs when an organisation adds public or third-party MCP servers into production without validating maintenance status, access scope, or tool descriptions.
2. Escalation happens when those servers carry credentials or trusted instructions into model context, allowing overbroad tool use or poisoned guidance to influence downstream actions.
3. Impact emerges as the AI environment inherits hidden blast radii, unpatched vulnerabilities, and unaudited access paths that can expose internal systems or sensitive data.

Breaches seen in the wild

• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP gateways are becoming the identity control plane for AI tool access. The core issue is not whether MCP is useful, but whether enterprises can govern many identity-bearing integrations without fragmenting auth, audit, and revocation across every server. Once tool access is distributed, security teams lose the single enforcement point they need for consistent lifecycle control. The practical conclusion is that MCP should be treated as governed identity infrastructure, not as an isolated developer convenience.

Dead MCP servers are an NHI governance failure, not just technical debt. A server with no maintainer, no issue response, and no patch path is still a live trust dependency if it can reach production systems. That makes ownership, service lifecycle, and offboarding the real control gap, not runtime availability alone. Enterprises should stop treating community server adoption as a one-time install decision and start treating it as a managed dependency with retirement criteria.

Tool description poisoning shows why trust assumptions must move closer to the model boundary. MCP descriptions are consumed as context, which means a text field can become a control surface if no gate inspects it. This is a named concept worth tracking as context-to-control drift: metadata intended for routing and discovery starts shaping authorization-relevant behaviour. For practitioners, that means model-adjacent text needs the same scrutiny they would apply to executable policy inputs.

Centralizing credential injection changes the governance unit from server to dispatch layer. When per-server OAuth handling is replaced by one dispatch layer, revocation, rate limiting, and auditability become infrastructure properties instead of implementation choices. That does not remove the need for least privilege, but it does make privilege boundaries observable and repeatable. The implication is clear: if the enterprise cannot enforce access once, it will keep re-litigating it server by server.

MCP sprawl is where NHI lifecycle failure becomes visible to the business. Every added server increases the count of secrets, permissions, and maintenance paths that have to be governed. The deeper problem is that lifecycle controls were designed for a smaller number of more stable service identities, not for rapidly multiplying AI integrations. Practitioners should expect MCP to expose whether their NHI programme actually knows what exists, who owns it, and how it is retired.

From our research:

• 52% of public MCP servers are effectively dead, creating a maintenance and trust problem for enterprises adopting the protocol, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why server-level governance gaps keep reappearing.
• The governance lesson carries forward in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs, where provisioning, rotation, and offboarding need to be treated as one lifecycle.

What this signals

Context-to-control drift: MCP pushes enterprises to treat metadata, routing, and authorization as one governance surface. That matters because AI systems often trust what the protocol presents as descriptive text, so teams need inspection at the gateway rather than confidence in every upstream server.

If your programme already struggles with secrets sprawl, MCP will make the problem more visible rather than less. The immediate signal is that unmanaged server growth turns each integration into a standing NHI dependency, and the right response is to anchor control design in the NHI Lifecycle Management Guide rather than ad hoc developer trust.

Enterprises that want a stable AI operations model should align MCP governance with the NIST Cybersecurity Framework 2.0 so identification, protection, detection, and response all sit at the same control boundary.

For practitioners

• Inventory every MCP server as a governed NHI asset Record owner, upstream systems, credential type, tool scope, and retirement trigger before approving any server for production use.
• Centralize authentication and authorization at the gateway layer Use one dispatch layer for OAuth validation, credential injection, RBAC or ABAC policy enforcement, and per-user revocation across the fleet.
• Inspect tool metadata before it reaches model context Normalize and allowlist tool descriptions, then block servers that inject unreviewed instructions or ambiguous tool labels into the context window.
• Create offboarding criteria for dead or abandoned servers Remove servers that no longer receive commits, issue responses, or security patches, even if they still function for a narrow use case.
• Map MCP access to blast radius by server and tool Document which data sources, APIs, and internal systems each server can touch so a single vulnerability does not remain an unknown exposure path.

Key takeaways

• MCP sprawl turns AI integrations into governed identity assets, not just developer tooling.
• The biggest governance failures are fragmented auth, unknown blast radii, and unmaintained servers that stay trusted long after ownership is lost.
• A gateway approach only works if it centralizes policy, inspects tool metadata, and makes lifecycle control visible to IAM and NHI teams.

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.
• Tool description poisoning: A manipulation technique where malicious instructions are embedded in tool metadata that an agent reads before acting. The danger is that the agent may treat those instructions as trusted context, allowing unauthorized calls or data access without any obvious code change or network anomaly.
• Context-to-Control Drift: The condition where information intended to describe or route a request begins to shape access, execution, or model behaviour as if it were policy. In MCP environments, this happens when tool descriptions or metadata are consumed as trusted instructions.
• NHI Credential Lifecycle: NHI credential lifecycle is the end-to-end governance of machine credentials from creation through use, review, rotation, and retirement. It matters because service accounts, tokens, and certificates can remain active long after a team believes they have been controlled.

What's in the full article

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

• Step-by-step gateway architecture for centralizing OAuth, routing, and policy enforcement across MCP servers
• Practical guidance on vetting community MCP servers before they touch production systems
• Deployment considerations for STDIO, multi-server environments, and catalog-based governance models
• Examples of how the dispatch layer can handle credential injection and per-user revocation

👉 The full Obot article covers the gateway architecture, vetting workflow, and deployment trade-offs in more operational 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.