Skip to content

What is egress control for agent sandboxes?

Egress control, or egress filtering, limits which outside hosts a sandboxed AI agent can reach, usually through an allowlist that a proxy enforces.

Last updated , 8 min read

What is egress control for agent sandboxes?

Egress control for an agent sandbox is a limit on outgoing network traffic that lets the agent's commands reach only approved outside hosts. It is also called egress filtering. The approved hosts, e.g. the package registry, form an allowlist. A proxy or firewall outside the sandbox refuses connections to other hosts.

Egress is traffic that leaves a network, and ingress is traffic that enters it. The US National Institute of Standards and Technology (NIST) defines egress filtering in its firewall guidelines as filtering of outgoing network traffic. The same guidelines recommend blocking any traffic that the policy does not expressly permit, a practice called deny by default.

A coding agent runs code that nobody has read, e.g. a package's install script, and it reads text that other people wrote. Anthropic's engineering post on sandboxing says that allowing connections only to approved servers keeps an agent from "leaking sensitive information or downloading malware" after a prompt injection. Most coding tasks need a few outside hosts, so a common setting is a short allowlist, not a sandbox with no network. Some hosted background coding agents allow the network while a setup script installs dependencies, then block it while the agent works.

How does egress control work?

Egress control puts one checkpoint between the sandbox and the internet, usually a proxy on the host. A request moves through it in five steps:

  1. The sandbox has no direct route to the internet, so its commands must connect through the proxy.
  2. A command reads the proxy's address from the HTTPS_PROXY environment variable and asks it for a host, e.g. registry.npmjs.org.
  3. The proxy checks the hostname against the allowlist.
  4. The proxy connects to an allowed host and relays the encrypted traffic. It refuses other hosts, e.g. with an HTTP 403 error.
  5. The proxy logs the host and its decision for each request.
What an egress proxy checks Sandbox Agent's command no direct route out Egress proxy checks the host logs the decision Allowed host e.g. package registry Other hosts refused not checked by the proxy DNS resolver name lookups Name server data in the hostname
The proxy checks and logs each connection. When the sandbox can also query a Domain Name System (DNS) resolver, a lookup is a second way out that the proxy does not check.

A program that ignores HTTPS_PROXY connects directly, and the sandbox blocks it. Without decrypting HTTPS, the proxy reads only the hostname the client asks for, e.g. in an HTTP CONNECT request. Claude Code's sandbox checks only this hostname by default, per its sandboxing documentation. It starts with no allowed domains and asks for approval when a command needs one, or refuses under a strict allowlist.

Other designs vary the checkpoint:

  • Firewall rules. Host rules allow the addresses of approved names and drop other packets. They cover every protocol, but an address that a content delivery network shares opens each site behind it.
  • A proxy that decrypts HTTPS. This proxy can also check paths and methods, e.g. allow only GET. A tool that does not trust the proxy's certificate authority fails.
  • A credential proxy. A credential proxy adds keys to allowed requests, so the sandbox never holds them.

What is an example of an egress allowlist?

Here is an illustrative example. A developer at Acme Co. asks a coding agent to "Let customers edit their delivery address during checkout." The agent runs in a container whose only way out is a proxy with this allowlist:

registry.npmjs.org
github.com
api.model.example.com

The task runs in six steps:

  1. The container starts with HTTPS_PROXY=http://proxy:3128, and its firewall drops other outgoing traffic.
  2. The agent runs npm install, and the proxy allows each request to registry.npmjs.org.
  3. The agent runs git fetch on a remote written as git@github.com:acme/web-store.git. Secure Shell (SSH) does not use the proxy, so the firewall drops the connection and logs it.
  4. The agent changes the remote to https://github.com/acme/web-store.git, and the fetch goes through the proxy.
  5. The agent runs the command that downloads a browser for the end-to-end tests. The proxy refuses browsers.example.com, and the command exits with an error.
  6. The developer reads the proxy log, confirms that the host belongs to the test framework, and adds it to the allowlist.

An excerpt from the proxy log shows these decisions:

ALLOW  CONNECT api.model.example.com:443
ALLOW  CONNECT registry.npmjs.org:443
ALLOW  CONNECT github.com:443
DENY   CONNECT browsers.example.com:443

