MCP gateways centralise AI tool access, but governance still matters

At a glance

What this is: This is a practitioner analysis of MCP gateways, which centralise discovery, access control, distribution, and monitoring for MCP servers while leaving core governance questions unresolved.

Why it matters: IAM, NHI, and platform security teams need to separate operational convenience from governance, because centralised access does not automatically deliver least privilege, visibility, or lifecycle control.

Context

MCP gateways are centralisation layers for Model Context Protocol servers, which means they reduce the friction of connecting AI applications to APIs, files, databases, and other services. The governance question is not whether the gateway makes access easier, but whether it can enforce consistent authorisation and oversight once many tools sit behind one control point.

Obot’s article focuses on the operational shape of that problem: discovery, central management, access control, distribution, and monitoring. That is useful because it shifts the discussion away from one-off configuration and toward shared infrastructure, where IAM and NHI controls have to be designed for multi-team use rather than ad hoc setup.

At enterprise scale, the issue is sprawl, not just adoption. As more MCP servers are added, the central question becomes which identities, teams, and AI applications are allowed to use which tools, under what conditions, and with what review path when the tool estate changes.

Key questions

Q: What breaks when an MCP gateway centralises access without tool-level governance?

A: The control breaks when the gateway makes access easier to distribute than to review. Teams can end up with a shared entry point that hides different privilege levels behind one interface, which means the real authorisation boundary shifts from the tool to the gateway. That is convenient operationally, but risky if ownership and approval are not tied to each server.

Q: Why do MCP gateways create governance risk even when they improve usability?

A: They create risk because usability and governance solve different problems. A gateway can simplify discovery and distribution, yet still leave authorisation scope, ownership, and removal decisions unresolved. If those decisions are not formalised, the environment becomes easier to adopt but harder to govern as the number of connected tools grows.

Q: How should teams decide which MCP servers belong behind broader access controls?

A: Teams should classify MCP servers by business criticality, data sensitivity, and operational impact, then apply tighter controls to infrastructure and privileged systems. The gateway should not flatten those differences. A low-risk collaboration server can have broader reach than an admin-oriented tool, but both still need explicit review.

Q: How do organisations keep MCP server access from drifting over time?

A: They need an owner, an approval trail, and a removal process for every server in the registry. Without those three elements, the catalogue becomes a list of standing access paths that no one revisits. Lifecycle discipline is what keeps centralised distribution from turning into permanent entitlement.

Technical breakdown

Why MCP gateway centralisation changes the control plane

An MCP gateway acts as a broker between AI applications and the external tools they call. Instead of every developer wiring up local server definitions, the gateway provides a shared directory, policy point, and distribution layer. That makes operations more manageable, but it also concentrates trust: one gateway decision can expose many downstream tools. In identity terms, the gateway becomes the place where access intent, tool availability, and monitoring need to be aligned. Without that alignment, the environment becomes easier to administer but harder to govern, because the same control point can mask uneven permissions across different MCP servers.

Practical implication: Treat the gateway as a policy enforcement point, not just an inventory hub, and validate whether each server behind it still has distinct access rules.

Authentication and authorisation scope across MCP servers

The article highlights authentication and access control as the hard parts of scaling MCP. That is because a gateway can standardise how access is brokered without defining what each connected tool should be allowed to do. In practice, the risk is over-broad authorisation, where users or AI applications gain access to a server but not to narrowly scoped actions inside it. This is especially relevant when the same gateway fronts both low-risk collaboration tools and higher-risk infrastructure systems. The governance challenge is to keep authentication consistent while preserving tool-level differences in privilege, approval, and monitoring.

Practical implication: Map each MCP server to its own privilege boundary and review whether gateway-wide access masks overbroad tool permissions.

Monitoring and lifecycle control for distributed tool access

Central monitoring helps, but it does not automatically give lifecycle governance. If teams can add MCP servers quickly, they can also accumulate stale, unused, or overly trusted connections just as quickly. That is an identity problem as much as an operations problem, because tool access has to be owned, reviewed, and removed when business need changes. In enterprise settings, the gap is often not visibility alone, but whether the environment can prove who can use a server, whether they still should, and how that entitlement is retired when it is no longer justified.

