A sandboxed coding agent is safer than an unconfined one, but not safe by default. Most practical risk comes from abuse of what you granted inside the sandbox: tokens, network access, and write paths. Escape from the isolation layer matters too, but it is only one of several ways things go wrong.
Six myths
Myth 1: The sandbox stops prompt injection
Fact. It limits reach. OWASP says indirect injection can come from external content such as web pages or files, with impacts that include disclosure of sensitive information and unauthorized use of connected functions, and that no foolproof prevention is known. A sandbox narrows where injected instructions can act.
Myth 2: No internet means no data leaves
Fact. One platform states that with network access disabled the agent can still reach its model service, which may allow data to exit the VM. A session must talk to its model, so ask what that channel carries.
Myth 3: If the agent cannot merge, review is optional
Fact. Review is how you catch planted changes. Documented designs that block merging still rely on a human to review and merge, and hold workflow runs until approval.
Myth 4: A domain allowlist is a complete control
Fact. One firewall page says it applies to processes the agent starts through its shell tool, may be bypassed by sophisticated attacks, and should not be considered a comprehensive security solution.
Myth 5: Isolation technology makes the boundary absolute
Fact. gVisor's documentation says its goal is to minimize the risk of container escape. Firecracker's page says security depends on a well-configured host. Both are honest about limits.
Myth 6: Secrets in a private environment are hidden from the agent
Fact. Environment values are read into ordinary environment variables that any command the agent runs can read, per one platform. Only designs that keep the value outside the sandbox, such as a proxy that adds it to requests, hide it from the agent.
What this means in practice
| Layer | Question to answer |
|---|---|
| Isolation | Is the runtime appropriate for the code it runs? |
| Network | What can the agent reach, including via tools? |
| Credentials | What can a leaked or misused token do? |
| Git | Where can the agent write, and who reviews? |
| Pipeline | Do workflows run before a human looks? |
| Logs | Can we reconstruct a session? |
A balanced stance
Use sandboxes, because they work as one layer. Do not describe them as making an agent safe. Describe them as narrowing blast radius, and list what else you rely on. That wording holds up in a security review and in a customer questionnaire.
Worked example: abuse without escape
An illustrative incident narrative. An agent runs inside a well built sandbox: single use microVM, default deny egress to an allowlist, no secrets, single branch push. It is asked to update a dependency. The package's README contains hidden instructions saying the project requires a changed build step. The agent edits a workflow file and adds a helper script, then opens a pull request.
No isolation was broken. The microVM held. The network policy held. No credential was stolen. The risk is that the pull request now carries a malicious workflow change. If it is merged or its workflow runs without review, the attacker's code runs in your pipeline, where credentials and runners live.
This is why the layers after the sandbox matter. A gate that flags workflow file changes, a reviewer who reads changed files first, and held workflow runs each stop this path.
What to measure
| Metric | Why |
|---|---|
| Share of agent pull requests that changed workflow, build, or dependency files | Shows where review should focus |
| Rejection and change request rate | Zero over a long period may mean rubber stamping |
| Blocked network requests per session | Signals attempts or misconfiguration |
| Time to revoke a credential after suspicion | Tests your response |
| Age of the oldest cached environment | Tests rebuild discipline |
| Number of tools per agent | Smaller is easier to defend |
A plain way to describe the stance
For customers and auditors, a defensible summary reads like this: agents run in isolated, disposable environments with default deny network access, hold no standing credentials they can read, may only propose changes through reviewed pull requests, and have all activity logged. Then list limits honestly: the model connection stays open, allowed destinations can still receive data, and review quality matters.
Tabletop exercise
Run a one hour exercise with this scenario.
- Present the README injection above.
- Ask the team to trace each layer: what the sandbox did, what the gate did, what review did.
- Ask what they would see in logs after the fact.
- Ask which control, if missing, would have let it through.
- Capture two improvements and assign owners.
Keep both halves in view
Escape is rare and severe. Abuse is common and subtle. A program that only addresses escape leaves the common path open, and a program that only addresses abuse relies on the boundary holding. Maintain both.
Where Safeguard fits
Safeguard supports the layers around the sandbox: agent identity, policies and gates, MCP Guardrail, and dependency scanning. 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 watch how a gate decides whether a change may proceed, since that is the layer that catches abuse of an otherwise intact sandbox.
Quick check
What is the biggest sandbox mistake?
Treating the sandbox as the whole control. Credentials, egress, and review decide most outcomes.
Should we skip sandboxing if we review every pull request?
No. Review checks the output, while a sandbox limits what the agent can touch while it works. Use both.
How do we know our layers actually work?
Test them. Plant a hostile instruction in a test repository, run a task, and check what the sandbox, gate, review, and logs each did. Repeat after changes.
Sources
- OWASP LLM01:2025 Prompt Injection
- OWASP LLM06:2025 Excessive Agency
- Use Claude Code in the cloud (Anthropic documentation)
- Configure cloud environments (Anthropic documentation)
- Customize the Copilot cloud agent firewall (GitHub Docs)
- What is gVisor?
- Firecracker microVM project
Last reviewed: 19 October 2026.
