The trust boundary behind remote agent workspaces
Isolation starts with a precise answer to one question: what is the agent actually allowed to affect?
A remote machine is not automatically a sandbox. The security value comes from the boundary around it: identity, permissions, resources, network reach, and the lifetime of the workspace all need to reflect the task the agent is performing.
Start with effects, not tools
A shell command is only the interface. Its real meaning is the effect it can produce: changing files, opening a socket, reading a token, or consuming compute. A useful threat model begins with those effects and works backward to the tools and permissions required for them.
This keeps the boundary tied to the workload. A documentation task may only need one repository and no outbound network access. A deployment task needs a different, carefully scoped set of capabilities.
Bound the workspace on several axes
Filesystem scope is one layer. Process permissions, CPU and memory limits, network policy, secret exposure, and workspace duration are equally important. No single control carries the whole design.
Defaults matter because agents perform many small actions. A bounded default reduces the number of moments where a user must notice and correct an overly broad request.
Design for recovery
Isolation is stronger when a workspace can be inspected and replaced without drama. Logs help explain what happened, snapshots preserve useful state, and revocable credentials stop yesterday’s environment from retaining tomorrow’s authority.
The goal is not to promise that mistakes cannot happen. It is to keep their scope understandable and make returning to a known state routine.