Sandbox isolation

When you give an agent real tools — a terminal, a browser, Git — you're trusting it to run code on your data. Buda makes that safe by giving every agent its own cloud computer. Agents don't share a machine, so one agent's work can never leak into another's, and a misbehaving task is bounded by its own limits.

Per-agent isolation

Every Claw runs in a dedicated sandbox that Buda provisions when the agent is created:

• One sandbox per agent. Each agent has its own files, browser, terminal, and Git — isolated from every other agent in your Space.
• Named persistent volume. Working files live on a per-agent volume (buda-agent-<space>-<agent>), so two agents never see each other's files.
• Plan-scoped CPU and memory. Resources are provisioned from your Space's plan. A heavy task is capped by the agent's own allocation — it can't starve the rest of your team.

Network and data boundaries

• Space-scoped data. A sandbox only has access to its own agent's working files and the Drive of the Space it belongs to. It cannot reach into another Space.
• Drive as the boundary. Knowledge an agent should use goes into Drive deliberately. The sandbox reads from there — it doesn't have ambient access to your other systems.
• Outbound web via the browser tool. Agents reach the internet through their own sandboxed browser and terminal, scoped to the task you gave them.

Persistence and cleanup

• Persistent working files. The agent's volume survives between sessions, so an agent keeps its workspace, history, and memory across tasks.
• Idle sleep. When a sandbox has no active work, Buda puts it to sleep — nothing keeps running unsupervised, and idle compute isn't billed against your plan.
• On-demand wake. The next task wakes the sandbox back up with its files intact, so persistence and cleanup work together: state is kept, but the machine doesn't idle hot.

Related