CLEAR BOUNDARIES. YOUR SAVED PROJECTS.

Give your agents
their own space.

Sandspace is a private operator pilot. These are the controls built into the workspace design, alongside the limits you should understand before using it.

Your computer stays outside

The workspace does not mount local drives, forward an SSH agent, or copy your computer’s credential directories. You choose what repository or files to bring into the remote workspace.

Cloud authority stays outside

Workspace guests are provisioned without a Google service account, OAuth scopes, or a public IP. Provisioning and lifecycle authority belong to the separate control plane.

Account access is scoped

Google or GitHub sign-in identifies an invited account. Workspace and terminal requests are authorized by the backend for that owner. Short-lived terminal tickets are consumed once.

Compute pauses. Projects stay saved.

Cloud-side compute limits stop a running workspace while keeping its disk and files. Projects are deleted only when their owner explicitly confirms deletion. Pausing stops running programs; resume opens a new terminal session with your saved files.

Know the pilot’s boundaries.

Agents can run commands and access files inside their workspace. Authenticate provider and repository accounts there with the least access you need. Separate agent processes share the same worktree; they are not isolated from each other.

Exports exclude environment files, credential/cache directories, Git history, dependencies, and file links, with a 20 MiB limit. Review an export before relying on it. Do not use this pilot for sensitive production data.

Local tests do not establish cloud isolation. Live provider login, isolation, saved-file recovery, and deletion evidence must be verified before broader access.

Read about pilot access