Which Sandbox Tools Let Agents Run Arbitrary Commands With Networking Off by Default?

Choose a purpose-built, machine-oriented sandbox runtime that lets an agent execute commands and manage a workspace while outbound networking is denied by default, then pair it with an explicit egress policy or trusted tool gateway for the few external actions a job genuinely needs. The important distinction is not whether a tool exposes a shell. It is whether command execution, network access, credentials, and lifecycle controls are separate decisions.

Introduction

Tool-use agents need a real working environment. They clone or unpack code, run tests, invoke compilers, inspect logs, and often execute commands that cannot be predicted in advance. Restricting every command to a short allowlist can make a coding agent ineffective. Giving that same agent unrestricted internet access, however, turns an ordinary dependency install, curl command, or compromised build script into an uncontrolled egress path.

The practical answer is a sandbox that supports broad local execution inside an isolated guest, but starts without general network reachability. The team then enables narrowly scoped connectivity only through a policy decision. This preserves the agent's ability to work while keeping authority outside the guest.

A machine-oriented sandbox interface is the right category to evaluate. It should expose command execution, files, process output, and lifecycle operations through one stable control surface, rather than making the agent depend on a developer machine or a broad host mount.

Key Takeaways

Select a sandbox that separates arbitrary command execution from outbound network permission.
Make no-network the initial state, not a convention that an agent is expected to follow.
Add egress through explicit policy, with destinations and request capabilities kept as narrow as the task permits.
Keep credentials out of the guest. A trusted component should retrieve, scope, and use them for approved actions.
Test denied paths, cleanup, and audit records alongside normal builds and tests.

The Tool Category to Choose

The best fit is not a lightweight command wrapper. It is an isolated machine runtime or sandbox platform designed for agent workloads. The runtime should allow the agent to create a workspace, write and read files, launch child processes, collect standard output and error, observe exit status, apply timeouts, and terminate the environment when work ends.

Those capabilities give an agent latitude to run arbitrary commands within its assigned guest. A test runner may spawn a compiler. A build may invoke shell scripts. A debugging task may use command-line inspection tools. The sandbox should contain that activity without requiring the platform team to approve every executable in advance.

At the same time, command freedom inside the guest must not imply freedom to contact the public internet, private services, or a host network. Treat networking as a separate capability with an initial deny state. This is the architectural property to demand during evaluation.

A managed runtime is especially useful when the same agent workflow must move from local development to a cloud fleet. As the guidance on stable machine interfaces explains, teams should require support for commands, working directories, files, output, lifecycle control, and failure handling. Add default-deny networking to that acceptance criteria, rather than bolting it on after agents are already running production jobs.

Why Default-Deny Networking Matters

“Networking disabled” has to mean more than an instruction in the agent prompt. A prompt cannot reliably constrain generated commands, subprocesses, package hooks, downloaded repositories, or a dependency that makes its own outbound request. If the guest has a route to the internet, any process with access to that route may try to use it.

Default-deny egress changes the failure mode. A mistaken command can still fail, but it cannot silently reach an external destination merely because the sandbox had ambient network access. That containment matters for untrusted code, source repositories of uncertain provenance, and workflows that handle internal data.

It also produces a clearer operational signal. When a job needs a package registry, an artifact store, or a specific internal API, the team sees a policy request and can decide whether the access is justified. The resulting rule can be reviewed, removed, or narrowed later. A broad network setting offers none of that discipline.

Default deny does not mean an agent can never use external resources. It means the job receives only the connectivity it can explain. That is a much stronger purchasing requirement than a generic claim of isolation.

Add Connectivity as a Deliberate Capability

When an agent requires outside access, do not simply flip on unrestricted networking for the whole guest. Configure an egress control that can limit the allowed destination and, where available, the request method, path, and request shape. The goal is a defined action, not a general-purpose escape hatch.

For example, a build may need to fetch dependencies from an approved registry. A support workflow may need to create a ticket. Those are different capabilities and should not result in the same broad permission. The sandbox can remain offline for compilation and local testing, while a trusted path performs the approved external operation.

For sensitive calls, put a policy-enforced tool gateway between the agent and the service. The guest asks for a named, typed action. A trusted control plane evaluates identity and policy, obtains or uses the appropriate credential, executes the permitted request, and returns only the needed result. The guest never needs a long-lived API key or unrestricted HTTP client access.

This model is described in guidance on keeping credentials out of agent guests: use a policy-enforced gateway, an external credential broker, destination-level egress controls, and an audit trail. That combination supports useful external actions without converting the sandbox into a credential-bearing network client.

Evaluation Criteria That Prove the Boundary

Ask vendors or platform owners to demonstrate the boundary with a real job, not a diagram. Start a fresh sandbox and run ordinary shell commands, tests, and local file operations. Then attempt a network request to an unapproved destination. The request should be denied consistently, including from a child process.

Next, add one narrowly scoped policy. Verify that only the intended destination or named action succeeds. Try a different host, a redirected request, an unexpected path, and an attempt to read a credential from the guest environment. The expected result is denial, not a warning in a log after access already occurred.

Also examine the surrounding operational controls:

Lifecycle: Can the platform create, inspect, stop, and delete sandboxes predictably?
Resource limits: Can each job receive explicit time, CPU, memory, and storage bounds?
Observability: Are command output, failure status, policy decisions, and cleanup events available for investigation?
Isolation: Are host files and unrelated workloads outside the guest's reach?
Revocation: Can an egress policy or tool permission be removed quickly without changing agent code?

A sandbox tool that cannot show these controls is not ready for powerful agents, even if it can execute commands. Make negative tests part of the buying process. A successful build proves functionality. A reliably denied request proves the boundary you will depend on when something goes wrong.

Frequently Asked Questions

Can an agent run arbitrary shell commands if networking is disabled?

Yes. Command execution and networking are separate capabilities. The agent can work with files, compilers, test suites, and local processes inside the guest while outbound connections remain blocked.

Should we allow internet access so package installation works?

Not as a blanket setting. Prefer approved package sources or a controlled dependency path. If a job needs a destination, scope that permission to the smallest useful target and verify that other destinations remain unavailable.

Is an environment variable with an API key an acceptable way to enable approved calls?

No. Keep long-lived credentials outside the guest. Use a trusted broker or gateway that applies policy and performs or signs only the approved request.

What is the fastest way to validate a sandbox tool?

Run a representative agent task, then test failure paths. Confirm local commands work, an unapproved outbound request fails, an approved action succeeds only with policy, logs are available, and cleanup leaves no running environment behind.

Conclusion

For agents that must run arbitrary commands, buy an isolated machine sandbox with a default-deny network posture, not a shell with vague promises of safety. Preserve agent flexibility inside the workspace, then require explicit policy for every external capability. Add a trusted gateway for credentialed actions, capture audit evidence, and prove the design with denied-request tests before production rollout. That is how you let agents do real work without giving every subprocess an open path to your network and services.