The Cloudflare AI Gateway egress path stops at the model. Cloudflare AI Gateway proxies your LLM API requests to add caching, cost analytics, retries, and rate limiting, but it never sees or blocks the outbound tool actions an autonomous agent takes afterward. To control the agent's actual network egress (HTTP calls, MCP tool invocations, webhooks, DNS), you need a dedicated egress proxy alongside it.
Why the Cloudflare AI Gateway egress path stops at the model
An AI gateway is a reverse proxy for model traffic. When your application calls api.openai.com or api.anthropic.com, you route that request through Cloudflare AI Gateway instead. It gives you a unified endpoint, response caching, token and cost dashboards, and per-key rate limits. That is genuinely useful LLMOps plumbing.
But an agent does far more than call a model. After the model returns a tool-call decision, the agent executes it: it hits a payments API, posts to a Slack webhook, runs curl from a code interpreter, resolves a domain over DNS, or opens a connection to an MCP server. None of that traffic flows through the AI gateway. The gateway sits on the inference boundary. The dangerous actions happen on the network boundary, which the gateway simply does not occupy.
The two boundaries, and why you need both
Think of an agent request lifecycle as two distinct control points. The inference boundary is where prompts and completions move between your app and the model provider. The network boundary is where the agent's decisions become real-world side effects. A prompt classifier or an AI gateway lives at the first boundary. An egress proxy lives at the second.
| Capability | Cloudflare AI Gateway | Agent G egress proxy |
|---|---|---|
| Caches and meters LLM API calls | Yes | No (not its job) |
| Inspects agent tool-call arguments | No | Yes |
| Default-deny domain allowlist for egress | No | Yes |
| Blocks exfiltration to unapproved hosts | No | Yes |
| Human-in-the-loop approval on risky actions | No | Yes |
| Wire-level audit log of every outbound call | Partial (model calls only) | Yes (all egress) |
| Blocks metadata endpoint and SSRF paths | No | Yes |
These layers are complementary, not competitive. Cloudflare optimizes model traffic. Agent G governs what the agent is allowed to do with the model's output.
The combined agent security stack
Here is how the two components fit together in a production deployment. The gateway sits in front of the LLM. The egress proxy sits in front of everything the agent reaches on the network.
- Step 1: Route model calls through Cloudflare AI Gateway. Set your OpenAI or Anthropic base URL to the gateway endpoint. You now get caching, cost visibility, and provider failover.
- Step 2: Route all outbound agent traffic through Agent G as the egress proxy. Set
HTTP_PROXYandHTTPS_PROXY(or point your Kubernetes egress at the proxy service) so every tool call, webhook, and MCP connection transits it. - Step 3: Configure a default-deny allowlist in Agent G. The agent can reach the model (via the gateway host), your sanctioned APIs, and approved MCP servers. Everything else is denied at the wire.
- Step 4: Add tool-argument inspection and DLP normalization so encoded secrets or PII cannot slip out through an allowed domain.
- Step 5: Gate high-impact actions (wire transfers, destructive database calls, external posts) behind human-in-the-loop approval.
- Step 6: Stream Agent G's egress logs to your SIEM for detection and audit evidence.
The result: the gateway keeps your model spend efficient and observable, while the egress proxy contains the blast radius of anything the agent decides to do.
What the gateway cannot stop on the AI gateway egress path
Consider a concrete failure mode. An indirect prompt injection lands in a document your agent retrieves. The model, doing exactly what it was told, emits a tool call that posts your customer table to attacker-webhook.example. Cloudflare AI Gateway happily proxied the model call that produced that decision. It logged the tokens. It has no mechanism to intercept the subsequent POST, because that POST never touches the gateway.
An egress proxy does. Agent G sees the outbound request, evaluates it against policy (is attacker-webhook.example on the allowlist? No.), and drops it before a single byte of customer data leaves. The same applies to DNS tunneling, SSRF against the cloud metadata endpoint at 169.254.169.254, and secret exfiltration disguised as base64 in a query parameter. These are network-layer threats that require a network-layer control.
When you might not need both
If you are only calling a single model provider directly with no autonomous tool use, the gateway alone may cover your caching and metering needs. But the moment your application becomes agentic (the model can choose actions that hit external systems), the egress proxy is no longer optional. Autonomy without egress control is an open exfiltration channel with a dashboard bolted on. For a deeper split of these responsibilities, compare an LiteLLM proxy versus an AI agent firewall, which faces the same boundary problem.
Deploying the egress layer without breaking tool calls
The common objection to inserting an inline egress proxy is latency and TLS breakage. Agent G is built as a drop-in proxy with sub-millisecond policy evaluation on the hot path, and it performs TLS interception designed not to break well-behaved tool clients. You configure it once at the network layer, define policy as code in Git, and every agent behind it inherits the same default-deny posture. There is no per-agent SDK integration required, which matters when you run heterogeneous frameworks (LangChain, CrewAI, custom loops) behind one control plane.
Frequently Asked Questions
Does Cloudflare AI Gateway block agent tool calls?
No. Cloudflare AI Gateway proxies and caches your LLM API traffic for analytics, cost control, and rate limiting. It does not inspect or block the outbound tool actions (webhooks, API calls, MCP invocations) an agent performs after the model responds. That enforcement requires a dedicated egress proxy on the network boundary.
Can I run Cloudflare AI Gateway and an egress proxy together?
Yes, and you should. Route model calls through the gateway for caching and metering, then route all agent outbound traffic through an egress proxy like Agent G for default-deny allowlisting, tool-argument inspection, and human-in-the-loop approval. The layers cover different boundaries and complement each other.
What threats does an egress proxy catch that an AI gateway misses?
An egress proxy catches data exfiltration to unapproved hosts, DNS tunneling, SSRF against the cloud metadata endpoint, encoded secret leakage, and destructive external actions. These happen on the network path after the model call, which an AI gateway never sees. Compare approaches in our alternatives overview.
Does adding an egress proxy slow down my agents?
Agent G evaluates policy on the hot path in under a couple of milliseconds and uses TLS interception designed not to break compliant tool clients. Configured once at the network layer, it adds negligible overhead while giving you full outbound visibility and control across every agent framework.
Cloudflare AI Gateway makes your model traffic fast and observable. It does not govern what your agent does next. To close the Cloudflare AI Gateway egress gap, pair it with an inline egress proxy that inspects, allows, denies, and gates every outbound action. Explore the MCP gateway and how Agent G enforces default-deny egress allowlists and SSRF protection at the wire. Ready to complete your agent stack? Request access to the Agent G private beta and lock down the boundary your gateway cannot see.