The SSH attempt is missing from this log, because it never reached the proxy. A team can also build the first allowlist from a run whose proxy logs requests without refusing them. This example is simplified. A real project would review the allowlist again when a dependency adds a download host.

What does egress control miss?

Egress control narrows the way out, one of the three parts of the lethal trifecta, the pattern by which prompt injection can steal data. The other two are access to private data and exposure to untrusted content. Simon Willison's post on the trifecta warns that a tool that can make an HTTP request "can be used to pass stolen information back to an attacker." An allowlist still leaves these gaps:

  • Uploads to allowed hosts. An allowed host can accept data as well as serve it, e.g. a code host that takes comments on public issues. Claude Code's documentation warns that allowing a broad domain, e.g. github.com, can create a path for data exfiltration. A proxy that decrypts HTTPS can allow only GET, which blocks most uploads, but a URL can still carry data in its query string.
  • Name lookups. Some setups let the sandbox query any DNS resolver directly, without the proxy. A command can then write data into a hostname under a domain that an attacker controls. The lookup carries that data to the attacker's name server, and the proxy never checks it. This is called DNS exfiltration. A resolver that refuses to look up names outside the allowlist stops those lookups when it is the only resolver the sandbox can reach.
  • Hidden destinations. A proxy that does not decrypt HTTPS trusts the hostname that the client asks for. The same documentation warns that code in the sandbox can then use domain fronting to reach hosts outside the allowlist. Domain fronting names an allowed host when the connection opens and a different host inside the encrypted request.
  • What comes back. An allowed registry serves any package it holds, including a harmful one. In slopsquatting, an attacker publishes a package under a name that models invent by mistake.
  • Processes outside the sandbox. The rules cover only what runs inside. In Claude Code, the sandbox covers shell commands, so its web fetch tool follows permission rules instead. A Model Context Protocol server that Claude Code starts on the host makes its own connections. With a built-in sandbox, the agent's requests to its model provider also start outside, and they carry the main part of what leaves your machine.
  • Addresses inside the network. Rules written for public hosts can leave internal addresses reachable, e.g. the metadata service that answers at 169.254.169.254 on an Amazon EC2 machine. That service can hand out the machine's credentials. Deny the private address ranges and 169.254.0.0/16 unless the task needs them.
  • A boundary that fails. After a sandbox escape, code runs on the host, where the proxy's rules do not apply.

How is egress control different from least privilege?

Least privilege is the principle that an agent gets only the access its task needs. Egress control applies that principle to one kind of access, outgoing network traffic. Least privilege also covers the agent's tools, files, and credentials, which an allowlist does not limit.

The two cover each other's gaps. A narrow allowlist does not stop a broad token from deleting a repository on an allowed code host. A narrow token does not stop the agent from sending a secret it read to any host the network allows. A sandbox for a coding agent usually needs both.

Neither one checks the code the agent writes. An injected instruction can add a backdoor that sends no data, a risk to AI-generated code security.

FAQs

What is DNS exfiltration?

DNS exfiltration sends data out in the hostname of a lookup under a domain that an attacker controls. When the sandbox can query a resolver directly, the lookup carries the data to the attacker's name server, and the proxy never checks it. A resolver that refuses to look up names outside the allowlist stops those lookups.

Should an agent sandbox block all network access?

An agent sandbox with no network access is the strictest setting, but most coding tasks need a few outside hosts, so a short allowlist is a common choice. Some hosted agents allow the network while a setup script installs dependencies and block it afterwards. Others keep the allowlist for the whole task.

How do you find which hosts an agent tried to reach?

The egress proxy's log lists each host that the agent's commands asked for, with the proxy's decision. A connection that skips the proxy, e.g. SSH, shows up in a firewall log instead, if the firewall keeps one. To build a first allowlist, you can run the task once with a proxy that logs requests without refusing them.

Why do some tools fail behind an egress proxy?

Some tools fail behind an egress proxy because they ignore the proxy variable or use another protocol, e.g. SSH, so the sandbox blocks their direct connections. Others need a host that is missing from the allowlist, or do not trust the certificate of a proxy that decrypts HTTPS.