AI gateways vs MCP gateways: where each control layer fits

At a glance

What this is: This is an analysis of how AI gateways and MCP gateways differ, and why neither fully closes the security gap around agentic AI behaviour.

Why it matters: It matters because IAM and security teams need to place model access, tool access, and session governance in the right control layer instead of assuming one gateway covers all agent risk.

👉 Read Noma Security's analysis of AI gateways vs MCP gateways

Context

AI gateway is a term for the LLM inference proxy layer, while MCP gateway refers to the control point between an AI agent and its tools. In the article's primary usage, the two are related but not interchangeable, and that distinction matters for AI agent identity governance.

The governance problem is not just routing. Security teams need to understand where visibility ends, where identity enforcement begins, and why session-level control is different from request-level filtering. That is the core issue for AI gateway and MCP gateway evaluations, especially as agentic AI use expands across enterprise environments.

Key questions

Q: How should security teams decide whether they need an AI gateway, an MCP gateway, or both?

A: Start by mapping the control objective. Use an AI gateway for model traffic, cost control, and inference logging, and use an MCP gateway for tool authentication, tool registration, and per-tool access control. If you need to govern both model calls and tool use, you usually need both layers plus runtime correlation outside the gateway.

Q: Why do AI gateway and MCP gateway controls still leave security blind spots?

A: Because both are partial views of agent behaviour. An AI gateway sees model traffic, while an MCP gateway sees tool traffic, but agents can also act through shell commands, direct APIs, local execution, and vendor-managed surfaces. Without session-level context, a control can be correct and still miss the abuse chain.

Q: What do security teams get wrong about agent tool access?

A: They often treat tool connectivity as a simple integration problem. In practice, every API, SaaS connector, and MCP server expands the agent's reachable action set, so each tool must be authorised separately and limited to the minimum actions needed for the approved workflow.

Q: How do identity teams govern shared agents that inherit a maker's credentials?

A: Treat the maker's token problem as an entitlement lifecycle issue. Review who created the agent, who uses it, which privileges are inherited, and whether access changes when the consumer changes. If the agent is reused across teams, the original trust decision may no longer match current usage.

Technical breakdown

AI gateway vs MCP gateway: different traffic, different control points

An AI gateway sits between an application or agent and the model provider, so it governs prompts, completions, routing, cost, and logging for inference traffic. An MCP gateway sits between the agent and tool servers, so it governs tool calls, tool responses, authentication, and tool-level access. The distinction is architectural, not cosmetic. One sees model interaction, the other sees tool interaction. Some vendors bundle both, but the control problem remains split because the risks are split across model traffic and tool traffic.

Practical implication: map each control requirement to the correct traffic path before deciding whether a gateway can actually enforce it.

Why gateway visibility stops at the session boundary

The article highlights a structural limit: gateways see requests, but agent risk often emerges across a session. A tool call can be benign in isolation and malicious in sequence, especially when the agent has already touched sensitive data or received a compromised prompt. Per-request policy cannot reliably distinguish ordinary use from multi-step abuse without session context. That is why logging, filtering, and routing are helpful but incomplete. The security question is not only what was called, but what the agent was doing across the full interaction.

Practical implication: evaluate controls for session correlation, not just request inspection, if you need to detect abuse patterns.

Why MCP control does not equal full agent governance

MCP gateways improve identity and tool access control, but they only govern what routes through MCP. Agents can still act through native shell commands, direct API calls, file operations, and vendor-managed surfaces that never generate MCP traffic. The article also shows that local stdio transport and cloud-managed agent execution can bypass network-based visibility entirely. That means MCP governance is useful, but it is not a complete agent security model. It is one layer in a broader runtime control stack, not the stack itself.

Practical implication: pair MCP governance with endpoint, runtime, and identity-aware enforcement for the actions the gateway cannot see.

Threat narrative

Attacker objective: The attacker aims to make the agent perform harmful actions or expose data without those actions appearing in the gateway's governed view.

1. Entry occurs when the agent or developer session is routed through a gateway that only covers part of the agent's actual execution path, leaving other actions outside enforcement.
2. Escalation occurs when the agent uses tool calls, native shell commands, direct HTTP requests, or vendor-managed surfaces that bypass the gateway's control plane.
3. Impact follows when static request-level policy misses a multi-step session pattern, allowing data exposure, unauthorized actions, or blind spots in investigation.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

AI gateway and MCP gateway are separate governance layers, not substitutes. The article is right to separate model traffic from tool traffic because the identity problem differs at each layer. Model routing, logging, and cost control sit in one path; tool authorization, registry control, and per-tool entitlements sit in another. Practitioners should stop asking which gateway is better and instead ask which control plane covers which part of the agent's runtime behaviour.

