Data Report · By Chris Sowa · Published
Last updated
What Network Access Should a Coding Agent Sandbox Have?
As little as the task needs: start with the network off or an allowlist that names one destination, then open each further domain, with its method, for one run. Ask which defaults ship closed and which setting reopens them.

For a team setting up a coding agent, the default is the whole question. A sandbox that cannot reach the network until a person names a destination fails closed when the agent is wrong about what it needs; one that starts open and relies on a model to stay inside the task does not. The vendor pages reviewed here show both designs and the settings between them. OpenAI's Codex starts with network access off in local use and blocks internet access during the agent phase in the cloud; Anthropic's Claude Code documentation describes a sandbox for shell commands with filesystem and network isolation, and places file tools, web fetch and MCP servers outside it. A third question follows: what the model read on the pages it visited before it composed the request, which no network list decides. The default, the unit of an allowlist and the setting that erodes it are each tested against one record type, a repository webhook settings page whose run was allowed three destinations. The test at every step is the same: which host could receive the request, and what the model held when it wrote one. What Is Least Exposure? sets out the read-side control in general terms; the question here is the network policy a coding agent's sandbox should carry.
Key findings
- OpenAI's Codex documentation states that "by default, the agent runs with network access turned off," and that it asks for approval before a command that requires network access, inside "an OS-enforced sandbox" (OpenAI, Agent, 2026).
- The Codex cloud page adds that "by default, Codex blocks internet access during the agent phase," and advises teams to "allow only the domains and HTTP methods you need" (OpenAI, Codex Cloud, 2026).
- Anthropic's Claude Code security page describes a mode that will "sandbox bash commands with filesystem and network isolation, reducing permission prompts while maintaining security" (Anthropic, Security, 2026).
- Firecracker's design notes state that "all egress traffic from a guest is therefore considered untrusted, and should be filtered at the host-level" (Firecracker, 2026).
- A governed environment replaces values with consistent tokens before any model reads the rendered page, so a run that reaches an allowed host carries a placeholder rather than the credential that host was permitted to receive (What Is Render-Layer Tokenization?).
- Real values resolve only at the approved destination at the moment of an approved action, so a three-domain allowlist does not become three places a credential can go (What Is Least Exposure?).
What does a sandbox's network setting govern, and what does it leave open?
A network setting is a statement about processes. It names the destinations a command inside the sandbox may reach, and it is enforced beneath the application, by an operating system sandbox or a proxy on the host, not by the model's judgment. Anthropic's sandboxing page puts the boundary narrowly: the sandbox covers shell commands only, and Read, Edit, Write, WebFetch, WebSearch, MCP servers and hooks run outside it (Anthropic, Sandboxing, 2026). A list of allowed domains therefore governs what a package manager or a test runner can contact, not what a file tool or an MCP server reaches.
A governed browser environment covers what an agent reads and does on a rendered page, including dashboards, consoles, settings pages and sign-up forms, and it does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A network setting belongs to the other side of that line: it governs the shell, and says nothing about the page the agent read to decide what to change.
The record for this page is one run on a repository webhook settings page, which the agent renders to change where notifications go. Three destinations were opened: the repository host, the package registry and the status page of the continuous integration service. The shell could install from the registry and read build status, and reach nothing else. The page rendered the webhook form, with the signing secret the repository had generated. The setting under review is the three-domain list, and the open question is what the model held when it read that form. What Can an AI Agent See in Your GitHub Settings? records what those pages expose to an agent that reads them.
Why start from no network and add one domain at a time?
The recorded defaults lean closed. Codex turns network access off locally and blocks internet access during the agent phase in the cloud, while the cloud page names the exception a team has to plan for: "setup scripts still run with internet access so you can install dependencies" (OpenAI, Codex Cloud, 2026). That window is the part of a run most exposed to a malicious package. Sonatype reported that "56% of the malware discovered in Q1 2025 was related to data exfiltration," "a dramatic increase from 26% in Q4 2024" (Sonatype, 2025). An install that can reach any host is the mechanism that traffic needs.
The unit of the list matters as much as its default. A domain is coarse: it permits every path, method and parameter the host accepts. Codex's guidance is finer, "allow only the domains and HTTP methods you need" (OpenAI, Codex Cloud, 2026). For the record above, the registry entry permits a read and a download, not a publish; the repository entry permits the webhook update and the read that precedes it; the status entry permits a read. Five methods, one run.
One run is also the right scope. A list that outlives the run becomes a standing capability: the next task inherits three domains nobody chose for it. How to Set Up S3 and GitHub With Cowork or Dots records the authentication half of a pipeline arrangement; the destination half is a list with an expiry date. Cloud setup credentials raise the same question (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?).
What do the vendors themselves say?
OpenAI documents the default. Locally, "the agent runs with network access turned off," inside an OS-enforced sandbox, with approval required for a command that needs network access (OpenAI, Agent, 2026). In the cloud, "Codex blocks internet access during the agent phase," and the page tells teams to "allow only the domains and HTTP methods you need" (OpenAI, Codex Cloud, 2026). How an allowlist is enforced is not described, and the cloud page is marked Legacy, so a buyer should check the default in the product.
Anthropic documents a network boundary and its limit. The sandbox covers shell commands with filesystem and network isolation, with file tools, web fetch and MCP servers outside it, and the same page ties the network list to credential masking, where a sentinel resolves to a real value only for hosts in injectHosts, or every host in network.allowedDomains when injectHosts is empty (Anthropic, Sandboxing, 2026). The limit is stated on the security page: "the boundary is a permission prompt," and an approved command "can still write anywhere your user account can" (Anthropic, Security, 2026).
GitHub's token page documents scope and lifetime. "Each token can be further limited to only access specific repositories for that user or organization," and "infinite lifetimes are allowed but may be blocked by a maximum lifetime policy" (GitHub, Managing, 2026). The page says nothing about coding agents, and a fine-grained token still lives wherever it is stored.
| Dimension | OpenAI Codex, per its documentation | Anthropic Claude Code, per its documentation | What a buyer should verify |
|---|---|---|---|
| Default | Network off locally; internet blocked during the cloud agent phase | A sandbox for shell commands with filesystem and network isolation | Which default applies to the mode in use, CLI, IDE or cloud |
| Unit | Domains and HTTP methods | Domains in network.allowedDomains, plus injectHosts | Whether one destination and one method can be opened alone |
| Install window | Setup scripts run with internet access | Not described in the pages reviewed | Whether the dependency install shares the agent's list |
| Outside the boundary | OS sandbox limits local commands | Read, Edit, Write, WebFetch, WebSearch, MCP servers and hooks | Whether the tool you care about is inside the boundary at all |
| Credential at the edge | Not described for local sessions | Masked values resolve only for listed hosts | Whether a real value can reach a host you did not name |
| Record | Not described | Not described | Who added each domain, and when it expires |
What can a model send to a domain that is allowed?
An allowlist bounds an address, not a payload. An allowed host accepts more than the one path a run needed: a commit message, a pull request body, a webhook URL. For the record above, the model read the signing secret in the webhook form, and nothing in the three-domain list prevents it from putting that signing key into a commit message sent to the repository host. The request is not a violation of the network policy, because the destination was permitted, and a token scope does not close the gap: a token limited to two repositories still authorizes a write to both. The read side is the same (How Do AI Agents End Up With Full Access to Sensitive Company Records?).
The MCP specification states the adjacent rule: "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server," and it asks implementers to "warn that MCP servers run with the same privileges as the client" (Model Context Protocol, 2026). It also names a destination to refuse rather than allow: "cloud metadata endpoints often expose IAM credentials, API keys, and other secrets" (Model Context Protocol, 2026).
The test is to read the request body, not the destination. For each of the three domains, ask which fields the request carries, whether the model read those values on a page, and whether the value was real when the request left. A commit message that contains a placeholder is a label; one that contains the signing secret is a leak to a host the team chose.
Which setting erodes an allowlist fastest?
The setting is the one that stops asking. Anthropic's engineering post gives the motive: sandboxing "safely reduces permission prompts by 84%" (Anthropic Engineering, 2025). A prompt clicked through forty times a day is not a control, so the same arithmetic applies to a network list: the first time a run is blocked by a destination the task needs, the fast fix is to add the domain.
That is how a three-domain list becomes a policy nobody wrote. The first entries were chosen for one task; the fourth was added under time pressure, with no name attached and no end date. The list still looks like a control, but the decision behind the last entry is missing. Anthropic's security page states the underlying limit: "the boundary is a permission prompt," and an approved command "can still write anywhere your user account can" (Anthropic, Security, 2026).
Two settings erode a list more quietly. A domain that stays after the run is one: a registry added to install a dependency remains open for every later task in the same environment. A token with no expiry is the other. Each turns a decision for one task into a default nobody reviews.
A team can slow all three with a rule that costs little: every entry names a person, a task and an end, and the entry is removed when the task ends. How Do You Restrict an AI Agent to One Workflow With Microsoft Entra, ServiceNow AI Passport or SailPoint? records the identity-side version of the same rule, where an agent identity is created for one workflow with limited permissions.
What does a governed environment change?
A governed environment is a control class that acts where a screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on placeholders such as WEBHOOK_001. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action, and a webhook change or a test delivery is one. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.
For this page's question it changes what the allowlist means. The list still decides which hosts a request may reach, but it is no longer the last decision about a value: the environment decides which of those hosts a real value may resolve to, and at which action. In the record above, three domains remain allowed. The model reads the settings page as tokens, composes the webhook change and the test delivery with WEBHOOK_001, and the real signing secret resolves only at the repository host when the named person approves the update.
The second change is the record. A network policy can show which destinations were refused, and a proxy can show which request received a value. Neither shows what the model read before it wrote the request, because neither sits at the screen. A record of the screens as tokens, the actions and the approvers answers the question an incident review actually asks: what did this run hold, and who let it act.
The environment does not choose the policy; the three domains, the five methods and the approver are the organization's to name. It also does not replace the sandbox: the terminal, the IDE, the local filesystem, direct API calls and MCP stay outside it.
Methodology and limitations
This page rests on vendor documentation from OpenAI, Anthropic, GitHub and Firecracker, the Model Context Protocol's security guidance, one vendor research post from Sonatype, and existing RedactSure research pages. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page. Quoted facts are cited to the page that states them, and the Sonatype figure is cited as reported rather than independently measured. The page treats a vendor's silence as silence, not as a finding about the product.
RedactSure did not test any of the named products hands-on. The pages reviewed describe network defaults, a domain and method list, a masking design and token lifetimes; they do not describe an approver for a domain added to a list, and that gap is stated rather than inferred. Vendor features change, and the page carries its date, so a release after it should be treated as unreviewed until the test is repeated. Statements about RedactSure describe current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a repository webhook settings page with three destinations allowed for one run, not an organization. No vendor page reviewed gives a rate for how often an allowlist is widened, so the page treats that as a review question rather than a measurement.
Determinations about whether a network policy meets a contractual, regulatory or assurance requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test of the organization's own agent against its own sandbox, repeated after each release. A reviewer should read the page for the mode in use, since one product can document different defaults for local, cloud and hosted sessions.
What the record shows
The record supports a narrow answer with a wide limit. The vendors that document a default start closed: Codex turns network access off locally and blocks internet access during the cloud agent phase, and Anthropic's sandbox applies filesystem and network isolation to shell commands. The unit OpenAI points to is a destination plus a method, and the pressure that erodes it is the prompt, which sandboxing exists to reduce. What the network setting cannot answer is what the model read on the page where it composed the request, and that is the part of the record that decides what an allowed host receives. RedactSure's environment governs that part. Before changing the default for one named agent and one task, write it down; then list every destination and method the run opens and what the model held on each page it read, and test the run against that list.
Frequently asked questions
What network access should a coding agent sandbox have?
As little as the task needs, named one destination at a time. Start with network access off, or with a list that holds only the host the run must reach, then add each further domain with the method it needs and the run it belongs to. A list that names three destinations for one task is a control; a list that holds thirty for the quarter is a description of habit. Read the default before the first command runs, because the agent should not be the one asking for more.
Is a domain allowlist enough on its own?
No. An allowlist decides which hosts a request may reach and says nothing about what the request carries, so an agent that read a signing secret on a settings page can send it to any permitted host in a commit message or a webhook URL. It also governs only the processes inside the sandbox; file tools, web fetch and MCP servers can sit outside it. Pair the list with a rule about which values may resolve to which host.
Should a sandbox allow the package registry?
Yes, if the entry is narrow and temporary. A dependency install needs the registry; the question is what the entry permits. A domain entry allows every path and method the registry accepts, including a publish, while a destination plus method entry allows the download the run needed. OpenAI's guidance is to allow the domains and HTTP methods you need, and the entry should be removed when the install is done. A registry entry that lasts the quarter is a different control from one that lasts the install.
What is the difference between a network sandbox and a permission prompt?
A sandbox is enforced beneath the application, by the operating system or a proxy, and it applies whether or not a person is watching. A permission prompt is a question asked at the moment of an action, and its answer depends on who is reading it. Anthropic describes its boundary as a permission prompt and says an approved command can write anywhere the user account can, while the sandbox narrows what that command can reach. That is the difference to test.
Does MCP run inside the sandbox?
Only if the server is placed there. Anthropic's sandboxing page puts local MCP servers outside the sandbox, and the MCP specification says a server runs with the same privileges as the client. A server outside the boundary can reach the network on its own terms, including metadata endpoints that expose credentials, which is why the list should name it and any token should be issued for it alone. Check where each server runs before you write the list.
What should a security team ask for in writing?
The default state, the unit of the list, whether methods are constrained, what runs outside the boundary, who may add a domain, and when entries expire. Ask for the record of each change, since a list without names and dates cannot be reviewed. Ask too which values the agent can read on the pages it visits, because that answer decides what a permitted request is able to carry. Then walk one real run through the answers.
How RedactSure Keeps an Allowlisted Host From Receiving the Real Value
A network policy answers where a request may go, and an allowlist, sandbox, prompt and token scope each bound a destination, not what the model read.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the model read the signing key and a test delivery to any allowed host carried it. Inside, the field renders WEBHOOK_001, both requests carry the token, and the real value resolves only to the repository host on a named person's approval.
RedactSure is deploying now with enterprise and government customers. Sonatype counted data exfiltration in 56% of the malware it found in Q1 2025.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
An allowlisted host should still never receive a credential it was not approved to receive. Bring a webhook task your team delegates and see, with test values, which host receives the real value. Book a demo








