Sandboxes and Execution Isolation

The execution contract and its trusted components

A sandbox is a controlled execution environment that restricts an application's permissions and access to resources. Generated code needs the same treatment as other untrusted code. The restriction must exist in the execution system; an instruction asking the program to avoid sensitive files does not prevent access. [1]

A trust boundary separates different assumptions about control or authority. The trusted computing base comprises the hardware, firmware and software relied upon to enforce policy. For execution, that can include the kernel, runtime, management service and credential gateway. The protected assets determine which components belong in this set; AI Security explains the surrounding threat model. [2]

A repository-build service provides a useful execution contract: receive one tenant's source, install dependencies, run tests and return selected changes for review. The harness—the runtime requesting and coordinating execution—needs observable results from this environment. Scheduling and continuation belong to Harness Engineering; executing code and incorporating its changes remain separate operations. [3][4]

Isolation limits where execution can act. Authorization determines whether a particular action on a particular resource is permitted. An allowed connection to a repository service therefore does not itself authorize a push. The control-placement distinction keeps execution restrictions from being mistaken for business approval. [8]

Process, container and virtual machine boundaries

A process is a running program with an address space: the memory addresses it can use. Separate address spaces do not eliminate inherited access. On Linux, fork creates a child with initially copied memory and inherited file descriptors—handles referring to already-open resources. Parent and child can consequently retain access to the same underlying files. [9]

The kernel is the operating-system component that mediates hardware and privileged operations. A container groups processes under operating-system isolation controls while sharing a kernel. A virtual machine runs a guest operating system, including its own kernel, behind a virtualization layer. Its virtual machine monitor, or VMM, manages guest execution and virtual devices. [10]

A VM exit transfers guest execution to host-side handling. Device-heavy workloads can incur repeated servicing costs; CPU work and cached guest operations follow different paths. These differences require workload measurements, not a universal overhead percentage. [14]

Startup optimization also extends beyond the isolation runtime. Modal's 2025 architecture account pairs gVisor with custom scheduling and storage infrastructure. This illustrates why selecting a runtime does not settle image distribution, readiness or fleet behavior. [15]

Operating-system controls and inherited access

A system call is a program's request for a kernel operation. Confinement combines controls over visibility, access, privilege and consumption. These properties are independent: hiding another process from a process listing does not establish that every route to its resources has been denied. [16][17]

seccomp reduces exposed kernel interfaces; it is not a complete filesystem policy. Landlock supplies additional mandatory kernel restrictions that constrained code cannot simply waive. Inspect both supported rights and inherited handles before relying on the resulting policy. [17][19]

Changing the apparent filesystem root with chroot does not close descriptors or change the current working directory. An already-open resource outside that tree can remain reachable. Path presentation and actual authority must therefore be checked separately. [20]

Rootless Docker runs both its daemon—the management service—and containers without host root privileges. User-namespace remapping differs: its daemon retains root privileges. Rootless operation reduces those privileges, but mounts, networking, ordinary host permissions and kernel interfaces still need an explicit contract. [21]

A host Docker socket is a management interface, not an ordinary workspace file. Access to a privileged daemon can permit requests to mount host storage into another container. Restricting the original container's visible paths does not remove authority granted through that socket. [22]

Capabilities, credentials and mediated operations

An object capability is an unforgeable reference that identifies a resource and conveys authority to use it. Naming a resource is insufficient: a caller-supplied pathname does not grant permission to write there. The Confused Deputy explains how a service can accidentally apply its own stronger authority to a caller's request. [23]

Linux capabilities use the same word for a different mechanism: dividing operating-system privileges. Ambient authority means broadly available access, such as access inherited from an execution identity, rather than a narrowly supplied resource reference. Minimizing it makes the workload's usable powers easier to identify. [18][19]

A credential broker is a trusted service that performs authenticated operations for a workload. A useful proposed grant binds trusted execution identity, target resource, permitted operation and validity period. Identity must come from trusted context, not a generated argument. The broker implements grants; AI Security's execution-authority discussion owns the underlying business policy. [24][25]

Cloudflare's Dynamic Workers gateway demonstrates secret withholding: trusted loader code can attach credentials to selected outgoing requests. Its outbound restriction does not disable separately supplied bindings. Every binding therefore remains an independent grant to inspect. [26]

Direct credential delivery exposes the credential to the receiving process. For example, the MCP TypeScript subprocess client filters its default environment, but explicitly supplied environment entries reach the launched server. Filtering defaults cannot protect a secret deliberately passed to untrusted execution. [27]

Credential copies also need lifecycle controls. Environment data can reach child processes; snapshots can retain tokens; logs can preserve secrets after execution ends. Avoid placing broad credentials in workload memory, and exclude tokens from routine diagnostic records. [9][30][31]

