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) run in isolated VMs in the cloud with full development environments instead of on your local machine, or on self-hosted machines if you operate your own (the cloud-agent docs’ label is “Self-Hosted Machines”): the agent clones budgetcli (the course’s illustrative personal-finance API) onto a fresh branch, does its work, and pushes results back. This moves local filesystem risk out of the loop, 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.

Moving the machine is a clean way to get local containment, but it is not a blanket safety guarantee. Use least-privilege repository access, keep secrets out of the environment unless required, restrict what can start an agent in the first place (the triggers the docs list: mentions, issues, and the chat integrations), and review every returned branch before it merges. We pick Cloud Agents back up in the CLI chapter’s page on unattended cloud work, where running headless 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: known-safe calls run immediately, shell commands run in the sandbox where possible, and a classifier reviews the rest) or plain Allowlist for a known-safe command set. Repetitive grind you watch but don’t want to approve action-by-action → 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; Windows is not documented as sandboxed as of September 2026 (run modes documentation). 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 - the sandbox load-bearing, the 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 damage a wrong command can do bounded on purpose, 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.