Cloudflare AI Gateway stops at the edge, not the agent layer

At a glance

What this is: This comparison shows that Cloudflare AI Gateway secures the model-call edge, while agent identity, tool access, and MCP governance sit in a separate layer.

Why it matters: IAM and security teams need to separate edge controls from agent-runtime controls so they do not assume request logging or rate limiting also governs delegated tool use.

Context

Edge gateways protect model traffic, not the full identity and tool chain that appears when an application becomes an agent. Once an LLM call is followed by tool selection, MCP access, and delegated action, the governance problem changes from request handling to runtime authority and traceability. The key question is whether the platform can still explain who acted, which tool was used, and why.

This is where MCP security becomes relevant: the control boundary moves from provider-facing request handling to the layer where agents make and sequence tool calls. A clean architecture can use both layers, but only if teams recognise that each one terminates a different unit of work.

Key questions

Q: What breaks when AI gateways are treated as the source of trust for agents?

A: Trust collapses because gateways can inspect traffic, but they cannot prove who the agent is, who authorized it, or whether the action is permitted at that moment. That leaves organisations with good logs and weak governance. The missing control is a verifiable identity and an action-level policy decision outside the gateway.

Q: Why do agent systems need a different authorisation model than chat apps?

A: Chat apps usually need request-level protection, while agent systems need action-level protection because the runtime can choose tools and sequence work on behalf of a user. The security question changes from whether a prompt reached a model to whether a specific identity was allowed to trigger a specific action.

Q: How do security teams know if agent governance is actually working?

A: It is working only if the team can answer three questions quickly for any agent: what it can reach, what it did recently, and whether that behaviour matches intent. If any of those answers require manual reconstruction, governance exists on paper but not in operations.

Q: Should teams stack an agent layer above an AI gateway or replace the gateway entirely?

A: Replace neither by default. Use the gateway for provider-side optimisation and use the agent layer for identity-aware tool control, then combine them when the workload has both needs. The right answer depends on whether the risk is model traffic, delegated action, or both.

Technical breakdown

Why edge gateways cannot see agent identity

A cloud AI gateway terminates a single HTTP request to a model endpoint. That works for chat applications, where the main job is to route prompts, cache responses, and enforce rate controls. It breaks as soon as an application becomes an agent because the important control points shift to the calling user, the tool selected at runtime, and the downstream system the agent reaches through MCP or another tool bus. The gateway may still log tokens and latency, but it cannot map that request to delegated authority or tool-level intent. See the NHI Authentication Guide.

Practical implication: Treat the gateway as a transport and cost control layer, not as a substitute for agent identity governance.

How agent-layer auth changes the trust model

Agent-layer authorisation has to resolve who the user is, what the agent may do on that user’s behalf, and which provider or tool credentials should be used for the action. That requires identity-aware routing, consent or delegated authorisation, and logs that preserve the resolved identity behind the call. In practice, the control surface expands from a static API key to identity-bound access decisions across the model, the tool, and the audit trail. Without that, a platform knows a request happened, but not whether the right actor was allowed to perform it. See the LLM Provider API Key Security and LLMjacking Guide.

Practical implication: Bind provider keys, tool access, and audit records to the authenticated user rather than to a shared application identity.

Why prompt-injection defence belongs above the gateway

Prompt injection is a content-level attack, not a transport-level one. Once an agent reads tool output, issue text, or retrieved content, malicious instructions can attempt to alter the next step in the decision chain. An edge gateway cannot reliably inspect or neutralise that because it does not understand the agent’s internal sequence of reasoning or the trust boundary between model output and tool input. The right boundary is inside the agent runtime, where tool results can be quarantined, scored, or separated before they influence the next action. See the AI Agent Observability, Audit and Incident Response Guide.

Practical implication: Place injection controls where tool output re-enters the agent loop, not where the model request first leaves the application.

Threat narrative

Attacker objective: The attacker seeks to manipulate the agent’s next action or expand what the agent can do without crossing the controls enforced at the edge.

1. Entry occurs through a legitimate model request sent through an edge gateway, which is enough for transport handling but not enough to establish tool-level trust.
2. Credential or decision exposure happens when the agent runtime, not the gateway, selects tools and resolves delegated access on behalf of the caller.
3. Impact follows when malicious tool output or an over-broad tool permission changes what the agent does next, while the gateway still only sees a normal request and response flow.

NHI Mgmt Group analysis

