A remote sandbox is an isolated environment, hosted by the vendor, where an AI agent runs code, edits files and uses tools instead of doing so on your machine. Ask what isolates it, what it can reach on the network, what it stores between runs, and who can see inside.
Definition
An agent that writes and runs code needs somewhere to run it. A local sandbox lives on your device. A remote sandbox lives in the vendor's cloud: you send a task, the agent works in a fenced environment, and you get results back. The fence is what makes running unreviewed generated code tolerable. If the fence is weak, the agent's code is running on shared infrastructure with other tenants' work, or reaching your internal systems.
How isolation is built
Isolation comes in a few styles, and the gVisor documentation describes the trade-offs clearly. Container isolation shares the host kernel. Machine level virtualization gives each workload a guest kernel through a hypervisor, which gives strong isolation at the cost of a larger footprint and slower start. Rule based execution, such as seccomp or AppArmor, restricts what a process may do through kernel hooks. The gVisor project describes a third approach: an application kernel in userspace that intercepts system calls, aiming for many of the benefits of virtual machines with a lighter footprint.
You do not need to pick the winner. You need the vendor to tell you which model they use, and why they think it fits running untrusted code.
| Style | Typical strength | Typical question |
|---|---|---|
| Plain container | Fast, light | Shared kernel, how is it hardened? |
| Virtual machine per task | Strong separation | Startup time, cost, image upkeep |
| Userspace kernel | Smaller kernel exposure | Compatibility, performance |
| Rule based confinement | Fine control | Rule coverage, bypass history |
Eight questions to ask
- What isolation technology separates one customer's sandbox from another's?
- Is each task in a fresh environment, or does one persist?
- What network access exists by default, and can it be restricted by an allowlist?
- How do secrets reach the sandbox, and can the agent read them?
- What does the agent see of your repositories: a copy, a mount, or live access?
- Who at the vendor can access sandbox contents, and under what process?
- Where is it hosted, in which regions?
- How are escapes handled: bug reporting, patching, and customer notice?
Question 4 is the one that causes real incidents. A sandbox with generous network access plus a secret inside it is a path for data to leave if the agent is manipulated by hostile content.
Excessive agency still applies
Isolation limits what a compromised or confused agent can damage on the host. It does not decide what the agent may do with the access it was given. OWASP lists excessive functionality, permissions and autonomy as root causes of excessive agency, and recommends minimizing tools and permissions and requiring approval for high impact actions. A well built sandbox with a repository token that can write to production is still a risk. Review the sandbox boundary and the access inside it as two separate checks.
Evidence to request
Ask for architecture documentation, the most recent independent assessment the vendor is willing to share, and the incident notice process. Treat a verbal description as a claim until you see a document. Keep what you receive with your other control evidence.
Related reading on sandbox choices: which sandbox for untrusted code and default deny egress for an agent sandbox.
Safeguard's MCP Guardrail and agent identity features cover the access side when an agent reaches security data, which complements whatever isolation the host product provides.
A worked example: fixing a failing test
A developer asks a hosted agent to fix a failing test in a repository. Here is what happens inside the remote sandbox, and where each question applies.
- The platform creates an environment (isolation question) and copies the repository into it (access question).
- The agent installs dependencies from public registries (network question). If egress is open, it can reach any host. If it is restricted to an allowlist, the install needs registry hosts permitted.
- The agent runs tests, edits files and runs tests again.
- The agent opens a pull request using a token (secrets question). The token's scope decides whether it can only open pull requests or also push to protected branches.
- The environment is torn down, or kept (state question).
A weak design fails in different places: shared kernel isolation with a hardening gap, open egress with a token inside, or a persistent environment that keeps the token after the task. A strong design makes each step narrow: strong isolation, an allowlist, a pull request only token and a disposable environment.
Step by step: evaluate a remote sandbox
- Ask for the architecture description and read it with your platform team.
- Create a test repository with no real code and a dummy token.
- Run an agent task that tries to contact an unlisted host.
- Check whether the dummy token is visible to the agent, and whether it persists.
- Run the task as two different users and compare what each can see.
- Check which logs exist for commands run, files changed and network calls made.
- Ask what happens during a vendor side incident, and how customers are told.
Reading the vendor's isolation answer
If the vendor says "containers", ask how the kernel is protected from a hostile workload. If it says "virtual machines", ask about startup time and how images are patched. If it says it uses a userspace kernel or rule based confinement, ask what workloads are known not to run well and what the compatibility gaps are. You are not grading the technology. You are checking that the answer is specific and that someone owns it.
| Vague answer | Better answer |
|---|---|
| "It is isolated" | "Each task runs in its own virtual machine with no shared kernel" |
| "Network is secure" | "Egress is denied by default, with an allowlist per organization" |
| "Secrets are safe" | "Secrets are injected at run time, scoped, and never written to disk" |
Try it yourself
Click through it at your own pace, or open it full screen. See how a gate stops a change until a rule passes, the same idea as an approval step around an agent.
Quick check
Does a sandbox make an agent safe?
It limits the blast radius on the host. The agent can still misuse whatever access you give it, so scope tokens and network access too.
Is remote safer than local?
Not automatically. It moves the trust to the vendor's isolation and operations, and may reduce risk to your endpoints.
Does a remote sandbox protect my repository from the agent?
Only partly. It limits damage to the host environment, but the agent can still change the repository through the access it holds. Scope tokens and require review of changes.
Sources
Last reviewed: 19 October 2026.
