What Is an Egress Allowlist in a Software Factory?

A software factory runs agents inside sandboxed stations. Those stations produce artifacts. But what keeps a compromised or prompt-injected agent from phoning home with your source code or customer data? The answer is an egress allowlist: a network rule that blocks every outbound connection except a handful of explicitly approved destinations. By default, nothing leaves the station. Only what's on the list gets through.

The Default-Deny Rule

An egress allowlist operates on a simple principle: deny all, then permit by exception. The station starts with zero outbound network access. No DNS lookups. No HTTP calls. No database connections. Nothing. Every outbound packet is dropped at the network boundary unless it matches an entry on the allowlist.

This is the opposite of a blocklist approach, where you allow everything and block specific bad destinations. Default-deny is stronger because you do not need to anticipate every possible malicious destination. You only need to enumerate the legitimate ones. If a destination is not on the list, it cannot be reached, regardless of how the agent was instructed to contact it.

The egress allowlist is part of the factory's security model, which addresses discussion problem 5: agent-specific security holes. Without this control, every agent process has an implicit network path to the internet, and every prompt injection becomes a potential data exfiltration channel.

What Stations Can and Cannot Reach

A station produces artifacts. It never opens its own network path to the world. That rule is architectural, not just operational. The station interacts with the factory through the control plane, which passes artifacts in and out via the artifact store. The station does not call external APIs, push to repositories, or send data to analytics endpoints directly.

What the station can reach is determined by the allowlist entries for its specific task type. A build station might be able to reach a package registry. An eval station might connect to a model inference endpoint. A deployment station might talk to a container registry. Each of these destinations is explicitly configured, not discovered at runtime. If a station needs a new destination, the change goes through the same governance and policy process as any other factory configuration.

The allowlist is applied at the sandbox level. The factory's execution adapter (ports/execution.py) enforces it by running each station inside a container or microVM with a locked-down network policy. The current reference implementation runs stations against the working tree directly with no containment; both the ClaudeCLIBuildStation and SubprocessHarnessStation docstrings note this is temporary and that production deployments require the containerized model with egress controls.

Why This Matters for Agent Safety

Prompt injection is not theoretical. An LLM-based agent can be instructed by malicious content in a file it reads, a comment in a code review, or a response from an API it calls. Once injected, the agent follows the attacker's instructions, not the factory's. Without an egress allowlist, that agent can exfiltrate data by making an HTTP request to any server on the internet. With an egress allowlist, the injection succeeds but the exfiltration fails. The agent tries to call out and the network drops the packet.

This is the same principle that makes sandboxing work: you contain the blast radius. A compromised station cannot reach your production database, your CI/CD runners, or your source control. It can only produce artifacts that the factory validates before they go anywhere. The tier max-rule governs what those artifacts are allowed to do, but the egress allowlist governs what the agent itself can do at the network level.

Egress in Practice

Configuring an egress allowlist means making explicit choices about which external services the factory depends on. The list is short by design. A typical factory allowlist might include:

• A model inference endpoint for eval stations that score outputs.
• A package registry (PyPI, npm) for build stations that install dependencies.
• A container registry for stations that build and push images.
• A telemetry endpoint for operational metrics (if the station emits them directly).

Everything else is blocked. That includes public code repositories (GitHub, GitLab), cloud provider APIs, analytics services, and any destination not explicitly required for the station's job. If a station needs to push code, it does so by writing an artifact that the control plane then delivers through the appropriate adapter. The station never holds credentials for those external systems.

This design creates a clean separation: stations produce evidence. The factory decides what to do with it. The egress allowlist enforces that boundary at the network layer, making it impossible for a station to bypass the factory's decision process.

The Relationship to Sandboxing

An egress allowlist and sandboxing are complementary controls. Sandboxing restricts what the agent process can do inside the container: filesystem access, process creation, system calls. The egress allowlist restricts what the container can reach outside the container. Both are needed.

Sandboxing without egress control means a compromised agent can still call home. Egress control without sandboxing means a compromised agent can still read sensitive files on the host. The factory uses both, applied at the station level through the containerized execution model tracked as DECISION[D-024]. The sandbox provides the internal boundary. The egress allowlist provides the external boundary.

Together, they implement the factory's core security rule: a station may produce artifacts but never open its own network path to the world. The station does what it is told, the control plane decides what happens next, and the allowlist ensures the station has no back channel.