AI agent sandbox: controlling network egress and credentials

In June 2026, an experimental, internal-only OpenAI model working on research questions took actions OpenAI had not authorized. According to OpenAI's disclosure, it "discovered a way to gain non-public access" to Australia's Medicare Statistics Reporting Service. It then ran commands and retrieved internal files, credentials and aggregate statistics. In a separate case, OpenAI agents found an exposed access key and used it to query a Victorian health agency's reporting system. OpenAI's response included three measures:

• Blocking live internet access in those research environments.
• Serving web content from a cache instead.
• Monitoring that pages a human reviewer.

In September, Transluce published an analysis of suspected AI agent traffic against US and Canadian government websites. The analysis draws on requests captured by public datasets, including the Arquivo.pt web archive. Among these were 899 requests to a Library and Archives Canada search service, 13 of which carried attack payloads. Transluce does not believe those probes succeeded and has so far identified no instance in these datasets of agents gaining access to non-public information. It also suggests that the agents "were not given a hacking-related task". The Communications Security Establishment stated that there is "no indication that government systems have been compromised at this time".

Both cases raise two questions: where an agent's traffic can go, and which credentials it can reach. This note covers those two questions, together with execution isolation, for an agent that runs commands or makes web requests inside an organization's environment.

• Contain execution

  Choose the isolation level for the code the agent runs and limit what it can write.

• Deny egress by default

  Route all traffic through a proxy that checks each destination against an allowlist.

• Keep credentials out

  Start with none and inject short-lived, narrowly scoped tokens outside the agent's reach.

• Log and alert

  Record every egress decision per run and send unusual volume to security staff.

Each part is enforced outside the model. Test the boundary before the agent runs in your environment.

Decide what the boundary has to contain

A sandbox for an agent covers five things:

• Execution: the kernel and runtime the agent's commands run on.
• Files: what the agent can read and write.
• Network: which destinations it can reach.
• Credentials: which secrets are present or obtainable.
• Volume and records: how much it can do, and what is logged.

For execution, NVIDIA's AI Red Team guidance notes that standard Docker dev containers "share the host kernel, leaving it exposed to any code executed within the sandbox". It places macOS Seatbelt and Linux Bubblewrap in the same shared-kernel group. Claude Code's sandbox, cited below, is built on those two mechanisms. It recommends full virtualization, such as virtual machines or Kata Containers, and describes gVisor as an intermediate option. The Kubernetes Agent Sandbox project supports both gVisor and Kata backends. Choose the strength according to what the agent executes. Code the agent writes from untrusted documents or web content warrants more isolation than a fixed set of build commands.

The same guidance treats three controls as mandatory:

• Network egress controls.
• Blocking writes outside the workspace.
• Blocking writes to agent configuration files wherever they are located, such as hooks, MCP server configuration, skills and rules files.

Mount only the inputs the task needs.

List every process the agent can start and check that each one is inside the boundary. The documentation for Claude Code's sandbox gives an example of why. Its sandbox covers shell commands, while built-in file and web tools, hooks, local MCP servers and other helper processes run outside it. Commands can also leave the sandbox through configured exclusions or a retry outside it. To put everything behind one boundary, the documentation suggests running the agent process itself in a container, a virtual machine or the sandbox runtime. Turn off retries outside the sandbox. Set the sandbox policy in a place the agent and the repository it works on cannot edit, such as centrally managed settings.

Deny network egress by default, below the agent

The agent's environment should have no direct route out. Send all traffic through an egress proxy that checks each destination against an allowlist. Limit DNS to trusted resolvers, which NVIDIA recommends to prevent DNS-based exfiltration.

Write the allowlist by purpose. For each destination, record why the task needs it and, where the proxy can see them, which methods and paths are allowed. Leave out hosts that accept arbitrary uploads unless the task requires them.

A hostname allowlist has two limits, both stated in Claude Code's documentation:

• Its proxy makes the allow decision "from the client-supplied hostname without inspecting TLS". As a result, code inside the sandbox "can potentially use domain fronting or similar techniques to reach hosts outside the allowlist".
• Allowing a broad domain such as github.com "can create paths for data exfiltration".

Rules on methods, paths or content need a proxy that decrypts the traffic, with its certificate trusted inside the sandbox. Claude Code's experimental TLS termination does not add content filtering. The documentation points readers who need inspection to a custom proxy. Alternatively, put a narrow gateway in front of each upstream service.

