With a vendor-hosted sandbox, the provider builds and operates the isolation, and you configure access and review output. With a self-hosted one, isolation is your responsibility: host hardening, network egress, credentials, and cleanup. Choose based on where code may run and how much isolation work your team can sustain.
What the documentation says
One platform states that sessions routed to a self-hosted environment run on your own infrastructure, where isolation is your deployment's responsibility, and that you restrict session egress at your own network boundary. In its hosted environments it describes isolated VMs, a network proxy, and credentials kept outside the VM. It also notes that a self-hosted environment does not have the stored network secrets feature, and that your deployment supplies git credentials.
Another platform recommends, for self-hosted runners, ephemeral single-use runners, restricting network access so the agent has no open access to your network or the public internet, and disabling its integrated firewall because the firewall is incompatible with self-hosted runners. That last point is easy to miss: moving to your own runner can remove a control you were relying on, so you must replace it.
Comparison
| Area | Vendor-hosted | Self-hosted |
|---|---|---|
| Isolation technology | Provider chooses and operates | You choose and operate |
| Network egress | Provider defaults plus your settings | Your network boundary |
| Credentials | Provider mechanisms such as proxies | You supply and protect them |
| Source location | Uploaded to the provider | Stays in your environment |
| Evidence | Provider docs and your session records | Your own logs and configs |
| Effort | Configuration and review | Build, patch, monitor |
| Controls that may not carry over | None to replace | Built in firewalls or secret features |
Decision guide
- Can the code leave your network? If policy says no, self-host.
- Do you have staff to patch hosts and tune egress? If not, hosted may be safer in practice.
- Do you need proof of controls for an audit? Hosted gives you the vendor's documentation. Self-hosted gives you control and the duty to produce your own evidence.
- How untrusted is the code? Untrusted code argues for stronger isolation, such as a user-space kernel or microVM, whichever you pick.
- Can you run ephemeral environments? Single use sandboxes reduce leftover state in either model.
If you self-host, minimum bar
- One sandbox per task, destroyed afterward.
- Default deny egress with an allowlist you own.
- No access to the cloud metadata address from the sandbox.
- Credentials issued per task, scoped, and short-lived.
- Logs for tool calls, network decisions, and git operations.
- A patch process for the host and runtime.
Worked example: two teams, two choices
Illustrative scenarios.
Team One builds consumer software, has a small platform group, and keeps source in a hosted git service. They choose a vendor hosted sandbox. Their work is to configure a tight network setting, add scoped repository access, require held workflows and review, and read the vendor's documentation each quarter for changes. They accept that source is uploaded to the provider and confirm retention terms in writing.
Team Two builds software for customers whose contracts forbid source leaving a controlled network. They choose a self-hosted environment on their own cluster. Their work is bigger: pick an isolation runtime, write network policy, run an egress proxy, issue per-task credentials, patch hosts, collect logs, and test the setup. They also replace any built in control the hosted option offered, such as a managed firewall or credential proxy, because those do not carry over.
Both are reasonable. The failure modes differ. Team One's risk is trusting defaults. Team Two's risk is under-investing in the platform.
Effort comparison
| Task | Vendor-hosted | Self-hosted |
|---|---|---|
| Patch the host and runtime | Provider | You |
| Define egress | Configure provider settings | Build and run it |
| Credential handling | Use provider features | Build or buy |
| Capacity and cost control | Provider limits | You |
| Incident response for the sandbox layer | Shared, depends on contract | You |
| Evidence of controls | Provider docs and reports | Your own records |
| Customization | Limited to what is offered | Full |
Questions for a self-hosting plan
- Who is on call for the sandbox platform?
- How fast can you patch the runtime after an advisory?
- How do you test isolation, and how often?
- What does a session leave behind, and who cleans it?
- How are costs capped when an agent loops?
- What is the exit plan if the platform proves too costly to run?
A middle path
Some teams use a vendor hosted sandbox for public or low sensitivity repositories and self-host only for the sensitive ones. That keeps operational effort proportional to risk. It also means two sets of rules, so write both down and make the dividing line explicit.
Contract and evidence angles
For hosted options, ask for documentation on isolation, retention, and subprocessors, and align what you tell your own customers with what the vendor states. Do not repeat a vendor's marketing as your own claim. For self-hosted, maintain your own architecture notes, network diagrams, and test records.
Where Safeguard fits
Safeguard does not host sandboxes. It supports governance in either model through agent identity, policies and gates, MCP Guardrail, and compliance and evidence automation.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through it and look at how continuous checks surface changes over time, since a self-hosted sandbox needs the same ongoing attention.
Quick check
Is self-hosted always more secure?
No. It keeps code in your network, but you must build and maintain the isolation yourself.
Can I move from hosted to self-hosted without changing controls?
Not safely. Some controls, such as built in firewalls or credential features, may not apply, so list them first.
Can a small team realistically self-host agent sandboxes?
Yes, if scope is narrow and the platform is treated as a product with an owner. Without an owner and a patch process, a hosted option is often safer in practice.
Sources
- Use Claude Code in the cloud (Anthropic documentation)
- Configure cloud environments (Anthropic documentation)
- Customize the Copilot cloud agent environment (GitHub Docs)
Last reviewed: 19 October 2026.
