TL;DR: An MCP gateway centralises identity, permissions, policy enforcement and audit between AI agents and MCP servers, while also filtering tool discovery and action-level access, according to Willow. The practical shift is that enterprises must govern agent-to-tool calls as a distinct control plane, not as ordinary API traffic, because discovery and execution now happen dynamically.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Willow's blog post: MCP gateways sit between AI agents and MCP servers to govern discovery, identity, permissions, and audit.
Why it matters: It matters because agentic systems change access from fixed integrations to dynamic tool discovery and action selection, which requires a governance model that can evaluate each call in context.
Context
MCP gateways address a governance gap that appears when AI agents can discover tools dynamically and act through structured calls instead of fixed application paths. In that model, the problem is not connectivity alone but deciding which agent can see which tool, under whose identity it acts, and what evidence remains after execution.
The first assumption that breaks is that access can be governed only at provisioning time. Once an agent can choose tools at runtime, identity, permission, and audit controls have to sit on the path between the agent and the tool, not only around the underlying system.
Key questions
Q: How should security teams govern AI agents that can access enterprise systems?
A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.
Q: Why do MCP gateways matter if we already have API gateways?
A: API gateways manage fixed application traffic, but MCP gateways govern tool discovery, agent context, and action selection. That difference matters because agents can choose what to call at runtime, which means security must evaluate the request in context, not just the endpoint. Existing API controls help, but they do not fully govern agent behaviour.
Q: What are the biggest governance mistakes with MCP in production?
A: The most common mistakes are treating every agent as equivalent, exposing too many tools by default, and relying on routing controls without action-level policy. Teams also underestimate the importance of identity propagation and audit evidence. Those gaps turn a useful integration layer into an ungoverned access path.
Q: When does an MCP gateway become a better control than point-to-point integrations?
A: It becomes the better control when multiple teams, tools, or agents need shared access and the organisation can no longer rely on bespoke approvals. At that point, central policy, consistent identity handling, and standard audit evidence matter more than speed of one-off wiring. The trade-off is less duplication and more governance.
Technical breakdown
How an MCP gateway governs tool discovery and action
An MCP gateway sits in front of MCP servers and governs the tools/list handshake, tool selection, and downstream calls over JSON-RPC. That matters because an agent does not merely invoke a fixed endpoint, it first discovers capability and then chooses what to do. The gateway can filter visible tools, enforce action-level permissions, and bind the request to user, group, or machine identity before execution. In practical terms, this is closer to policy enforcement for agent decisions than classic request forwarding. Read OWASP Agentic Applications Top 10.
Practical implication: Treat tool discovery as a governance event and not just a catalogue lookup.
Why MCP gateways are not the same as API gateways
Traditional API gateways are designed for fixed application traffic, endpoint routing, authentication, and rate limiting. MCP gateways must also understand agent context, tool discovery, and structured action selection, which changes the security problem materially. The control question becomes whether a specific agent should be allowed to discover and execute a specific tool action in a given context. That is why API gateway patterns help with transport control, but they do not by themselves solve agent-to-tool governance. See the MCP Security Guide.
Practical implication: Do not assume existing API gateway policy covers agentic tool use without additional identity and action controls.
What runtime guardrails add to enterprise MCP control
Runtime guardrails extend governance beyond allow or deny decisions. They can inspect prompts, tool arguments, and outputs, then limit what the agent can pass onward or receive back. That is important because the risk often emerges after a tool is approved, not before it is discovered. In enterprise terms, the control plane has to watch for overbroad output, sensitive context leakage, and unsafe action sequences while still preserving useful automation. See the Agentic AI Security Guide.
Practical implication: Place policy checks at both discovery time and execution time, not only at connection setup.
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.
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
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
MCP gateways formalise the missing control plane for agentic access: once an agent can discover tools dynamically, route selection itself becomes a governance decision. That collapses the old assumption that the important control point sits only at the API perimeter. Enterprises now need a decision layer that understands agent identity, tool scope, and action intent before the call reaches the target system.
The security issue is not just sprawl, it is delegated autonomy without sufficient policy locality: point-to-point integrations make every new agent another access path, and every path another audit problem. An MCP gateway gives platform teams one place to bind identity, permission, and runtime constraints to tool use instead of scattering them across teams and connectors.
Tool discovery must be treated as a privileged event: if an agent can see every available capability, discovery itself becomes a source of overexposure. Filtering tool visibility is not a convenience feature, it is how enterprises prevent capability drift from becoming privilege drift. least privilege for AI agents starts at discovery, not after the action is chosen.
MCP governance and classic API governance are adjacent but not interchangeable: the former governs a decision-making client that can select actions at runtime, while the latter governs fixed client-server traffic. That distinction matters because an enterprise can be compliant at the API layer and still be exposed at the agent layer. The practical conclusion is to align identity, policy, and audit around the agent-to-tool relationship itself.
Shadow AI becomes harder to ignore once MCP is operationalised: the more agents connect to common tools, the more unsanctioned or lightly governed paths emerge. An enterprise control plane is therefore not only about access approval, but also about inventory, observability, and proving which agent acted under which identity. That is the governance baseline practitioners should assume before rollout.
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.
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Authorisation Guide
What this signals
The governance shift is that agentic access now needs a policy plane that can decide before a tool is visible, not only before a tool is executed. Without that, organisations end up with approved routes but ungoverned discovery, which is how shadow AI paths and privilege drift accumulate across teams.
Identity locality for agents: the control boundary moves closer to the request itself, because the identity that matters is the one acting at the moment of tool use. That means enterprises should expect more pressure to connect agent routing, delegated identity, and audit evidence into one enforcement point rather than separate systems.
For practitioners
- Define agent-to-tool policy boundaries Specify which tools each agent can discover, which actions it can perform, and which identities it may act under before broad rollout.
- Extend identity to the gateway layer Bind the gateway to your identity provider so agent requests inherit user, group, or machine context instead of relying on shared tokens alone.
- Separate read from write permissions Allow agents to inspect approved tools where needed, but block delete, export, admin, and other high-impact actions unless explicitly justified.
- Log action-level evidence Capture which agent called which tool, on behalf of which identity, with what arguments and outcome, so reviews are traceable later.
- Inventory shadow AI paths Review direct agent connections, unsanctioned integrations, and duplicated tool routes so governance is not limited to the approved gateway path.
Key takeaways
- MCP gateways are about governing agent-to-tool decisions, not just moving traffic between systems.
- The main control problem is dynamic discovery, because an agent can reveal and use capabilities at runtime that would never be safe to expose broadly.
- Enterprises need identity binding, action-level policy, runtime guardrails, and audit evidence to make MCP usable beyond pilots.
Related NHI Mgmt Group resources: AI Agent Authorisation Guide · Agentic AI Identity Guide · Zero Trust for AI Agents · AI Agent Observability, Audit and Incident Response Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on governing agent identity and privilege at the tool boundary. |
| ASI02 — Tool Misuse | MCP gateways are built to prevent unsafe or overbroad tool use by agents at runtime. | |
| ASI07 — Insecure Inter-Agent Communication | The article discusses governed handshakes and context transfer between agents and tool services. | |
| Recommendation — Apply ASI03 by binding each agent action to a verified identity and least-privilege scope. Use ASI02 controls to restrict which tools an agent can discover and invoke in each context. Apply ASI07 to control how agent context is passed into tool calls and downstream services. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Gateway identity propagation and delegated access depend on strong machine and agent authentication. |
| NHI-05 — Overprivileged NHI | The article repeatedly warns that agents must not receive broad tool access by default. | |
| Recommendation — Enforce NHI-04 so every agent request is authenticated before it can discover or call tools. Use NHI-05 to scope agent permissions to the minimum tool and action set required. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The gateway is an authorization layer for agent access to tools and actions. |
| Recommendation — Apply PR.AA-05 to evaluate and enforce tool-level permissions before each agent action. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article’s threat pattern is overbroad access that can be reused across tools and systems. |
| Recommendation — Map agent overreach to TA0006 and TA0008 to hunt for credential misuse and lateral movement paths. | ||
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 Discovery Governance: The practice of filtering which tools an AI agent can discover before it requests access or takes action. In an MCP environment, discovery is not neutral metadata exposure, because visibility itself shapes the agent's options and therefore the organisation's risk surface.
- Object Level Authorization: Object level authorization controls access to individual records or resources, not just to an endpoint. It prevents users from reaching data that is technically available through a route but should remain hidden according to policy, role, or ownership. This is a key safeguard against broken access control.
- Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.
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 identity security across human and non-human access, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org