Real isolation with Cloud Agents, and setting it by reflex

When you need real isolation: Cloud Agents

Sometimes the right answer isn’t tuning the local controls at all - it’s not running on your machine in the first place. Cursor’s Cloud Agents (formerly Background Agents) operate in isolated VMs in the cloud with full development environments instead of on your local machine: the agent clones budgetcli onto a fresh branch, does its work, and pushes results back. This reduces local filesystem risk, but it does not remove the cloud threat model: the agent may have repository credentials, network access, secrets exposed through its environment, and permission to create or modify branches. Scope those separately. The environment is configured from .cursor/environment.json (a Dockerfile is supported), so the box is reproducible the same way every run.

This is a clean way to move local filesystem risk out of the loop, but it is not a blanket safety guarantee. Use least-privilege repository access, keep secrets out of the environment unless required, restrict triggers, disable auto-merge, and review every returned branch. We pick Cloud Agents back up in the CLI chapter, where running headless and unattended makes those controls matter most.

(Reference: Cursor Cloud Agents documentation; older material may call them Background Agents.)

Set it by reflex

The shape to carry out of this chapter:

• Pick the mode for the work. Unfamiliar code or real stakes → Auto-review (the default) or plain Allowlist for a known-safe command set. Repetitive, supervised grind where you want the loop to run unattended → Allowlist with sandboxing on. Run Everything stays in the disposable-environment box, not on your real machine.
• Lean on the sandbox, not the lists. The Agent Sandbox is the local wall that actually holds - on macOS directly, on Linux given the kernel prerequisites, on Windows via WSL2. Allow/deny rules express policy, but they are not your last line of defense.
• When you need a real guarantee, change where the agent runs - a Cloud Agent in an isolated VM - rather than trying to harden the local lists into something they aren’t.

Get the ordering right - sandbox load-bearing, lists superseded - and the rest is muscle memory: loose on the mode where the work is tedious and watched, tight on reach because the wall, not the model, is what’s keeping the agent in its lane.

With the blast radius set deliberately, you can afford to run more than one agent at a time - which is where the next chapter goes, fanning a single brief out across isolated worktrees so several agents work without stepping on each other. Next: running agents in parallel.