Workspace paths and underlying storage

A mount makes storage visible at a filesystem path. A bind mount exposes existing host storage rather than copying it. Writes through a writable bind mount change that underlying storage. [32]

OverlayFS combines lower and upper layers into one view. A write requiring modification of a lower-layer file copies it into the upper layer; the upper copy then takes precedence. This copy-on-write behavior separates shared base files from private changes. [33]

A symbolic link redirects pathname resolution; path traversal uses names such as parent-directory components to reach outside an intended tree. Trusted readers must constrain resolution, not merely check a string prefix. Linux openat2 can require containment beneath a directory and reject symlinks or mount crossings. These checks protect individual opens, not every later processing step. [35]

Device files and management sockets expose operations beyond ordinary file contents. Existing descriptors can preserve access even after a path becomes invisible. The workspace specification must enumerate these grants alongside data paths; access governance determines which data access the environment should permit. [22][19]

Network reachability and service authority

Egress is outbound communication; ingress is incoming communication. A network namespace supplies a separate view of network devices and stacks. Connection filters decide which address-and-port connections may occur. An application proxy receives requests on behalf of another program and can apply checks to their application-level contents. [16][36][26]

Deny outbound communication unless the task requires it, then mediate the necessary paths. Identity-aware connections can help a destination identify the calling workload, as the Tailscale talk proposes. The receiving service must still decide which resource and operation that identity may use. [37][38]

Cloud metadata endpoints expose instance information and potentially service credentials through special network paths. EC2 documents IPv4 and conditionally available IPv6 access, plus token-based IMDSv2 requests. Blocking public Internet access does not establish that these local paths are blocked. Token requirements alone do not exclude arbitrary code that can reach the endpoint. [39]

DNS resolution translates hostnames into addresses; redirects instruct a client to contact another destination. Either can change where a validated request ultimately goes. SSRF prevention guidance therefore addresses destination membership, resolved addresses and redirects together. Server-side request forgery means inducing a service to contact an unintended destination using its own reachability or authority. [40]

A reported repository-fetching exploit illustrates the consequence: changing a repository destination caused a tool to send its Git credentials elsewhere. The failure was in destination and credential handling; it did not require escaping the execution environment. [41]

Network-policy declarations require effective enforcement. Kubernetes NetworkPolicy needs a supporting plugin; ingress and egress are independent, applicable allow rules combine, and policy distribution can lag creation. Changes to established connections are implementation-dependent. Readiness must establish the required restrictions before untrusted work starts, rather than merely confirm that a policy object exists. [36]

Preview servers need separate inbound authentication and tenant routing. Arrakis's port-forwarding example explains connectivity into a guest, not permission to use the exposed service. [42]

An allowed destination can still receive private data. Filesystem and network restrictions must therefore be assessed together, including every granted service interface. Disclosure paths explains how private-data access, attacker-controlled content and external communication can combine. [8]

Resource budgets and limit outcomes

A control group, or cgroup, groups Linux processes for hierarchical resource accounting and enforcement. New children inherit membership, but moving a parent later does not move its existing descendants. Establish the execution group before setup begins, and verify that required controllers are enabled. [43]

Resident memory occupies physical memory; virtual address space describes addresses a process can map. An inode represents a filesystem object, so many tiny files can exhaust object capacity before byte capacity. A quota must apply to the execution's intended user, group or project identity on a supporting filesystem. [44][46]

Sleeping or waiting for a service consumes elapsed time without equivalent CPU consumption. An external deadline therefore serves a different purpose from CPU limits. For example, systemd separates startup, active-runtime and stopping timeouts; unit types and permitted deadline extensions affect whether a configured duration is truly a hard bound. [45]

Output bytes, network volume and remote-operation spending require separate enforcement contracts. A local CPU ceiling cannot cap charges from permitted API calls. Specify the measuring component, concurrent-request accounting and overflow response before claiming a bound; retries can multiply downstream work even after the original caller stops waiting. [47]

Per-execution ceilings also differ from service capacity. Admission control decides whether another execution may begin; supervision and cleanup require capacity of their own. Resource abuse supplies this availability context. Resource configurations affect task outcomes, so guaranteed allocations, hard limits and time budgets belong in execution records. [48]

Environment creation and execution readiness

An image packages executable software, filesystem contents and configuration for environment creation. An image digest identifies content, whereas a tag can be reassigned. Recording a requested tag does not establish which image actually ran. [49]

Dependency preparation is execution. npm's version 8 documentation describes installation lifecycle scripts and Git dependencies whose prepare scripts run before packaging. This versioned example establishes the ordering requirement: confinement must precede enabled hooks, not begin only when the advertised application command starts. [50]

