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 its own virtual machine, not a shared container. On a self-hosted deployment the platform uses Kata Containers on the Cloud Hypervisor, scheduled through a dedicated kata-clh RuntimeClass, so the isolation boundary is the hypervisor rather than the host kernel. The sandbox service builds a per-run filesystem from a content-addressed base image plus a writable overlay, and exposes the run's workspace snapshot to the guest over virtio-fs. The guest has its own kernel, its own filesystem view, and no path back to the host filesystem outside of the snapshot it was given.

This is why a self-hosted cluster cannot be a generic one: the node has to provide nested virtualization and a prepared sandbox runtime before it joins. See Cluster and node requirements.

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 unless a project admin grants it

Sandboxed code has no network access by default. A new project starts with No network access, and the run request carries the none network policy. On Kubernetes, runner Pods are also covered by a deny-all NetworkPolicy named sandbox-run-deny-all, with empty ingress and egress rules.

A project admin can grant network access on the Network access tab of the project's settings:

• No network access: agent code that opens a socket gets no route. This is the default.
• Public internet: agent code can reach any public HTTPS host.
• Allowed hosts only: agent code can reach only the HTTPS hosts the admin lists. A *.example.com entry covers every subdomain of example.com.

When access is granted, the run carries the egress policy and the runner can reach only the platform's egress gateway. The gateway reaches public addresses on TCP port 443 only. Private, loopback, link-local, and carrier-grade NAT address ranges are excluded, so agent code cannot reach hosts on your internal network through it.

Credentials for outside services stay out of agent code:

• A project admin adds a token or key as a credential on the same tab.
• Agent code sees only an environment variable that holds a placeholder.
• When a request matches one of the credential's destinations by host, path, and method, the gateway replaces the placeholder with the real secret.
• The secret is write-only. Nobody can read it back after it is saved.

Every change to a project's network access is recorded in the audit ledger in the config family, and every credential change in the security family, with the acting person. Agents can still reach external systems through platform-side integration calls (Gmail, Linear, an MCP server), which are 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 Workflow's contract using the engineering Details disclosure.

What is not yet a one-click action:

• Re-executing the recorded inputs against the current Workflow 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 Workflow'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.
• Sandboxed code has no network access unless a project admin grants it, either to the public internet or to a listed set of hosts. Every grant and every credential change is recorded in the audit ledger.
• 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 Audit lenses. For the reproducibility side, see /admin/audit/determinism.