Running a coding agent in a cloud sandbox moves risk from your personal machine to a shared, remote environment. You gain isolation from local files and credentials. You take on new exposure: repository and tokens uploaded to a platform, network egress rules you must set, and a session record that may hold sensitive output.
Side by side
| Question | Local agent | Cloud sandbox |
|---|---|---|
| What can the agent read? | Whatever your user account can read | Only what is cloned or provisioned |
| Where does code go? | Stays on the machine unless the agent sends it | Uploaded to the platform |
| Network control | Your laptop firewall and settings | Platform or self-built egress policy |
| Credentials | Your keys, SSH agent, cloud profiles | Tokens you add to the environment |
| Cleanup | Persistent, state accumulates | Often disposable per task |
| Review | You watch it live | You review a branch or pull request afterward |
What gets better
A local agent runs as you. It can reach your home directory, your shell history, and any login that is already open. A fresh cloud environment has none of that unless you put it there. Disposable environments also reduce the chance that one task leaves something behind for the next.
What gets worse
First, your source leaves the machine. One hosted agent documents that a local repository without a suitable remote is bundled and uploaded, including history across all branches plus uncommitted changes to tracked files. Check what that means for your own policy before enabling it.
Second, you now own an egress decision. A hosted platform may default to a limited allowlist, but one vendor notes that with network access disabled its own API connection can still exist, which may allow data to leave the VM. Plan for that.
Third, supervision changes. A cloud agent runs while you are away, so a bad decision may complete before anyone looks. That makes pull request review, branch protections, and workflow approvals more important, not less. One documented design only lets the agent push to a single branch, blocks merging, and holds workflows until a person approves them.
A simple way to decide
- List the repositories involved and rate the source sensitivity.
- Decide whether those repositories may leave your network.
- If yes, set a default deny egress policy and add only what builds need.
- Provision the narrowest credential that works, with a short lifetime.
- Require human review before anything merges or deploys.
- If no, keep the agent local and apply local permission rules and sandboxing instead.
Worked example: the same task two ways
Imagine a developer asks an agent to fix a failing integration test in a payments service. This is an illustrative scenario.
Local run. The agent starts in the developer's terminal. It can read the working directory and, depending on settings, anything else the user account can read. The developer sees each command and can stop it. If the agent lists the home directory and reads a cloud credentials file, that happens on the laptop, and the file never leaves unless the agent sends it somewhere. The control is the developer's attention plus local permission rules.
Cloud run. The developer starts the same task from a ticket and goes to a meeting. A fresh environment clones the repository. No home directory, no cloud profile, no password manager. The agent works for twenty minutes, pushes a branch, and opens a pull request. Nobody watched the commands. The control is the environment's limits plus the review that follows.
Neither is clearly safer. The local run exposes more of your machine but has live supervision. The cloud run exposes less of your machine but runs unattended and sends code to a platform. Which risk you prefer depends on what is on the laptop and what is in the repository.
Risk factors to rate before choosing
| Factor | Lower concern | Higher concern |
|---|---|---|
| Repository sensitivity | Public or low value code | Regulated data, secrets in history, unreleased products |
| Laptop contents | Dedicated dev machine | Personal files, production access, long lived cloud logins |
| Network position of the laptop | Isolated from internal systems | VPN into production networks |
| Review capacity | Every pull request gets a real read | Reviews are rubber stamps |
| Task type | Small, well tested changes | Build scripts, workflows, auth code |
| Vendor transparency | Published isolation and retention details | Marketing language only |
Score each row and look at the pattern. A high sensitivity repository on a developer laptop with production access is a poor fit for a local agent, and an equally poor fit for a cloud platform whose retention you cannot confirm. In that case the answer may be a self-hosted environment.
Hybrid patterns that work
- Plan locally, run in the cloud. Some documentation suggests planning with the agent in a read-only mode on your machine, committing the plan, and then letting a cloud session execute it. The plan becomes reviewable input.
- Local for exploration, cloud for execution. Reading and explaining code is low risk. Running installs and scripts benefits from isolation.
- Cloud for parallel chores. Dependency bumps, doc fixes, and flaky test repairs across many repositories fit the disposable model well.
What to put in a short policy
- Which repositories may use cloud agents, and which may not.
- Which identity the agent uses, and which repositories it can reach.
- The default network policy and who may change it.
- Required review before merge, and workflow approval rules.
- How sessions are logged and for how long.
- Who owns exceptions.
A one page policy that people can find beats a detailed one nobody reads.
Where Safeguard fits
Safeguard does not run the agent. It supports the governance side with agent identity, policies and gates, MCP Guardrail, and dependency scanning on what an agent proposes.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through it and watch what is checked before a change is allowed to proceed, since that check matters more when an agent works unattended.
Quick check
Should regulated source code go to a cloud coding agent?
That is a policy decision for you and your counsel. Start by reading what the platform uploads and retains, and consider a self-hosted environment if code must stay in your network.
Is a local agent always riskier?
No. It runs with your user's reach, which can be wide, but nothing leaves the machine unless the agent sends it. Compare the two for your own data.
Can we use both local and cloud agents?
Yes. Many teams use local agents for exploration and cloud agents for isolated, well scoped chores, with the same review rules for both.
Sources
- Use Claude Code in the cloud (Anthropic documentation)
- Risks and mitigations for Copilot cloud agent (GitHub Docs)
- OWASP LLM06:2025 Excessive Agency
Last reviewed: 19 October 2026.