The creation gate should establish execution identity, private storage, effective access restrictions and budgets before admitting setup. Missing enforcement is a no-execution outcome. Readiness then includes the required tools and policy checks, not simply a running process. This is a proposed integration contract whose components must be verified together. [5]

Image reuse, dependency caching and memory snapshots preserve different state. A memory snapshot can duplicate machine identifiers, randomness and cryptographic tokens. Repeated restoration therefore needs an explicit uniqueness mechanism. Giving a clone a new external name does not by itself refresh the state inside it. [30]

Initialization captured before tenant inputs arrive avoids capturing those inputs. A later snapshot can retain tenant data in both memory and storage. Identity refresh addresses duplicated identity; it does not erase arbitrary retained contents. A clean base and fresh private writable state provide a clearer starting contract than undocumented reuse. [30][51]

Record the actual image, runtime, policy, grants, limits, dependency inputs and cache conditions. Reproducing these conditions reduces environmental variation but does not freeze remote repositories or guarantee deterministic program behavior. Execution provenance explains how to retain this context without indiscriminate data capture. [51]

Termination, cleanup and environment reuse

A caller timeout means the caller stopped waiting. A cancellation request asks execution to stop. Neither establishes observed termination. Temporal's activity documentation illustrates the distinction: cancellation is cooperative, and a timed-out attempt can continue. The execution service needs independent evidence about the actual unit it controls. [52]

Stopping only the main process can leave descendants active. Whole-unit stopping must target the execution's group. Linux cgroup.kill targets a subtree, including concurrent forks; cgroup.events can report whether live processes remain. Process absence still says nothing about retained storage or credentials. [43]

An execution lease is a proposed time-bounded permission to remain active. Its enforcer must survive loss of the requesting controller. Manager timeouts are one building block, not evidence of complete orphan discovery, storage cleanup or authoritative status reporting. Those failure paths require an implementation and tests. [45]

Cleanup also releases references and retained resources. A namespace can survive its last process through an open descriptor or mount reference. Network-policy changes may leave established connections intact. Destruction therefore needs checks appropriate to storage, references, connectivity and authority, beyond a process exit code. [16][36]

Use finally-style cleanup for ordinary completion and exceptions, plus maximum lifetimes for abandonment. Neither can establish cleanup after every controller failure. Return exit reason, termination evidence and cleanup outcome separately; an unresolved cleanup state must remain unavailable for reassignment. [53]

Pooling trades repeated initialization for a reset obligation. Before reassignment, establish that processes, memory, writable storage, credentials, connections and caches cannot expose prior-tenant state. A successful task is not reset evidence. When reset is unverified, creation from the recorded clean baseline is the defensible alternative; continuation policy remains in Harness Engineering. [51][30]

Artifact export and retained copies

Artifacts are retained outputs: files, patches, reports and logs. A proposed export manifest names selected relative paths, their execution origin, size/count limits and intended use. Selection separates useful results from disposable workspace contents; recording origin does not validate those results. [7][54]

Trusted exporters must resolve paths under an approved directory. openat2 can reject symlinks throughout a path and prevent mount crossings; O_NOFOLLOW only addresses the final component. These constraints do not validate contents or secure a later multi-step export against every race. [35]

Archive extraction adds link, special-file and resource risks. Use fresh destinations, reject unnecessary links, limit sizes and counts, and handle concurrent modification. Extraction filters are partial defenses; failed extraction can leave partial output. [55]

Program-reported success, process exit status, accepted export and verified correctness are different observations. A patch can export successfully and still fail tests. Verification in a separate environment receives only transferred artifacts; verification inside the workload environment may inherit modified tools and state. [54][56]

Parsing, rendering or executing an exported artifact opens another exposure. PatchPilot illustrates a useful authority split: the agent edits local files, while a deterministic controller handles repository writes and review handoff. Basic file checks support that split but do not establish code safety. [57]

Logs are outputs too. Exclude access tokens and other unnecessary secrets, sanitize untrusted event fields, restrict readers and define disposal. Exported files, snapshots, caches and telemetry can outlive the workspace. Lifecycle fulfillment across derivatives explains why deletion at one location does not establish deletion everywhere. [31][7]

Snapshots, rollback and external effects

A checkpoint is a saved recovery point; a snapshot captures specified environment state. Disk checkpoints can preserve installed packages and files for restoration on another node. Incremental snapshots retain changes between checkpoints, reducing repeated copying while making restoration depend on the saved lineage. [58][59]

Running-state recovery needs more than files. Arrakis describes pausing the guest while capturing memory and writable filesystem state, then resuming. That coordinated capture has broader scope than disk persistence alone. [60]