Edge controls and agent controls are not the same governance problem. Cloud AI gateways answer questions about cost, latency, caching, and provider failover. Agent runtimes answer questions about delegated authority, tool choice, and who is acting on whose behalf. When teams collapse those into one layer, they create a false sense of coverage that leaves tool access and decision traceability outside the control model.

Runtime identity must follow the user, not the application shell. In agent systems, a shared API key for the gateway does not provide meaningful authorisation for the tools the agent can invoke. The real control issue is whether identity survives across model calls, tool calls, and MCP hops without being flattened into a generic app token. Practitioners should treat that as a delegated access problem, not a simple request-routing problem.

Tool governance becomes the new policy boundary once the model is no longer the only actor. The moment an agent can choose tools, the important security question shifts to whether each action is attributable, scoped, and isolated from untrusted context. That is why agent authorisation is more relevant than edge logging for the agent layer. The practical conclusion is simple: control the action path, not just the prompt path.

Identity blast radius starts at the layer where decisions are made. If a platform can cache and route model responses but cannot explain which identity authorised a tool call, then the blast radius of a compromised workflow is measured above the gateway, not at it. That is a governance gap in delegated execution, not a failure of the edge itself. Teams should separate infrastructure convenience from decision authority before agents reach production.

MCP security is the named concept that matters here: the security boundary moves from the model request to the tool invocation layer, where identity, authorisation, and context all need to be preserved. That boundary is where many agent stacks currently go thin, because they inherit assumptions from chat infrastructure that do not hold for delegated action. The practitioner takeaway is to design for tool mediation first and model mediation second.

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: NHI Authentication Guide

What this signals

Identity blast radius will become the deciding design variable for agent platforms. As teams add tools to AI workflows, the question is no longer whether the model is reachable, but how far a compromised or mis-scoped identity can move once the agent starts acting. Platform teams should expect more pressure to prove that model access, tool access, and user authority are joined rather than inferred.

Access review cadences will not be enough for agent runtime control. Governance processes built for periodic review assume there is a durable access state to certify. Agent systems create transient, action-scoped authority that may exist only for a single task, so the programme has to watch issuance and delegation boundaries instead of relying on post-hoc certification.

MCP security will increasingly sit beside IAM and PAM in architecture reviews. The practical distinction is that the gateway optimises calls, while MCP governs tool invocation and identity propagation across the agent loop. Teams that ignore that split will keep adding edge controls to solve a runtime authority problem they never actually see.

For practitioners

• Define the edge boundary precisely Use the gateway for caching, rate limits, failover, and provider routing, but do not treat it as the control point for agent actions or tool authorisation.
• Bind agent actions to a real user identity Require the runtime to resolve the signed-in user before model calls and tool calls, then record that identity in the audit trail.
• Separate tool access from model access Put policy around which tools an agent can invoke, which MCP servers it can reach, and which actions require per-user delegation.
• Inspect the audit trail for decision context Log the resolved identity, tool touched, and downstream action so investigators can reconstruct what the agent decided rather than only what endpoint it hit.
• Use the stack in the right order Place the agent layer in front of the gateway only when you need tool governance, then let the gateway continue handling edge optimisation behind it.

Key takeaways

• The central issue is not whether an AI gateway works, but whether it can govern delegated action once an agent starts using tools.
• Cloudflare AI Gateway is positioned as an edge control, while agent identity, MCP access, and prompt-injection defence belong to a different layer.
• Practitioners should separate transport optimisation from runtime authority so logging, caching, and rate limits do not get mistaken for agent governance.

Related NHI Mgmt Group resources: MCP Security Guide · NHI Authentication Guide · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide

Key terms

• Agent Layer: The agent layer is the part of an AI workload where the system makes runtime decisions and takes actions. It includes prompt handling, tool calls, code execution, network access, and data retrieval. In security terms, this is where control-plane visibility ends and behavior-based risk begins.
• Edge Gateway: An edge gateway is a front-line appliance or service that brokers access between external users and internal systems. It often handles authentication, session initiation, traffic inspection, or policy enforcement, so weaknesses in the gateway can affect both network security and the identity controls that depend on it.
• 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.
• Delegated Authorization: A model in which an application is allowed to act on a user’s behalf after explicit approval. In SaaS environments, delegated authorization is powerful but risky because excessive scope or weak revocation can turn a routine integration into durable non-human access.

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 programme, it is worth exploring.