Isolation and Residency: One Environment Per Task, Placeable by Region

Of the six platforms graded in this guide's platform comparison, all six document per-task execution isolation and zero document regional placement. That asymmetry is the whole story of this property, the fourth of the seven that make audit evidence a byproduct of normal operation. The execution half (one environment per task, no cross-talk) is table stakes the field has converged on. The residency half (where, geographically and organizationally, your code runs) is the emptiest column in the matrix: not one shipping platform documents it. The evidence for both halves comes from one architectural decision made in Build the Environment: the agent's hands are a provisionable resource, so isolation is a boundary you draw and residency is a parameter you set.

One environment per task is the part the field agrees on

Every platform in the comparison documents some form of per-task execution isolation. Google Jules "runs each task inside a secure, short-lived virtual machine" where "your data stays isolated within the execution environment." OpenAI Codex cloud creates one container per task, checked out fresh at a chosen SHA. GitHub Copilot cloud agent gives each task "its own ephemeral development environment, powered by GitHub Actions." Cursor cloud agents run "inside our AWS infrastructure in isolated VMs."

The why comes from Brex, whose in-house platform gives each task its own RDE (Brex's per-task isolated remote developer environment): "running 50 in parallel, each iterating independently, requires thinking carefully about orchestration and environment isolation." Isolation is what makes parallelism safe. The compliance reading is the same mechanism from the other side: if environments cannot talk to each other, one task's code and data cannot leak into another's, and the blast radius of any one compromised agent is one workspace. The one environment per task page makes the operational argument. The auditable artifact is the per-task environment record itself, surfaced through the four-axis audit query.

The leak is in the snapshot pipeline, not the running task

The documented dents are at the boundaries between tasks, not inside them. Codex's docs state that for Business and Enterprise plans, "caches are shared across all users who have access to the environment," so post-setup container state crosses user boundaries within a workspace. Cursor's docs warn that "if you include .env.local files during snapshot creation, they will be saved," freezing one user's credentials into an image others boot. And credential scrubbing before snapshot appears in no platform's documentation at all. Per-task isolation that feeds from a shared, unscrubbed image is isolation with a side channel; the snapshot pipeline is part of the boundary. The fix is a property of how images are built and credentials are scrubbed, covered in versioned images; the audit question for this property is whether that scrub is a hard gate or a hope.

Not one platform documents where your code runs

No platform in the comparison documents regional placement of execution or session data. Jules comes closest to saying something, and what it says is "worldwide, everywhere where the Gemini model is available," which is a statement about model availability, not about where your code runs or any control over it. Cursor names a region exactly once: artifacts upload to an S3 host in us-east-1. Placement of the VMs themselves is undocumented. Copilot, Codex, and the Anthropic managed-agents article do not use the words residency or region. Brex is moot by construction, an internal platform on its own infrastructure.

One caveat: absence of documentation is not evidence of absence. Some of these platforms may place execution regionally and simply not say so. But for a buyer answering a GDPR or HIPAA questionnaire, a control you cannot point to in writing is a control you cannot put in an audit.

The architecture already makes residency a placement decision

The brain/hands split means residency requires choosing where to provision the hands, not redesigning the system. Anthropic's managed-agents architecture separates the reasoning loop from the sandbox where code lives, and the split removes the need for network peering: the hands can sit inside a customer's own VPC while the harness runs elsewhere. That is the architectural precondition for "the code never leaves our perimeter," even though the article never frames it as a residency feature. Once the sandbox is a provisionable resource rather than a fixed location, "EU data stays in the EU" is a parameter on provision, the same way instance size is.

Wallfacer (disclosure: the sponsor of this guide) builds on this shape: isolated VM pairs per session, booted in roughly 2 seconds from a versioned snapshot, with server placement zoned at the infrastructure layer. But zoning the fleet is not a residency control a buyer can hold: there is no published region selector or residency guarantee, so under this handbook's published-documentation rule the sponsor's residency cell stays undocumented like everyone else's.

Three questions decide this property, each answerable in one sentence

Put these to any vendor: What is the isolation unit per task, and what state (caches, snapshots, artifacts) crosses it? In which regions does execution run, and who chooses? Can the sandbox run inside our network boundary? If the answers are not in the security documentation, treat them as no until they are, because a control you cannot cite is a control you cannot put in an audit. The auditor questions page carries the longer list, and the framework mapping for GDPR, HIPAA, and the EU AI Act shows which regulation each answer satisfies.