Choose a local sandbox when the work needs your files and tools and the data must stay on the device. Choose a remote sandbox when you want isolation from endpoints, central control and tasks that run while devices are off. Many teams use both, split by data sensitivity and task type.
The core trade
A local sandbox keeps work on a machine you manage. A remote sandbox moves it to the vendor's infrastructure. Both can be well or badly built. The decision comes down to where the data and the trust should sit.
Comparison
| Factor | Local sandbox | Remote sandbox |
|---|---|---|
| Data location | Your device | Vendor cloud |
| Access to local files and tools | Direct | Via upload or connectors |
| Runs when device is off | No | Yes |
| Isolation quality | Depends on the endpoint and settings | Depends on vendor design |
| Central visibility | Needs endpoint tooling | Usually in a console |
| Secrets exposure | On the machine | In the vendor's environment |
| Scale for many tasks | Limited by the device | Elastic |
| Cleanup | Per machine | Vendor controlled |
Decide by task, not by product
Run each task type through four questions.
- How sensitive is the data the agent reads? Regulated or confidential data tilts toward the place you can already justify in your own risk assessment. Sometimes that is local. Sometimes a vendor environment with strong contracts is easier to defend than hundreds of laptops.
- Does the task handle untrusted input? Public issues, inbound email and third party documents are handled safest in a fresh, disposable, restricted environment, which a remote sandbox often provides more consistently.
- Does it need local context? Large local codebases, private tools, or hardware dependent tests favor local.
- Must it run unattended? Scheduled or long running work favors remote, since devices sleep.
Typical splits
| Task | Common choice |
|---|---|
| Interactive coding in a trusted repo | Local, with scoped folder |
| Reviewing untrusted pull requests or issues | Remote or isolated disposable environment |
| Nightly reports | Remote with alerting |
| Work on regulated data | Per your risk assessment, documented |
| Experiments with new tools | Remote throwaway |
What does not change
Whichever you choose, apply the same access principles. OWASP recommends minimizing extensions, their functionality and permissions, avoiding open ended extensions, executing in the user's context and requiring approval for high impact actions. A sandbox boundary does not replace these. And in both cases, control the network: an agent that can reach anything can send anything anywhere.
Cost and effort
Local setups cost endpoint management effort. Remote setups cost usage and vendor management effort. Ask vendors how remote usage is metered and whether it can be capped, then set a budget alert once you know your volumes. For local setups, count the hours your platform team will spend on settings, updates and support.
Write the decision down
Record, per task type, the choice, the reason, the data class and the owner. When the vendor changes a default or you change a policy, you will have a baseline to revisit. See also local or hosted coding agents: where does your code run.
Safeguard's compliance and evidence automation can keep those decision records with your other control documentation.
A worked example: three tasks, three answers
A company runs three agent tasks and applies the four questions.
Task A: refactor a function in a trusted internal repository. Data is internal, input is trusted, it needs local tools and runs while the developer watches. Choice: local sandbox, with scoped folders and approval on commands.
Task B: triage new public issues on an open source project the company maintains. Input is untrusted, the content comes from strangers, and the task can run unattended. Choice: remote sandbox, fresh per task, restricted network, a token that can only comment.
Task C: summarize customer contracts for the legal team. Data is confidential and may contain personal data. The question is where it is easier to defend processing. Choice: decided by the legal and security teams after reviewing the vendor's terms and the endpoint controls, and documented either way.
The point is not that one answer wins. Each choice follows from data, input trust, context needs and timing, and each is written down with an owner.
Step by step: make the decision for a new task
- Name the task and its owner.
- Classify the data it reads and writes.
- Classify its input as trusted, mixed or untrusted.
- Decide whether it needs local files or tools.
- Decide whether it must run unattended.
- Pick local or remote using the table above.
- Write the controls: folders, commands, network, token scope, state.
- Set a review date.
Controls that apply to both
| Control | Local | Remote |
|---|---|---|
| Narrow token scope | Yes | Yes |
| Network allowlist | Via endpoint tooling | Vendor setting |
| Approval for risky actions | App setting | Platform setting |
| Logs | Endpoint collection | Vendor export |
| Wipe or teardown | Per device | Per environment |
Mixed setups
Some products let a local agent hand tasks to a remote one. Treat that handoff as a boundary: what data crosses it, under what identity, and with what approval. A mixed setup can combine the strengths of each, but it also doubles the questions.
Revisit on triggers
Review the decision when the vendor changes defaults, the data class changes, a near miss occurs, or a new regulation or contract term affects where data may be processed.
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
Can we use both local and remote sandboxes?
Yes, and many teams do. Split by data sensitivity, input trust and whether the task must run unattended.
Which is safer for untrusted input?
A fresh, restricted, disposable environment, which is often easier to guarantee remotely. Verify the vendor's isolation and network controls first.
Can we change the choice later?
Yes. Record the reason for each choice and the review triggers, so changing it is a documented decision rather than a surprise.
Sources
Last reviewed: 19 October 2026.
