A remote cloud sandbox is a short-lived virtual machine or container, hosted away from your laptop, where a coding agent clones your repository, runs commands, and proposes changes. It limits damage to one disposable environment. It does not make the agent trustworthy, and anything you put inside it is still exposed to the agent.
The pieces of a typical setup
Hosted coding agents differ in detail, but the shape is similar. A task starts, the platform allocates an isolated environment, your repository is cloned, a setup step installs dependencies, and the agent works until it opens a branch or pull request. The environment is then paused or thrown away.
One vendor's documentation says each session runs in its own isolated VM and that network access is limited by default. Another documents a firewall that limits the domains the agent can reach, and a third blocks internet access during the agent phase by default while letting setup scripts reach the network. Those are three different designs for the same idea. The sources are listed below.
What the sandbox is meant to protect
| Asset | What the sandbox helps with |
|---|---|
| Your laptop and local files | The agent never touches them |
| Other tenants and other tasks | Each task gets its own environment |
| The host operating system | A VM or user-space kernel sits between agent and host |
| Your network | Egress limits restrict where traffic can go |
What it does not protect
The agent can read everything you gave the environment. That includes the repository, every environment variable, and any token placed there. OWASP describes excessive agency as damaging actions taken in response to unexpected, ambiguous, or manipulated model output, with causes that include too much functionality, too many permissions, and too much autonomy. A sandbox narrows where those actions land. It does not remove the three causes.
Prompt injection is the usual way manipulated output arises. OWASP notes that indirect injection can come from external content the model processes, such as web pages or files, and that no foolproof prevention is known. A dependency README or an issue comment is enough input.
Questions to ask about any sandbox
- Is each task a fresh environment, or can state carry over?
- What can the agent reach on the network, and who decides?
- Which credentials exist inside the environment, and how long do they live?
- Where can the agent write, and does a human review before merge?
- Who owns isolation: the vendor, or your own infrastructure?
The last one matters. One vendor states that for sessions routed to a customer's own environment, isolation is the deployment's responsibility. A sandbox you host yourself is only as strong as its configuration.
A worked example: one task from start to finish
Consider a team that asks a hosted agent to upgrade a logging library in one repository. This is an illustrative scenario, not a measurement.
- A developer with write access starts the task from a ticket.
- The platform allocates a fresh environment and clones the repository at the main branch.
- A setup step installs dependencies from the lockfile. This step may have network access the agent will not have later.
- The agent edits the manifest, runs the test suite, and fixes two failing tests.
- The agent pushes a task branch and opens a pull request. It cannot merge.
- A reviewer reads the diff, checks the session record, approves, and merges.
- The environment is paused or destroyed.
Now ask what each step exposed. In step 2 the agent can read the whole repository. In step 3 the install scripts of every dependency ran. In step 4 the agent ran commands whose output it then read back, so a hostile string in a test fixture or README could have steered it. In step 5 a branch exists that CI may want to run. Each of those is a place a control belongs.
Sandbox, container, VM, runner: clearing up the words
| Term | What it usually means | Isolation strength |
|---|---|---|
| Container | Processes sharing the host kernel, separated by namespaces | Moderate, depends on configuration |
| MicroVM | A small virtual machine with its own kernel | Stronger, host must be hardened |
| User-space kernel | A kernel written to intercept system calls | Stronger than a plain container, with compatibility trade-offs |
| CI runner | A machine or VM that executes workflow jobs | Depends on whether it is single use |
| Sandbox | A loose label for any of the above plus network and credential limits | Depends on all of it |
When a vendor says "sandbox," ask which row they mean. The word alone tells you very little, and a sandbox built on a container with a mounted runtime socket is not the same thing as a single-use microVM with no credentials.
Four properties that define a good one
- Disposable. The environment is created for the task and removed after it. Nothing carries over.
- Constrained network. Outbound traffic is denied by default, with named exceptions.
- Minimal credentials. The agent holds the narrowest token that works, preferably one it cannot read.
- Reviewed output. The only way work leaves the sandbox is through a branch or pull request that a person reviews.
If a product you are evaluating cannot show you all four, it is a convenience feature, not a security boundary.
What it costs you
A cloud sandbox is not free of work. Someone must write the setup script, decide the network policy, issue credentials, read session records, and review pull requests. Teams that skip those tasks usually discover the gap after something unexpected happens. A reasonable plan is to start with one low sensitivity repository, measure how much review the agent's output needs, and widen scope only as the controls prove themselves.
Where Safeguard fits
Safeguard does not host agent sandboxes. It helps with the controls around them: agent identity, policies and gates, MCP Guardrail, and dependency scanning of what the agent adds. You can run 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 which steps only read information and which could change something.
Quick check
Is a cloud sandbox safer than running an agent locally?
Often it limits blast radius, because the agent is away from your personal files and credentials. But the agent still holds whatever you provision in the sandbox, so the gain depends on what you put there.
Does a sandbox stop prompt injection?
No. It limits what an injected instruction can reach. OWASP says no foolproof prevention is known, so treat the sandbox as one layer.
Does a sandbox replace code review?
No. The sandbox limits what the agent can touch while it works. Review checks what it produced. You need both, since a clean sandbox can still emit a bad change.
Sources
- Use Claude Code in the cloud (Anthropic documentation)
- Customize the Copilot cloud agent firewall (GitHub Docs)
- Codex cloud internet access (OpenAI documentation)
- OWASP LLM06:2025 Excessive Agency
- OWASP LLM01:2025 Prompt Injection
Last reviewed: 19 October 2026.
