Cloud sessions run the agent in an isolated environment someone else operates, with credentials and network access controlled there. Local sessions run on a developer machine, where the boundary is whatever you configure. Cloud shifts risk toward data handling and vendor settings, and local shifts it toward credentials and isolation on laptops.
What two vendors document
Anthropic's Claude Code security page describes cloud sessions. In Anthropic hosted environments, each session runs in an isolated virtual machine managed by Anthropic, network access is limited by default and can be disabled or restricted to specific domains, and GitHub credentials are stored encrypted on Anthropic's servers and never enter the session machine, which holds a short lived credential scoped to that session. The page also says operations in cloud sessions are logged, session machines are reclaimed after inactivity, and sessions routed to a self-hosted environment run on your own infrastructure, where isolation, network egress, and git credentials are your deployment's responsibility. A separate remote control mode keeps all code execution and file access on your local machine.
OpenAI's documentation on agent approvals and security describes cloud tasks that run in isolated, OpenAI managed containers. Setup can reach the network to install dependencies, the agent phase runs offline by default unless internet access is enabled for the environment, and secrets are available only during setup and removed before the agent phase begins. It says local command line and editor use rely on operating system level sandboxing with settings you configure yourself.
Safeguard's download page lists a Local agent and a Cloud agent as available, alongside a hosted sandbox that runs against a seeded demo repository. Both ways of running exist across the industry, which is why the question is worth a framework.
Comparison
| Concern | Cloud session | Local session |
|---|---|---|
| Where code runs | Provider or self-hosted environment | Developer machine |
| Default isolation | Dedicated environment per session | Whatever you set up |
| Credentials | Can be kept out of the session and scoped to it | Often inherited from the developer |
| Network | Limited by default in the documented examples | Open unless you restrict it |
| Data path | Repository content goes to the environment | Prompts and files go to a model endpoint |
| Logs | Central, per the documented examples | Local, unless you capture them |
| Cleanup | Automatic reclamation | Manual |
| Developer experience | Works from anywhere, slower to customize | Fast, uses local tools |
A worked example: choosing by task
| Task | Better fit | Why |
|---|---|---|
| Long running refactor | Cloud, restricted network | Disposable environment, no ambient laptop credentials |
| Quick fix with local tools | Local in a container | Speed, familiar environment |
| Work on restricted code | Neither until reviewed | Needs a specific data decision |
| Scheduled maintenance job | Cloud with a named owner | Central logs, fixed task |
| Exploring a public repository | Either, read-only | Low risk |
Questions to ask for either model
- What does the agent reach, and what credentials does it hold?
- Where does repository content go, and how long is it kept?
- Can network access be restricted to named hosts?
- Can sessions be audited and deleted?
- Who can change the settings, and are changes logged?
- What happens when the session ends?
Cloud specific checks
Ask how repository access is granted. The cleanest designs keep long lived credentials out of the session and apply your branch protection to whatever the session pushes. Anthropic's page, for example, says branch protection rules and rulesets apply to the access you connected, and that a rule the connected access can bypass does not block a push. That is a useful reminder to check which identity the agent uses and whether it can bypass your rules.
Local specific checks
Use a container or virtual machine, mount only the project, strip inherited credentials, and restrict the network. Our post on sandboxing a terminal assistant gives the steps.
Mixed estates
Most teams end up with both. Use one policy that states required properties, such as scoped credentials, restricted network, logging, and review, and then show how each environment meets them. A policy written around properties survives tool changes.
A decision record you can reuse
Write the choice down so it survives staff changes. A short record has five lines: the workload, the environment chosen, the properties required, the evidence that each property holds, and the review date.
| Field | Example entry |
|---|---|
| Workload | Weekly dependency upgrade across four services |
| Environment | Cloud session with restricted network and a named owner |
| Required properties | Scoped credential, network limited to registry mirror, logs retained, human review |
| Evidence | Session log sample, network rule export, branch protection screenshot |
| Review date | Next quarter, or on any provider change |
Failure modes to watch
- A cloud environment allowed full internet access during the agent phase because someone enabled it once for a convenience.
- A local session started from a shell that was logged in to production tooling.
- A scheduled cloud job with no owner, still running after the person who set it up left.
- Logs that exist but nobody reads, so unusual hosts go unnoticed.
Assign each environment an owner, and put a review of its settings on a calendar.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through and notice what runs on your own machine and what is sent onward.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning, reachability analysis, policies and gates on pull requests, and agent identity, and the Safeguard CLI can also write code. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is cloud always safer than local?
No. Cloud can isolate and scope credentials well, but it adds a data path to a provider. Compare on the properties that matter to you.
What if the cloud environment can bypass branch protection?
Then your protection is weaker than you think. Check which identity the agent uses and whether your rules apply to it.
Can we mix cloud and local?
Yes, under one policy that states required properties for both.
Sources
- Claude Code security documentation
- OpenAI Codex agent approvals and security documentation
- Safeguard download page
Last reviewed: 19 October 2026.
