To set default deny egress for a coding agent sandbox, block all outbound traffic first, then allow only the package registries, source host, and internal services a task needs, by domain where possible. Test a real task, read the blocked requests, and add entries one at a time with a named owner.
Why start closed
Hosted platforms document the same risk. One lists prompt injection from untrusted web content or dependency READMEs, code or secret exfiltration, malware or vulnerable dependencies, and license-restricted content as reasons to limit internet access. Another says its firewall reduces the chance that code or sensitive information is sent to remote locations because of unexpected behavior or malicious instructions. Those risks are about where the agent can send data, so egress is the lever.
Steps
- Block everything outbound. Use the platform's "none" setting, or a deny rule at your network edge for self-hosted sandboxes.
- Run a representative task. Pick a build that installs dependencies and runs tests.
- Read the failures. One documented firewall adds a warning to the pull request showing the blocked address and the command that made the request. That is a ready-made worklist.
- Allow the minimum. Add your package registries and source host. A common starting preset on one platform covers package, source control, and build domains.
- Limit methods if you can. One vendor recommends restricting requests to GET, HEAD, and OPTIONS, which blocks POST, PUT, PATCH, and DELETE.
- Record the owner and reason for each allowed host, and review quarterly.
- Separate install from agent time. If setup needs wider access than the agent does, narrow the network once setup ends. See the related post on setup phase and agent phase.
Domain list or preset?
| Option | Good for | Watch for |
|---|---|---|
| None | Agents that only edit and test offline code | Builds that need packages will fail |
| Preset of common dependency hosts | Fast start | Wider than you need, and includes hosts you never use |
| Custom domain list | Tight control | Needs upkeep as tools change hosts |
| Unrestricted | Rare, justified cases | Largest exfiltration surface |
Self-hosted sandboxes
On Kubernetes, pods are non-isolated by default for ingress and egress. A pod becomes isolated for egress only when a NetworkPolicy selects it and lists Egress in policyTypes. The policy has no effect unless your network plugin enforces it. A policy that denies egress also blocks DNS lookups, so add an explicit rule for your cluster DNS. For one self-hosted runner design, the vendor advises restricting network access so the agent has no open access to your network or the public internet.
Worked example: building the allowlist for one repository
This is an illustrative walk through, with made up host names, for a service written in a popular language with a private package feed.
Round 1: deny everything. The first test task fails at dependency install. The block log shows three destinations: the public package registry, the registry's file host, and your private feed.
Round 2: allow the install hosts. You add those three. The install passes. The agent then fails to run an integration test because it tries to call a third-party test API.
Round 3: decide, do not just allow. You ask whether the test needs the real API. The team replaces it with a local mock. The destination stays blocked. This step is the point of default deny: each block forces a decision about whether the destination is needed.
Round 4: lock the list. The final allowlist has three entries, each with an owner and a reason. Anything new that appears in block logs later goes through the same decision.
Compare that with starting from a broad preset: you would have allowed dozens of hosts on day one and never learned which ones the work really used.
A policy table you can adapt
| Destination type | Default | Notes |
|---|---|---|
| Package registries you use | Allow, read only | Pin versions, use lockfiles |
| Source host | Allow via a proxy that scopes credentials | Limit to the task repository |
| Internal services | Deny unless the task needs them | Use test instances |
| Third party SaaS APIs | Deny | Use mocks |
| General web | Deny | Prompt injection often arrives this way |
| Model service | Allow, as required by the platform | Ask what the channel carries |
| Paste sites, file sharing, anonymous hosting | Deny | Common exfiltration targets |
Monitoring blocked requests
A block is information. Review blocked requests weekly at first.
- Group blocks by destination and by task.
- Mark each as expected (a real need), harmless, or suspicious.
- Add expected ones to the allowlist with an owner.
- Investigate suspicious ones: what command made the request, and what content preceded it?
- Alert when a single session produces many blocks, or when a new destination appears.
One documented firewall shows the blocked address and the originating command in the pull request itself, which makes this review part of normal code review.
Common mistakes
- Allowing a whole cloud provider domain because one bucket is needed. Allow the narrowest name you can.
- Forgetting DNS. On self-hosted setups a deny rule also blocks name lookups, so allow your resolver.
- Letting exceptions live forever. Review the list quarterly.
- Treating the allowlist as the only control. It narrows exposure, and the next layers are scoped tokens and review.
- Different rules per team with no owner. Pick a single owner for the baseline.
Where Safeguard fits
Safeguard does not enforce your network egress. It does cover the dependencies those allowed registries deliver, through dependency scanning and policy gates, and you can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through it and notice how a tool is connected and what it is allowed to reach, since each connected tool adds a destination to your egress picture.
Quick check
Is a domain allowlist enough to stop data exfiltration?
No. An allowed host can still receive data. See the related post on what an allowlist does not stop.
Will default deny break builds?
At first, yes. That is the point. Failures show you which hosts a build really needs.
How long does it take to tune a default deny policy?
For one repository with a clear build, a few test runs are often enough to find the hosts a build needs. Expect more rounds for monorepos and integration heavy projects, and keep reviewing block logs afterward.
Sources
- Codex cloud internet access (OpenAI documentation)
- Customize the Copilot cloud agent firewall (GitHub Docs)
- Customize the Copilot cloud agent environment (GitHub Docs)
- Kubernetes network policies
Last reviewed: 19 October 2026.
