By NHI Mgmt Group Editorial TeamBased on Kong: “What is an MCP Gateway? Key to Secure Enterprise AI at Scale” (February 16, 2026)

TL;DR: MCP gateways are emerging as the missing control layer for enterprise AI, centralising authentication, routing, policy enforcement, and observability as AI agents fan out across more servers, according to Kong. The governance problem is not protocol support alone, but the collapse of manageable trust boundaries once access, routing, and audit move point to point.


At a glance

What this is: This is Kong’s explanation of why MCP gateways are emerging as the control layer for enterprise AI access, with the core finding that centralising authentication, routing, policy enforcement and observability helps contain MCP sprawl.

Why it matters: For IAM, PAM and NHI teams, the issue is that every additional MCP server multiplies access paths, policy surfaces and audit complexity, so gateway design becomes an identity governance decision rather than just an infrastructure choice.

By the numbers:

  • Organizations using AI in at least one business function jumped from 55% to 78% in just one year, according to Stanford HAI AI Index Report data cited by Kong.
  • Generative AI usage specifically rose from 33% in 2023 to 71% in 2024, according to Stanford HAI AI Index Report data cited by Kong.

Context

Model Context Protocol, or MCP, is an open way for AI clients to reach tools and data sources through MCP servers. As enterprises add more AI agents and more servers, the access model stops looking like a simple integration pattern and starts looking like an identity and governance problem.

Kong’s article focuses on the control gap that appears when each agent talks to multiple servers directly. The practical issue is not whether MCP works, but whether organisations can keep authentication, routing, policy enforcement and auditability coherent once the environment scales beyond a few endpoints.

For IAM and NHI programmes, the underlying question is who controls tool access when the actor is an AI client rather than a human user. That makes gateway placement, policy consistency and observability part of the identity architecture, not just the network path.


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 gateways matter to identity governance for AI agents?

A: MCP gateways sit at the point where agents request access to tools, data, and downstream APIs, so they become the operational boundary for authorization and audit. That makes them part of identity governance, not just infrastructure plumbing. If the gateway cannot bind requests to a clear control model, agent access becomes difficult to govern or investigate.

Q: How can organisations tell whether MCP access is actually being governed?

A: A governed MCP deployment can answer who requested access, what scope was granted, when the token expires, and which tool calls were made under that token. If logs only show a shared credential or generic server activity, the organisation does not have effective identity governance for the protocol.

Q: What happens when AI agents fan out across too many MCP servers?

A: The operational result is configuration sprawl, fragmented audit evidence and a wider attack surface. The governance result is harder recertification, weaker accountability and more difficulty proving which tool access was actually used in a session.


Technical breakdown

Why point-to-point MCP access breaks at scale

Direct MCP connections create a many-to-many access pattern in which each AI client must know each server, each credential path and each policy edge. That model becomes brittle as soon as the server count grows, because every change forces coordinated updates across the client estate. A gateway collapses that topology into a single control point, which is why it becomes attractive in production. The technical issue is not only routing efficiency, but the loss of manageable trust boundaries when access is distributed across many endpoints.

Practical implication: treat uncontrolled server fan-out as an access-governance problem, not just an operations problem.

How authentication and policy enforcement shift into the gateway

An MCP gateway sits between the client and the server, so identity checks happen before the request reaches backend tools. In practice, that means OAuth, OIDC, SSO integration, RBAC and ABAC can be applied once at the front door instead of recreated across every server. This also changes the audit model: the gateway becomes the enforcement and logging layer, while servers stay focused on tool execution. For NHI governance, that separation matters because access decisions become centralised and reviewable rather than fragmented across tool endpoints.

Practical implication: make the gateway the policy enforcement point when you need consistent access control across many MCP servers.

Why routing and observability are part of identity control

MCP gateways do more than proxy traffic. They route requests to the right tool, preserve session state for multi-step interactions and create a single place for logs, metrics and traces. That matters because agentic workflows are often stateful, so the security question becomes not just whether access is allowed, but how each step is attributed and observed across a chain of tool use. Without that central layer, audit evidence is split across servers and the operational picture becomes incomplete. The result is weaker accountability and slower incident investigation.

Practical implication: require centralized tracing and session-aware logging wherever AI agents can chain multiple tool calls.


