Safe execution and isolation

A regulated workload cannot tolerate a process that runs straight against production data with ambient network reach and silent overwrites. Finance teams running close-period workflows, manufacturing teams whose MES data underpins SOX inventory assertions, and operations teams handling sensitive customer records all share the same precondition: agent work must be isolated, reviewable, and recoverable before it touches a system of record. This article explains how the platform enforces that, and where the enforcement is partial today.

Audience: IT (the enabler) and risk and compliance reviewers

Isolated by default

Every sandboxed run executes inside a Firecracker microVM, the same isolation primitive used in AWS Lambda and Fargate. The sandbox service builds a per-run rootfs from a content-addressed base image plus a writable overlay, mounts the run's snapshot manifest into /workspace, and runs the agent's command inside the jailer (AS_SANDBOX_FIRECRACKER_JAILER_PATH and friends in apps/sandbox/). The VM has its own kernel, its own filesystem view, and no path back to the host filesystem outside of the snapshot it was given.

Two consequences for governance:

• The sandbox cannot see other tenants. The execution principal is bound per run, and every blob, snapshot, and volume read happens under that principal's RLS context.
• The sandbox cannot see secrets the agent did not need. There is no shared mount of platform credentials into the guest. Tools that need credentials receive scoped tokens through the run request, not through the filesystem.

No network access today

The sandbox's NetworkPolicy enum has two values, none and egress, and the Firecracker backend explicitly rejects anything other than none:

if request.network != NetworkPolicy.none:
    raise SandboxBackendError("firecracker backend does not support network access yet")

Every call site in the platform sets network=NetworkPolicy.none. Agent code that tries to open a socket from inside the VM gets no route. This is stricter than Marketing's "unless explicitly granted" suggests: there is no admin toggle to grant egress today, and no allowlist UI. If an agent needs to reach an external system, it goes through a platform-side integration call (Gmail, Stripe, Linear, an MCP server), which is recorded in the audit ledger and gated by the credential's binding.

Snapshots make actions replayable, replay is partial

Every sandboxed run starts from a specific snapshot of the workspace (a content-addressed manifest of file paths, sha256 digests, sizes, and modes) and ends by emitting a DeltaBundle (add, modify, delete entries plus a tar.zst archive of bytes). The platform commits the bundle to a draft volume so the before-state, the after-state, and the exact bytes produced are all recoverable. The audit ledger entry for a sandbox call records the snapshot id, the command, the arguments, the tool output, and the resulting delta.

What you can do today:

• Open the run in /audit?group=<group_id> and inspect the snapshot id, the file changes, and the tool stdout in the Engineering lens.
• Reconstruct the input by reading the snapshot from the API.
• Verify a structured output against the Runbook's contract using the engineering Details disclosure.

What is not yet a one-click action:

• Re-executing the recorded inputs against the published Runbook from the audit detail page. The replay endpoint is on the roadmap, tracked alongside the determinism gap. Today, re-running means creating a new work item with the same input through the App's normal trigger surface.

See /admin/audit/determinism for the deterministic-structure guarantees that make replay meaningful and for the limits on free-form prose.

Drafts protect live data

Agent file changes do not land directly on the project. Each sandbox run commits its delta into a draft volume initialized from the project's head snapshot, and the draft stays there until a human (or a permitted agent path) applies it. The review surface is RunReviewDiffEditor.tsx, which renders a side-by-side or inline diff of every changed file. The apply payload is one of three modes:

• accept_all: every reviewable change applies in one commit.
• accept_selected: only the paths the reviewer ticked apply.
• reject_all: nothing applies, the draft is discarded.

Until one of these three actions runs, the project's live volume head does not move. Concurrent agent runs against the same project each get their own draft; one agent cannot stomp another's pending review.

Safe concurrent work

Volumes use optimistic head-pointer commits. Every commit declares its base snapshot id, and the VFS rejects the commit if the volume head has moved (VolumeConflictError). Three merge strategies decide what happens when a conflict surfaces:

• strict: the commit fails immediately. Used for explicit author commits where surprise is not acceptable.
• rebase_if_disjoint: if the two commits touch disjoint paths, the platform rebases automatically. Two agents editing different files concurrently will both land cleanly.
• conflict_copy: when paths overlap, the incoming change lands as a sibling under a conflict path rather than overwriting. Nothing is silently lost.

The product never silently overwrites. The non-negotiable invariant: the VFS layer enforces correctness, the higher layer decides policy, and conflicts are loud.

Where this leaves you

• For SOX, manufacturing operational data integrity, and customer record protection, the isolation, draft, and concurrency model give you a defensible "nothing touched production without review" narrative today.
• The "no network by default" claim is currently "no network at all". If your control narrative depends on a documented egress allowlist, flag it as an open ask.
• The "replay any action" claim resolves to "every action is recorded with the inputs, the bytes, and the deltas needed to replay it"; the one-click replay button is not shipped yet.

For the recording side, see /admin/audit/dual-lens. For the reproducibility side, see /admin/audit/determinism.