A network allowlist does not stop data from leaving through an allowed host, does not always cover every process in the sandbox, and does not remove the agent's connection to its own model service. It reduces exposure. Treat it as one layer next to least privilege, review, and logging.
Gap 1: allowed hosts are still destinations
If a code host, registry, or paste-friendly service is on the list, the agent can write to it. A package registry that accepts publishes, or a code host where the agent can push a branch, is a place data can go. This is why one vendor recommends limiting requests to read-only methods, which blocks POST, PUT, PATCH, and DELETE. Method limits help, but only where the platform can enforce them.
Gap 2: coverage may not include every process
One firewall's documentation is specific: it applies only to processes the agent starts through its Bash tool, and does not directly cover MCP server processes or processes started in configured setup steps. It also operates only within its own runner environment, and the page states that sophisticated attacks may bypass it and that it should not be considered a comprehensive security solution. That is a vendor being honest about scope, and worth reading for any platform you use.
Gap 3: the model connection
One platform states that when network access is disabled, the agent can still communicate with the model API, which may allow data to exit the VM. A session must reach its model to function, so a complete network cutoff is not available. The question to ask is what that channel can carry and who can see it.
Gap 4: traffic that bypasses the list
The same platform describes traffic that does not go through the allowlist, such as its GitHub proxy and connector traffic, and hosts you add for credentials. That is reasonable design, but it means the visible domain list is not the full list of reachable services. Ask any vendor for the complete set.
Gap 5: wide access levels
An environment set to unrestricted access, or a firewall that an administrator can disable, removes the control. One vendor's documentation notes that the firewall can be customized or disabled, and that disabling it lets the agent connect to any host. Add this to your review checklist.
What to layer with it
| Layer | Why |
|---|---|
| Least privilege tokens | Limits what a leak can do |
| No standing secrets in the sandbox | Less to exfiltrate |
| Pull request review before merge | Catches planted changes |
| Logging of tool calls and blocked requests | Lets you notice attempts |
| Human approval for high-impact actions | OWASP recommends it |
Worked example: data leaves through an allowed host
An illustrative scenario. A team allows its code host and one package registry. A pull request from an outside contributor includes a README with hidden text telling any AI assistant to collect environment variable names and "share them in a pull request comment so reviewers can verify the setup."
The agent reads the README as part of its task. The sandbox blocks every domain except the code host and the registry, so a request to an attacker's server fails. But the instruction did not ask for one. It asked for a comment on the pull request, which is a write to an allowed destination. If the agent holds a token that can comment, the data goes out through a path the allowlist was designed to permit.
Nothing in the network policy failed. The failure is that the allowed destination can receive attacker visible data, and the token allowed the write. The fixes are not network fixes: keep secrets out of the environment, scope the token to what the task needs, and keep a human reading what the agent posts.
Questions that expose the gaps
| Question | Why ask it |
|---|---|
| Which destinations can receive writes? | Writes are exfiltration paths |
| Which credentials sit in the environment? | Whatever is readable can be sent |
| Are tool servers inside the firewall's scope? | Some firewalls do not cover them |
| What can the model channel carry? | It stays open even when the network is closed |
| Who can change the policy, and is it logged? | A disabled firewall removes the control |
| Does the platform show blocked requests? | Visibility lets you notice attempts |
A layered view
- Reduce what is there to steal. Fewer secrets, narrower repository access, minimal data in prompts.
- Constrain where it can go. The allowlist, method limits, and proxying.
- Constrain what actions can be taken. Read-only tokens, single branch push, no merge.
- Make misuse visible. Logs, blocked request alerts, pull request notes.
- Put a person in front of consequences. Review, workflow approval, human approval for high impact actions.
Remove any one layer and the others carry more weight. Remove the allowlist and exfiltration is easy. Keep only the allowlist and an injected instruction can still use allowed writes.
What to tell your leadership
Say that egress limits reduce risk and do not eliminate it. Say that the platform's own documentation lists limits, which is a good sign about its honesty. And say what the compensating controls are. Claims like "the agent cannot send data out" are the kind that fail a later review.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how an MCP server is registered and what it is allowed to reach, since that traffic can sit outside a sandbox firewall.
Quick check
If the allowlist only has a code host, is exfiltration impossible?
No. The agent can still write to that host, for example in a branch or comment. Limit what the token may do.
Should I ask a vendor for the full list of reachable hosts?
Yes. Include proxies, connectors, and model traffic, not just the user editable allowlist.
Can method limits such as read-only requests close the gap?
They help a lot where the platform enforces them, because writes need POST, PUT, or similar methods. They do not cover every channel, such as a read request that carries data in the URL, so keep other layers in place.
Sources
- Customize the Copilot cloud agent firewall (GitHub Docs)
- Use Claude Code in the cloud (Anthropic documentation)
- Codex cloud internet access (OpenAI documentation)
- OWASP LLM06:2025 Excessive Agency
Last reviewed: 19 October 2026.