An uncertain outcome occurs when an operation may have completed without confirmed acknowledgment. A remote record can change before the response disappears. Restoring local state neither reverses that change nor supplies the missing observation. Retain the operation identity and reconcile—compare local expectations with authoritative service state—before deciding what further action is needed. [52]

An idempotent retry repeats one logical operation without duplicating its intended effect, when the receiving service enforces that contract. A caller-generated key in a local log is insufficient. A compensating action is a separately authorized corrective operation, not restoration of a sandbox snapshot. Uncertain effects and safe retries develops the recovery mechanics. [61]

Boundary failures and remaining containment

An escape crosses an intended isolation boundary through a failure in implementation or enforcement. A crash inside the boundary does not establish escape: the relevant evidence is an effect outside the protected region. The V8 discussion illustrates this distinction without supplying a container-escape mechanism. [62]

The attack surface is the set of interfaces an attacker can influence. Memory-safe VMM code and narrowly jailed device backends can reduce exposure. Operators still need to maintain the monitor and guest and host kernels. [64][10]

Blast radius describes the resources and effects reachable after compromise. PatchPilot's production account identifies host Docker access as a dangerous grant despite surrounding sandboxing. Separating repository-write credentials into trusted orchestration limits direct agent actions, while leaving generated changes subject to downstream review. [65][57]

Remaining controls help only while their enforcers remain trustworthy. A host supervisor can stop a compromised workload; a supervisor controlled by a compromised host cannot independently establish host safety. Linux process-memory access rules illustrate that the host kernel controls inspection permissions. Sandbox placement does not establish confidentiality against compromise of that same kernel. [66]

Residual risk is the exposure remaining after controls. Shared-hardware side channels—information leakage through shared resource behavior—are one concern beyond ordinary access checks. gVisor explicitly leaves hardware side-channel defenses to the host and platform. Stronger execution boundaries therefore need stated assumptions rather than claims of immunity. [12]

Stopping computation, cutting connectivity and invalidating credentials address different future effects. None recalls data already disclosed or proves that restoration is safe. Containment and verified restoration owns incident coordination and the evidence needed before resuming ordinary operation. [63][28]

Boundary evidence and workload-based selection

Compare execution designs using the same repository, required tools, access contract and retained output. Keep environment failures distinct from patch failures. SWE-bench's evaluation reports distinguish unresolved tasks from missing results and ambiguous infrastructure-versus-patch failures; a missing result is not evidence that a patch was tested and failed. [67]

Use a separate, narrowly privileged verifier where independent observation is required. It should read authoritative evidence without gaining mutation or permission-granting powers. A passing check supports its tested property and configuration; unavailable observations remain unavailable. Controlled offline comparisons explains how to keep comparison conditions interpretable. [70]

A cold start creates an environment without a running instance to reuse. Warm reuse retains initialized state. Tail latency describes the slower portion of a latency distribution; noisy-neighbor interference is delay or failure caused by competing workloads. Measure readiness, execution, memory use, interference, teardown and cleanup failures under stated concurrency and resource conditions. [48][67]

Guest boot and useful task readiness are different endpoints. Firecracker's historical evaluation measured startup to guest init under specified minimal configurations; it did not include application dependency installation. Preserve measurement boundaries and distributions before comparing those numbers with an interactive build service. [10]

Startup techniques remove different work. Content-addressed storage deduplicates image blobs; lazy loading avoids unused reads but can leave sequential access delays. Prefetching anticipates reads from earlier runs. Memory restoration can bypass repeated initialization. Modal's account demonstrates these complementary mechanisms without establishing a universal speed ranking. [71][72][73]

Selection requires compatible functionality, demonstrated enforcement and acceptable lifecycle costs together. Extra resource headroom can prevent infrastructure failures, but can also enable different solution strategies. Record both guarantees and hard limits, and retain the execution provenance needed to explain the result. [48]

Open questions

1. 01

   Verified reuse remains difficult because useful initialization and tenant state can occupy the same memory or storage. Progress requires reset tests that detect retained data and duplicated authority across failure paths, not merely successful startup under a new environment name. [30]

2. 02

   Revocation needs observable completion when external services are unavailable. The unresolved design problem is bounding continued credential use while invalidation is delayed; progress would include outage tests and an explicit maximum exposure period backed by service behavior. [29]

3. 03

   Execution budgets remain fragmented across local resources and remote operations. Concurrent calls and retries make a single hard spending bound difficult. Progress would demonstrate shared accounting, defined overflow behavior and bounded in-flight exposure during failures. [47]

4. 04

   Startup optimization needs comparisons that include setup and retained-state constraints. Lazy reads and restored initialization move costs to different phases. Progress would report matched readiness and cleanup distributions for clean creation and pre-tenant snapshots, including changing dependency access patterns. [72][73]