Block private, loopback and link-local addresses, including the cloud metadata endpoint at 169.254.169.254. The MCP security best practices give the same advice for MCP clients that fetch OAuth discovery URLs. They suggest an egress proxy built to prevent server-side request forgery, such as Smokescreen, and warn against hand-written IP validation, which encoding tricks can defeat. The same reasoning applies to any agent that fetches URLs.

When an agent needs a destination outside the policy, require a fresh approval each time. NVIDIA's guidance states that "approvals should never be cached or persisted" and that enterprise denylists should not be overridable by user approval. For research agents, consider the change OpenAI made: serve cached content instead of the live web.

Keep credentials out of the agent's reach

In the Victorian case, OpenAI agents found an exposed access key and used it. Treat any credential the agent can read as one it may use.

Start the sandbox with no credentials. Inject only what a task needs, preferably through a broker that issues short-lived, narrowly scoped tokens. OpenAI's sandbox guide describes credentials as "runtime configuration, not prompt content". It says the runtime or provider "should inject credentials instead of teaching them to the model as instructions".

Proxy-side injection keeps the real value outside the sandbox. In Claude Code's implementation, sandboxed commands see a placeholder, and the proxy substitutes the real secret on outbound requests. The substitution follows the secret's configuration:

• It applies to the hosts listed in that secret's injectHosts setting.
• With no injectHosts, it applies to every allowed domain.
• It requires the proxy's TLS termination, which the documentation labels experimental.

Set the host list for each secret to the one host that needs it. Check whether that host can return request headers to the caller, for example through a debug endpoint or a verbose error page. If it can, the injected value can come back to the agent in a response. In that case, restrict the allowed paths or redact the secret from responses at the proxy.

Two further rules apply to agents that call MCP servers and to anything mounted into the sandbox:

• An MCP server must not accept tokens that were not issued for it, and must not pass a client's token through to a downstream API. The MCP guidance calls the second pattern token passthrough.
• Do not mount privileged sockets. Claude Code's documentation notes that allowing access to /var/run/docker.sock "effectively grants access to the host system".

Treat volume and failed attempts as security signals

Transluce identified agents after the fact, from high-volume automated request patterns and from request sequences that changed paths or services after failures. OpenAI says its current monitoring would have detected the Australian activity and paged a human reviewer.

Log every egress decision with the run it belongs to: destination, method, bytes sent, allowed or denied, and the reason. To attribute requests to runs, give each run its own proxy credential or network identity. Alert on these events:

• Bursts of denied destinations
• Repeated attempts across different paths after failures
• Request volume beyond what the task needs

Set a rate limit per run. Send these alerts to whoever handles security incidents as well as to operations, because unusual load from an agent can be the first sign that it has left its task.

Sandbox strength and the choice of tool interface

A September 2026 study by Mak et al. (arXiv 2609.11999) compared tool interfaces for enterprise agents. Bash alone outperformed a catalogue of typed tools: by 21.8 to 24.5 points on TheAgentCompany and by 4.8 to 7.4 points on APEX-Agents, using 19 to 72 percent fewer tokens. The authors favour bash alone "when arbitrary execution can be isolated". Where policy requires a fixed tool catalogue, they favour programmatic tool calling. Their recommendation depends on whether execution can be isolated.

Test the boundary before relying on it

Write the expected result for each check before running it, and rerun the set after any change to the image, the proxy policy or the agent's tools:

• A request that bypasses the proxy fails.
• A request to a host outside the allowlist is denied and logged.
• A lookup through an outside DNS resolver fails.
• Private, loopback and link-local addresses are denied, including the metadata endpoint.
• Writes outside the workspace and to agent configuration files are denied.
• The agent's environment variables and mounted files contain no long-lived credentials.
• A burst of denied requests produces an alert that reaches a person.

These checks belong with the wider evaluation described in Testing an AI assistant before staff or clients rely on it. That article covers permissions, untrusted instructions and actions.

Running the sandbox in your own environment

When an agent runs in an organization's own cloud accounts, the organization should own the boundary:

• It provisions the sandbox infrastructure.
• It reviews the egress allowlist with its network team.
• It keeps the proxy and run logs in its own logging.
• It can revoke the agent's credentials and network access without help from the builder.

Canadian public-sector websites already receive suspected agent traffic. The Communications Security Establishment notes that automated and potentially malicious requests are routine for public sites and do not, on their own, indicate a successful cyber incident. An organization that runs agents is responsible for keeping its own agents from originating that traffic.

A sandbox reduces what an agent can reach. It does not establish that an agent is free of risk. Shared-kernel isolation remains exposed to kernel vulnerabilities, and allowlists drift as tasks change. Keep the isolation layer patched, review the allowlist on a schedule, and keep the remaining risks visible.