Notifications
Clear all
Topic starter
24/07/2026 4:10 pm
TL;DR: AI gateways control model traffic while MCP gateways control tool traffic, but neither governs the full agent session or the non-MCP actions that matter most for security, according to Noma Security. The gap is not terminology alone: runtime enforcement, session context, and identity-aware control still require a separate governance layer.
NHIMG editorial — based on content published by Noma Security: AI gateways and MCP gateways, and what each one actually controls
Questions worth separating out
Q: How should security teams decide whether they need an AI gateway, an MCP gateway, or both?
A: Start by mapping the control objective.
Q: Why do AI gateway and MCP gateway controls still leave security blind spots?
A: Because both are partial views of agent behaviour.
Q: What do security teams get wrong about agent tool access?
A: They often treat tool connectivity as a simple integration problem.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Noma Security's analysis of AI gateways vs MCP gateways →
AI gateways vs MCP gateways: what governance gap are teams missing?
Explore further
24/07/2026 4:13 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI gateways vs MCP gateways: where each control layer fits
