Network egress control: if data can't leave, it can't be exfiltrated
When we assess an agent environment, the first thing we look for is the exit. Not the model, not the prompt. The exit. Because an agent can hold every secret you own and read every poisoned input on the internet, and none of it matters if the data has no way out.
That is what network egress control does. It decides, in advance, exactly where an agent is allowed to send data, and blocks everything else by default. This is the most direct way to disarm the third leg of the lethal trifecta, the exfiltration channel. Detection is not part of the design, because a language model cannot reliably detect a malicious instruction. Egress control removes the exit instead.
Egress is the leg worth attacking first
The lethal trifecta, Simon Willison's framework we break down in the main guide, names three capabilities that are dangerous only together: access to private data, exposure to untrusted content, and an exfiltration channel. The first two are hard to remove from a coding agent. Reading source code is the job. Reading external content is how the work gets done. The exfiltration channel is different. It is infrastructure, and infrastructure is controllable.
Close the exit and the composite risk collapses, even when the other two legs are fully present. This is the move that turns an open-ended worry about prompt injection into an engineering problem with a known control.
What egress control actually requires
A single firewall rule is not egress control. Four things have to be true.
- Default-deny for every agent environment. Outbound access starts closed. Nothing leaves unless a rule explicitly permits it. Allow-by-default with a blocklist is the inverse of what you want, because you cannot enumerate every destination an attacker might use.
- Allowlists scoped per agent and per task. An agent that installs packages needs the package registry, not the entire internet. Scope the allowlist to the endpoints the workflow actually requires, and scope it per task so a build agent and a review agent do not share one broad rule. The tighter the allowlist, the smaller the exfiltration surface.
- Explicit blocking of the cloud metadata endpoint. The link-local address 169.254.169.254 hands cloud instance credentials to anything that can reach it. An agent that can query it can give away host credentials in one request. This is one of the most common and highest-impact gaps we find. Block it.
- Network namespace isolation. Egress is not only about the internet. An agent that can reach other processes or agents on the same host has an internal exit, and lateral movement is exfiltration with extra steps. Namespace isolation closes the sideways paths that perimeter rules never see.
The tradeoff is real, and it is engineering
A locked-down agent loses open web access and arbitrary external API calls. That is the point, and it is also the cost. The work is not writing a deny rule. It is decomposing the agent's actual dependency graph, the specific registries, APIs, and services the workflow genuinely needs, and encoding that into an allowlist tight enough to be safe without breaking the workflow.
A memo that says "restrict network access" produces one of two things: an agent that cannot function, or an allowlist so broad it is decorative. Neither is a control. Mapping the real dependencies and writing per-task rules is what makes egress hold up in production. The industry has converged here. NVIDIA's red team, OWASP, and Microsoft treat egress control for agent environments as mandatory, not recommended.
You do not need a perfect model. You need a perfect cage, and the cage starts with the door.
Frequently asked questions
What is network egress control for AI agents? A control that restricts where an AI agent can send outbound data. Access starts default-deny, and only explicitly allowlisted destinations are reachable. It removes the exfiltration channel a prompt injection would otherwise use.
Why is blocking the cloud metadata endpoint important? The metadata endpoint at 169.254.169.254 serves cloud credentials to any process that can reach it. If an agent can query it, a single request can expose host credentials. Blocking it closes one of the most direct credential-theft paths.
Does egress control stop prompt injection? It does not stop the injection. It neutralizes the outcome. Even if a poisoned input tells the agent to collect and send data, default-deny egress gives the payload nowhere to go. It breaks the exfiltration leg of the trifecta.
What is the hardest part of implementing egress control? Writing an allowlist tight enough to be safe without breaking the workflow. That means decomposing the agent's real dependency graph and scoping rules per task, rather than applying one broad rule to every agent.
Where to start
Inventory what each agent reaches on the network today, then write a per-task allowlist for the endpoints it genuinely needs and default-deny the rest. Block the metadata endpoint first. It is fast and high-return.
Egress control is one of four disciplines that close the agent security gap, alongside sandboxing and execution isolation, architectural trust boundaries, and observability and composition. For the full framework and a maturity self-assessment, download The Agentic AI Security Maturity Guide.