Practical implication: Tie MCP server onboarding and removal to an access review and offboarding process so distribution does not outrun governance.

Breaches seen in the wild

• 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.
• MongoBleed breach: MongoBleed exposed secrets across 87K MongoDB servers.

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 does not eliminate governance drift, it relocates it. A gateway can remove manual setup chaos, but it also creates a single layer where inconsistent tool scopes can hide behind a common interface. That means practitioners should stop thinking of MCP adoption as a developer convenience problem and start treating it as a shared access governance problem for AI-connected tools.

The real control gap is authorisation granularity, not connectivity. Connecting AI apps to more systems through one gateway is only useful if the downstream permissions remain differentiated by task, team, and risk. Without that separation, the gateway becomes a convenience wrapper around over-broad access, which is exactly the sort of condition IAM programmes are supposed to prevent.

Lifetime control matters as much for MCP servers as for any other non-human access path. If a server is added once and then left in place indefinitely, the platform quietly accumulates standing access that no one revisits. The practical implication is that MCP registries need ownership, review, and removal logic, not just a catalogue of available tools.

MCP sprawl is identity sprawl: the more tools an enterprise exposes through a gateway, the more it needs an explicit model for who may use which server and why. This is not a tooling issue alone; it is a governance design issue that touches IAM, NHI oversight, and platform operations at the same time.

Gateway centralisation will push teams toward standardisation, but standardisation is not the same thing as assurance. The market signal here is that enterprises want shared distribution and monitoring for MCP, yet the hard questions remain around authorisation scope, monitoring quality, and offboarding discipline. Practitioners should treat the gateway as a control surface that still needs policy, review, and exception handling.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

MCP gateway governance is becoming an access-control problem, not just a tooling problem. Once a shared gateway sits between AI applications and downstream services, the important question is no longer whether teams can connect tools quickly. It is whether each connection has an owner, a review path, and a clear retirement condition before the registry becomes a shadow inventory of entitlements.

Tool discovery without entitlement discipline creates hidden privilege accumulation. A gateway can make it easier to find and distribute MCP servers, but that same convenience can normalize broader access than individual teams would approve in isolation. Practitioners should expect pressure to standardise the front door while preserving different back-end privilege models for collaboration, data, and infrastructure systems.

MCP sprawl is measurable in exposed secrets, not just in server count. 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026. That is a warning that governance has to reach configuration, distribution, and offboarding together, not only the access layer.

For practitioners

• Define server-level ownership Assign a named owner to every MCP server exposed through the gateway, with responsibility for access scope, monitoring, and removal when the tool is no longer needed.
• Separate low-risk and high-risk tools Do not apply the same default access posture to collaboration tools and infrastructure systems; treat each MCP server as a distinct entitlement boundary.
• Review gateway-wide permissions Check whether central distribution has flattened privilege boundaries, especially where one AI application can reach multiple tools from the same portal.
• Add offboarding to the MCP lifecycle Require removal of unused or obsolete MCP servers as part of the same process used to approve new ones, so the registry does not accumulate stale access.

Key takeaways

• MCP gateways reduce operational friction, but they do not remove the need for explicit authorisation boundaries across connected tools.
• The main governance risk is that central distribution can conceal over-broad privilege, stale access, and inconsistent ownership.
• Enterprises need lifecycle controls for MCP servers, including ownership, review, and removal, or the registry will become permanent entitlements.

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.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Tool-level Authorization: Tool-level authorization is the practice of checking permissions on each discrete action a client asks an MCP server to perform. It matters because LLMs can generate dynamic requests, so access control must be enforced where the action is executed, not only where the request is formed.
• Mcp Registry: An MCP Registry is a catalog that lists available Model Context Protocol servers, tools, and resources for AI agents to discover and use. It typically stores metadata such as endpoints, capabilities, ownership, and trust information, helping organizations govern which tools agents can access and how those connections are managed.

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.