Egress control was hard before AI. AI made it harder.
Controlling where data can leave your organization has always been one of the harder problems in security. AI agents took an already difficult problem and made it worse in three specific ways: agents talk to many providers, they generate traffic autonomously, and they run in the one place your network controls see least clearly — the developer workstation.
Security architects know the standard toolkit: DNS filtering to block known-bad or unapproved domains, and cloud API gateways to route and inspect provider traffic. Both are useful. Both are part of a good program. Neither is sufficient for AI agent egress, and understanding exactly why is the difference between a control that works and one that gives false comfort.
Where DNS filtering falls short
DNS filtering blocks resolution of disallowed domains. It is cheap, broad, and easy to deploy. It also has well-known gaps that AI agents happily exploit:
- It is domain-coarse. “Allow this agent to reach this provider but not that one, for this role, for two hours” is not expressible in a blocklist.
- It lacks attribution. A blocked or allowed lookup tells you a domain was requested, not which process requested it. An approved CI job and an autonomous agent look identical.
- It is bypassable. DNS-over-HTTPS, hardcoded IPs, and alternate resolvers route around it. Agents and the libraries they use increasingly default to DoH.
- It misses local destinations. Traffic to
localhost, a container, or a mesh peer never involves your DNS at all.
DNS filtering is a useful blunt instrument. It is not an agent egress control.
Where API gateways fall short
Cloud API gateways are more sophisticated. They sit in the path of provider traffic, route it, and produce telemetry. For application traffic — your backend calling a model — they are excellent. For agent traffic on a workstation they share a structural limitation: they only see what is routed to them.
- If an agent calls a provider directly, the gateway is bypassed.
- If an agent points at a local OpenAI-compatible endpoint, the gateway sees nothing.
- If an agent reaches an internal API or local database, that is not provider traffic at all.
A gateway governs the slice of egress that flows through it. The agent’s most sensitive interactions frequently do not.
The missing layer: local enforcement and telemetry
What both approaches lack is presence on the workstation, where the agent actually runs. Effective AI egress control needs three things that only a local layer can provide:
Attribution. Tie an outbound call to a specific tool, agent, or identity. Without this, every policy decision is a guess. With it, “this agent reached this destination” becomes a fact you can act on.
Coverage of local and bypass paths. See and govern traffic that never reaches the network edge — local model endpoints, containers, internal services, DoH attempts.
Enforcement close to the process. Where supported, orchestrate the native host firewall (pf, WFP, nftables) to restrict destinations at the kernel, and route provider traffic through a managed proxy for control. This is enforcement the network edge cannot perform because it cannot see the process.
This is not a replacement for DNS and gateways. It is the missing layer that makes them effective. DNS and gateways handle breadth at the network; local enforcement handles depth and attribution at the endpoint. Together they form a defensible egress posture for AI agents. Either alone leaves a hole an autonomous tool will eventually find.
Honesty about “blocking”
It is tempting to promise that a tool will block all unauthorized egress. On a general-purpose developer workstation, no honest vendor can promise that. A privileged user can, in principle, work around endpoint software.
The defensible claim is layered:
- Detect unknown and unapproved destinations and surface them for review.
- Attribute outbound activity to a specific tool or identity.
- Restrict egress where the host firewall is orchestrated or traffic is proxied.
- Strengthen all of this by combining with OS, DNS, proxy, MDM, and network controls.
The point of egress control is not a magic wall. It is to make unapproved egress visible, attributable, and harder — and to make approved egress smooth — across layers that reinforce each other.
Where Cup’n’String fits
Cup’n’String provides the local layer. It routes provider traffic through a managed proxy for attribution and policy where configured, detects and surfaces unknown outbound destinations, and orchestrates native host firewalls — macOS pf, Windows WFP, Linux nftables — to restrict egress where supported. It applies outbound policy by user, agent, device, and destination, and records egress decisions as audit evidence.
It also coordinates with the network layer you already have: Cup’n’String can orchestrate Cloudflare Zero Trust, Zscaler ZIA, Palo Alto Panorama, and Tailscale, owning only its tagged rules. The result is breadth at the network and depth at the endpoint. See Block Unauthorized LLM Egress and the Cloudflare AI Gateway comparison.
Checklist
- Can you attribute outbound AI calls to a specific tool or identity?
- Can you detect unknown providers and destinations?
- Can you cover local and bypass paths, not just the network edge?
- Can you restrict egress at the host where supported?
- Can you coordinate endpoint policy with your existing DNS, gateway, and ZTNA?
- Can you audit egress decisions?
Breadth plus depth
DNS and API gateways give you breadth: broad, centralized controls that catch a lot. They cannot give you depth: attribution and enforcement at the process, coverage of local paths, presence where the agent lives. AI agent egress control requires both. Treating either as the whole answer is how organizations end up confidently monitoring the front door while agents quietly use the side entrance.