Sandboxing and Safety

Every workload runs inside an isolated sandbox. This protects the host, the operator, and the customer while making agent behavior reviewable.

Isolation is enforced by the runtime. Slashing applies only when an onchain Blueprint service defines the fault, the evidence path, and the slashable collateral. Tangle-managed API incidents still need operational response even when no onchain slashing rule applies.

Isolation Technologies

Operators choose isolation based on security requirements and workload type:

Docker containers provide process, filesystem, and network separation. Containers are lightweight, well-understood, and suitable for most workloads where standard isolation suffices.

Firecracker micro-VMs provide hardware-level isolation with millisecond boot times. Suitable for workloads requiring the strongest guarantees, where even kernel-level exploits should not compromise the host.

Docker containers and Firecracker micro-VMs are the isolation technologies today. The create API accepts four driver types: driver: { type: "docker" | "firecracker" | "host-agent" | "tangle" }. Operators declare which ones they run, and customers select one per sandbox. A host-agent driver picks its isolation separately with runtimeBackend: "docker" | "firecracker".

Isolation Guarantees

Regardless of technology, these guarantees must hold:

• Process isolation: No access to host resources or other sessions.
• Filesystem isolation: Private storage with quotas.
• Network isolation: Restricted external access per policy.
• Resource limits: Bounded CPU, memory, and I/O consumption.

For onchain services, slashing depends on the Blueprint’s rules and evidence path. For Tangle-managed API mode, isolation failures are handled as product security incidents.

Policy Enforcement

Each sandbox enforces:

• Tool allowlists: Which tools the agent can invoke.
• Domain allowlists: Which external endpoints are reachable.
• Data access policies: What files and secrets are available.
• Budget limits: Token and compute ceilings per session.

Workbench profiles define policies; the runtime enforces them.

For protocol-backed services, the app should also check the service instance policy and operator endpoint before launching a session. A chain record proves the service exists; it does not prove the sandbox is currently ready.

Auditability

Every session produces:

• Event streams: Real-time logs of agent actions.
• Execution metadata: Timing, resource usage, and exit status.
• File snapshots: State of the workspace at key points.

This makes execution reviewable and supports dispute resolution.

Operator Checklist

Before exposing a sandbox endpoint:

1. Run the selected isolation backend locally with the same kernel, container runtime, or microVM assets used in production.
2. Confirm the sandbox cannot read host files, sibling session files, or unapproved secrets.
3. Confirm network policy blocks non-allowlisted destinations.
4. Set CPU, memory, disk, and timeout limits and verify they trigger controlled failures.
5. Capture one successful run and one blocked-policy run in logs that an operator can inspect later.