Security boundaries

Containment is not authority

The sandbox contains the computing work, but it does not decide what the agent may do. A VM is a containment boundary: it limits where an action can run and what it can reach. It is not an authority boundary, which decides whether an action is allowed. Authority comes from permissions, connector scopes and approvals. A connector's scope is the list of things it is allowed to do.

An action needs authority, not just containment, to take effect. Untrusted content can carry injected instructions into the model's tool call. The call passes containment (the VM, the egress proxy, no connector tokens), which limits reach but grants no permission. Then authority (permissions, scopes, approvals) decides. Allowed calls cause an effect. Others stop or ask a person.

Injected text can shape the model's tool call. Prompt injection means instructions hidden in content the agent reads. The sandbox limits where that tool call runs. But only the authority check decides whether it takes effect.

The same split applies inside a project. Instructions you give a project coordinator are saved but not enforced, and each thread asks for approval only inside itself. See Authority in a project.

The controls around a session

Control	What it does	Basis
One sandbox for each session	Created when the session starts and destroyed when it ends. No state is shared across sessions or organizations	Vendor-documented¹
Egress proxy	All outbound traffic goes through a proxy that the sandbox cannot bypass. Only destinations on the allowlist are reachable. Private or internal addresses are not	Vendor-documented.¹ The proxy and the allowlist were observed
Credentials	Connector authorization tokens never enter the sandbox. It holds only short-lived tokens limited to the session	Vendor-documented.¹ A token limited to the session was observed in the environment
Your computer	Reached only through the desktop app, and only in the folders you connect. Deleting is off until you allow it	The folder limit is vendor-documented.¹ The deletion default is tool-documented
Network secrets	An API key the agent proxy adds after a request leaves the VM. The key stays outside. It still works for the listed hosts, in every session in that environment	Vendor-documented²
GitHub proxy	Keeps your real GitHub credentials outside the VM. Rejects branch deletions and pushes of anything other than a branch, such as a tag. Serves API requests only for the repositories attached to the session	Vendor-documented²
Approvals	Desktop tasks have a permission mode for each task. Cloud runs use auto mode, where ask rules still stop the run. In Desktop tasks, MCP tools marked `requiresUserInteraction` ask on every call. A trigger's prompt never counts as approval	Vendor-documented (the scheduled tasks documentation)³,⁴

The Tour describes the same controls from the user's side, in Where the work actually runs.

Risks that isolation alone does not remove

Prompt injection. Web pages, files, emails and tool results can contain instructions. The agent can act on them, within whatever permissions it has. Treat that content as data, not as instructions. Require approval for payments, sends and deletes.
Secrets in the workspace. Any code in the sandbox can read its files and environment variables. Do not paste long-lived keys into a session. Use connectors or a network secret, which stay outside the VM.²
Local access widens the reach. Linking a computer extends the agent into the folders you connect. Grant the smallest set of folders the task needs.
Isolation is not perfect. Sandboxes reduce the impact of an attack, but they do not rule out escape bugs, flaws that let code break out of the sandbox. So design as if a session could be compromised. Use least privilege (give only the access a job needs), short-lived tokens and audit logs, which record who did what.

Containment is not authority

The controls around a session

Risks that isolation alone does not remove

Check yourself

What is the difference between containment and authority?

Sources