Why do MCP deployments need more than a standard API gateway?

Why This Matters for Security Teams

MCP is not just another API surface. It is a tool-discovery and tool-execution layer that sits inside agent workflows, which means the security question is not only “can traffic reach the server?” but “what can the agent discover, chain, and invoke once connected?” A standard gateway is designed for request routing and coarse policy enforcement, not for governing multi-turn context, tool scope, or trust in dynamically selected actions.

That gap matters because MCP servers often expose far more than teams expect. NHIMG research on The State of MCP Server Security 2025 found that only 18% of MCP server deployments implement any form of access scoping for tool permissions, which helps explain why basic perimeter controls miss real risk. The industry is converging on stronger guidance through OWASP Agentic AI Top 10 and NHIMG’s OWASP Agentic Applications Top 10, both of which treat tool misuse and agentic abuse as first-class threats.

In practice, many security teams encounter MCP risk only after a tool has already been over-permissioned and the agent has used it in an unexpected workflow, rather than through intentional governance.

How It Works in Practice

Standard api gateway still matter, but they should be treated as transport controls, not as the full control plane for MCP. The deployment pattern that works best is layered: the gateway handles authentication, rate limiting, and basic request filtering, while an MCP-aware policy layer decides which tools, prompts, and resources are available to a specific agent at runtime.

This is where workload identity and runtime authorization become essential. For autonomous or semi-autonomous agents, static RBAC often fails because the agent’s next action is not fully predictable in advance. Current guidance suggests moving toward context-aware authorization, short-lived credentials, and per-task scoping so that access is issued only when the agent can justify a specific action in a specific context. That is consistent with broader NHI governance principles in the Ultimate Guide to NHIs — Standards.

Operationally, teams should look for three controls that a gateway alone does not provide:

• Tool-level authorization, not just endpoint authorization, so one MCP server cannot expose every function to every agent.
• Request-time policy evaluation, ideally with policy-as-code, so access can account for task, identity, environment, and data sensitivity.
• Continuous logging of tool discovery, tool invocation, and downstream effects, so investigations can reconstruct agent behavior across multiple turns.

For implementation thinking, it helps to compare MCP governance to agentic AI security patterns described in NIST AI risk guidance and in OWASP Top 10 for Agentic Applications 2026. The core point is the same: policy must follow the action, not just the session. These controls tend to break down when MCP is exposed directly to loosely governed agents in fast-moving development environments because tool catalogs expand faster than entitlement reviews.

Common Variations and Edge Cases

Tighter MCP governance often increases operational overhead, requiring organisations to balance developer speed against the need for precise tool control. That tradeoff becomes sharper in environments where agents are experimenting with discovery workflows, because rigid allowlists can frustrate legitimate use while loose controls create hidden blast radius.

There is no universal standard for this yet. Current guidance suggests treating MCP servers differently depending on whether they are internal-only, partner-facing, or reachable by production agents. Internal sandbox servers may tolerate broader discovery, but production systems should enforce explicit tool registration, scoped credentials, and per-agent trust boundaries. This aligns with the direction of agentic governance in Analysis of Claude Code Security, where tool use and execution context matter more than simple network reachability.

Edge cases also include multi-agent pipelines, where one agent discovers tools and another executes them. In those flows, a gateway can see only a series of requests, while the real risk sits in the handoff between agents. Another common failure mode is secret leakage through configuration and tool metadata, which is why NHIMG research on McDonald's McHire AI Chatbot Default Credentials is a useful reminder that exposed defaults and static secrets remain a recurring weakness.

The practical rule is simple: when the environment includes autonomous tool selection, shared context, or downstream side effects, a gateway is necessary but not sufficient.

Related resources from NHI Mgmt Group

• Who is accountable when an MCP tool call is authorised through a gateway and fails downstream?
• How should security teams implement MCP tool approvals in gateway-controlled environments?
• What are MCP Authorization Extensions and how do they help organizations?
• What is MCP in the context of AI security?