Egress allowlist: hosts coding agents can reach

The idea

An agent that runs commands on repository content can be steered by that content, for example by a prompt injection hidden in a README. Limiting where the agent can connect limits what such an attack can send out. An egress allowlist names the destinations that are reachable and refuses the rest.

How DevFlow enforces it

DevFlow runs an allowlisting CONNECT proxy inside its API process. In container mode, every agent container sits on an internal Docker network whose only way out is that proxy. Each run gets its own credential, a token that is revoked when the run ends and expires after 3 hours in any case.

For every connection, the proxy checks the host name against the policy and resolves it. The connection is refused if any resolved address is non-public: loopback, private ranges, link-local addresses including the cloud metadata address 169.254.169.254, or carrier-grade NAT. The proxy then dials the exact address it checked, so a second DNS answer cannot swap in a different one.

Policy by role

Roles that write code get the default list plus the workspace's own extra hosts. They are the implementer, fixer, verifier, build doctor, scanner, conflict resolver and the two discovery roles that look for build commands and screenshot targets.

When an owner locks agent internet access, every role is held to the default list and the workspace's extra hosts. If the proxy cannot read the workspace settings, it falls back to the locked policy with the default hosts only.

The default list

The default list covers package registries and source hosts:

• npm, Yarn, PyPI, the Go module proxy, crates.io, Maven Central, Gradle, NuGet, Packagist and pub.dev;
• GitHub, its archive download service and its user-content domains;
• the model catalog of OpenCode and the Figma API.

A pattern starting with *. matches strict subdomains only, so *.figma.com does not match figma.com itself. Owners add their own hosts in Workspace Settings → Execution → Agent internet access.

A worked example

Suppose an implementer run installs a package from a private registry at npm.example.com. Until that name is on the workspace's own list, the proxy refuses the tunnel with a 403 response that names the reason, and the install fails. Once an owner adds the host, the same run succeeds, while an attempt to reach any other host is still refused.

Keys stay with the relay

With the model relay on, which container mode forces, model calls go through a separate relay in the same API process. The agent sends its run token; the relay swaps it for the workspace's provider key, forwards the request, and answers 402 once the workspace's spend cap is reached.