Session-level visibility is the real control gap. Request-level inspection can validate a single prompt or tool call, but agent abuse often emerges only when those calls are chained. That is why both AI gateways and MCP gateways create useful telemetry without resolving the full security problem. The practical conclusion is that runtime governance must correlate identity, prompt context, model use, and tool use across the session.

Tool governance without non-MCP coverage leaves a false sense of control. The article's strongest warning is that agents can act through bash, direct API calls, file writes, and cloud-managed execution paths that never touch MCP. That means a neat-looking gateway deployment can still miss the most consequential actions. Security teams should treat gateway logs as partial evidence, not as proof of containment.

Maker's token inheritance is an identity governance failure, not just an AI platform quirk. When an agent runs under the creator's credentials and later serves other users, entitlement inheritance outlives the original trust decision. That pattern breaks the normal assumption that the current user and effective privileges stay aligned. Practitioners should recognize it as delegated access without clear lifecycle boundaries, especially where shared agents span business functions.

Identity-aware agent enforcement requires a control model that distinguishes who created the agent from who is driving it now. The article shows why static credential checks are not enough when agent permissions inherit across sessions and users. This is where traditional IAM, PAM, and NHI thinking needs to converge on the agent runtime, because the effective actor may change even when the credential does not. The practitioner takeaway is that agent identity must be resolved in context, not assumed from the first login.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That gap makes the case for OWASP Agentic Applications Top 10 and OWASP Agentic AI Top 10 alignment before agent deployment scales further.

What this signals

AI gateway and MCP gateway adoption will force identity teams to decide where governance really lives. If the control plane only sees a slice of the session, it cannot certify the whole interaction. That is why runtime enforcement will increasingly sit alongside gateway telemetry, not inside it, especially where shared agents and delegated credentials cross team boundaries.

Maker's token inheritance is becoming a governance pattern teams need to name, not just observe. When a shared agent carries the creator's rights into every later use, the problem is no longer configuration drift. It is entitlement inheritance that outlives the original trust decision, which means lifecycle review and access boundaries must follow the agent's real consumption pattern, not the original build event.

With 80% of organisations already seeing AI agents act beyond intended scope, per AI Agents: The New Attack Surface report, the next programme milestone is not more logging alone. Teams need a control design that joins identity, session context, and non-MCP execution paths before the gateway becomes a false assurance layer.

For practitioners

• Separate model-path and tool-path governance Inventory where AI gateways terminate and where MCP gateways begin, then document which traffic each layer can and cannot see. Use that map to prevent teams from assuming one control plane covers both model inference and tool access.
• Correlate decisions across the full agent session Require logging and detection that join prompts, tool calls, model responses, and downstream actions into one session record. Without that correlation, a multi-step abuse chain looks like harmless isolated events.
• Hunt for non-MCP execution paths Test whether agents can still use native shell commands, direct HTTP requests, local file operations, or vendor-managed backends outside the gateway. Treat those paths as governance gaps, not edge cases.
• Rework shared-agent entitlement models For maker-driven agents, separate creator privileges from effective runtime access and review whether shared use inherits rights that should have been bounded. If the user can change while the entitlement stays fixed, the lifecycle is broken.

Key takeaways

• AI gateways and MCP gateways solve different parts of the agent problem, so treating them as interchangeable weakens governance.
• The biggest blind spot is not a missing log entry, but the gap between request-level visibility and session-level behaviour.
• Identity teams should evaluate shared agents, inherited credentials, and non-MCP execution paths as one governance problem.

Key terms

• AI Gateway: A control point that sits between AI applications and the models, tools, or data they call. In practice, it can authenticate requests, enforce policy, inspect runtime behaviour, and stop unsafe actions before they spread into connected systems.
• 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.
• Maker's token: A shared-agent access pattern where the credentials or effective permissions of the person who built the agent are reused by later users. In practice, this can create entitlement inheritance that outlives the original trust decision and obscures who should be accountable for access.
• Session Governance: The practice of binding access to a specific task, time window, and execution context, then revoking it when the work is done. For non-human identities, session governance matters because tokens and delegated permissions often persist longer than the action they were created to support.

What's in the full article

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

• Gateway-by-gateway breakdown of routing, logging, and enforcement boundaries for AI and MCP traffic
• Examples of how real enterprise setups split model-path and tool-path control across products
• Practical deployment considerations for local agents, stdio transport, and cloud-managed surfaces
• Details on how vendors are converging gateway functions into shared control planes

👉 The full Noma Security article covers the control boundaries, blind spots, and convergence trends in more depth.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 or identity security programme, it is worth exploring.