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.

gVisor adds an additional isolation layer by intercepting system calls through a user-space kernel. This limits attack surface and is suitable for higher-security workloads where container escapes are a concern.

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.

Operators declare supported isolation technologies. Customers specify requirements when requesting services.

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.

Policies are defined in workbench profiles and enforced at the runtime level.

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 when issues arise.

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.