Threat narrative

Attacker objective: The objective is to exploit distributed MCP access paths to reach tools or data with weaker control, then evade consistent oversight across the server estate.

  1. Entry occurs when AI clients connect directly to multiple MCP servers without a shared control point, expanding the exposed access surface and multiplying credential paths.
  2. Privilege and policy abuse follow when authentication, routing and access checks are implemented inconsistently across servers instead of being enforced once at a gateway.
  3. Impact is operational and governance-related, with fragmented audit trails, harder incident review and a broader attack surface for tool abuse or misrouting.
  • Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
  • LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Centralising MCP access is becoming an identity architecture decision, not a convenience choice. Once AI agents consume tools through many servers, the control plane must define who can reach what, under which policy and with what evidence. That pushes gateway design into the same governance conversation as workload identity, access review and privileged access. Practitioners should treat the gateway as the policy boundary for agentic access.

The manageable trust boundary collapses when MCP access is distributed point to point. The old assumption was that each endpoint could be governed as a separate integration, but that assumption fails when every agent can fan out across dozens of servers. The implication is that review, logging and authorization no longer scale cleanly at the server edge; they have to concentrate at the front door.

Session-aware routing is now part of identity governance for AI clients. Statefulness changes the risk model because the same agent session can traverse several tools while preserving context. That means access decisions, traceability and scope control must survive the full interaction path, not just the initial login event. Practitioners should model MCP gateways as governance layers for delegated machine action.

Endpoint proliferation is the new MCP governance debt: every additional server increases credential sprawl, policy drift and audit fragmentation unless a central control layer is imposed. This is especially important where agents are the primary clients, because their access patterns are dynamic and harder to review after the fact. The practical conclusion is that enterprises need one place where policy, routing and evidence converge.

MCP gateway adoption signals where the market is heading: from protocol standardization to control-plane standardization. The protocol alone defines how clients and servers communicate, but it does not solve how enterprises govern that communication at scale. That gap is where identity, observability and routing converge, and it is now the decisive design problem for production AI.

From our research library:

What this signals

MCP gateways are the point where AI access becomes governable at enterprise scale. Once clients fan out across multiple servers, the questions stop being purely architectural and become about who authorizes tool use, where logs live and how session state is traced. That is why the gateway increasingly functions like the identity boundary for agentic systems, even when the protocol itself stays neutral.

Endpoint proliferation creates identity debt for AI programmes. Every additional server adds another path for credentials, another place for policy drift and another audit surface to reconcile. Teams that leave routing and authorization distributed across the stack will struggle to prove which agent did what, through which tool, and under what authority.


For practitioners

  • Define the gateway as the enforcement point Place authentication, authorization and policy checks at a single MCP gateway instead of duplicating them across individual servers.
  • Inventory every direct MCP path Map all AI clients, servers and credential paths so you can see where point-to-point access still bypasses centralized governance.
  • Require session-level tracing Ensure logs, traces and correlation IDs follow the full AI interaction so multi-step tool use can be reconstructed later.
  • Separate tool execution from access control Keep MCP servers focused on business logic while the gateway owns routing, policy enforcement and access observation.

Key takeaways

  • MCP gateways are emerging because direct client-to-server access does not scale cleanly once AI agents need to reach many tools under consistent controls.
  • The main risk is governance fragmentation, with authentication, routing and audit evidence spreading across too many endpoints to manage reliably.
  • Enterprises should treat gateway placement, session tracing and centralized policy enforcement as core identity decisions for agentic AI access.

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.
  • Session Affinity: Session affinity is the practice of keeping related requests on the same backend path so context is preserved across multi-step interactions. In agentic environments, it matters because tool calls often depend on prior state, but that state must still remain visible and auditable.
  • Policy Enforcement Point: A policy enforcement point is the control that applies an authorization decision at the place where an action occurs. In distributed systems, it may sit inside an API gateway, application, or workflow engine, and it depends on a consistent decision format to avoid bespoke integrations.
  • Agentic Access: Agentic access is delegated system access granted to an AI agent or autonomous workflow so it can perform defined tasks across tools and data sources. It differs from human access because the actor can execute continuously, combine actions quickly, and amplify mistakes at scale.

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.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org