Part I — The execution contract
Bounded execution, not safe code
A sandbox is a controlled execution environment that restricts an untrusted workload’s permissions and access to resources. “Untrusted” describes the assumptions applied to the workload, not a judgment about its author: generated code, downloaded dependencies, user programs, and ordinary buggy software can all receive the same treatment. The purpose is to limit the blast radius—the assets and operations reachable if the workload behaves unexpectedly or maliciously. This chapter begins where AI Security’s isolation boundary leaves off: with the mechanisms that make those limits real.
The contract
A useful sandbox contract names five things. First are the protected assets: host files, credentials, neighboring tenants, internal services, and shared capacity. Second are permitted effects, such as reading one input, writing scratch files, and exporting one result. Third is the trust boundary, where identities, permissions, or validation assumptions change. Fourth is the trusted computing base (TCB): every hardware, firmware, and software component whose correct operation is required to enforce the policy. Finally come the residual assumptions, including kernel, runtime, virtual-machine monitor, management-plane, and hardware defects that could defeat the boundary. A mount, broker, proxy, credential, or export path changes this contract even if the product still calls the environment a sandbox.
| Question | Example answer | Required evidence |
|---|---|---|
| What may enter? | One immutable program image and one read-only input | Artifact identity and effective mount configuration |
| What may leave? | One selected artifact; no direct network traffic | Export record and denied-egress test |
| What may be consumed? | Bounded CPU, memory, processes, storage, output, and elapsed time | Effective limits plus exhaustion tests |
| Whose authority applies? | A tenant-bound workload identity with one brokered operation | Authorization decision at the protected service |
| What survives? | Exported artifact and minimal audit receipt; scratch is destroyed | Collection, teardown, and retention evidence |
| What if isolation fails? | No standing credentials; restricted host and network reach | Attack-path review and incident drill |
A small boundary walk
Consider a generated program that transforms a supplied CSV into a summary. Its ordinary success path is small, but its possible reach is not: package installation can execute code before the intended command, writable host mounts change real files, inherited credentials enable remote calls, and unlimited output or child processes consume shared capacity. The sandbox contract is the difference between “run this program” and “read this identified input, execute within these limits, contact no destination, and export only this identified result.”
From proposal to workload
A language model does not execute a tool merely by producing its name and arguments. It proposes an invocation; application code interprets that proposal and performs the effect. That distinction creates an enforcement point. Structured Outputs’ controlled dispatcher validates and resolves an accepted request, but an execution service must still create the environment that will run the workload. The surrounding agent harness or runtime coordinates model access, tools, task state, cancellation, and verification; its broader scheduling and recovery responsibilities belong in Agent Runtimes and Harness Engineering.
The broker’s responsibility
The security-sensitive mediator is the execution broker or supervisor. Given an authenticated and authorized request, it selects an immutable workload artifact, assigns the workload and tenant identities, attaches filesystem and network policy, applies resource limits, creates the environment, streams bounded observations, handles cancellation, collects declared outputs, and destroys resources it owns. The Open Container Initiative lifecycle usefully separates create from start: configured properties must be applied before the user program runs, and failure to apply them must prevent creation rather than silently produce a weaker environment. Deletion removes resources created for the container without deleting unrelated resources supplied to it.
This division prevents three claims from collapsing into one. Schema validity says the request has an accepted representation. Authorization says the requester may ask for the named operation under current policy. Isolation says the resulting workload can exercise only the attached powers. A successful check at one boundary cannot stand in for the next.
Part II — Why boundaries accumulated
Protection mechanisms in parallel
Computer protection has several targets. Machine virtualization separates computing environments on shared hardware; privilege mechanisms constrain which procedures may enter more powerful code.
Access control asks whether a component may reach an object. Information confinement also asks where legitimately received data can leave or remain after execution.
Delegated administration and object-specific capabilities limit different kinds of authority. Neither follows automatically from a separate address space or a restricted pathname root.
The chronology follows these complementary lineages. A modern deployment can combine process policy, machine separation, explicit interfaces and egress enforcement because each controls different paths.
Complementary protection mechanisms
July 1968 — availabilityCP/67Machine virtualization: Separate computing environments become available to System/360 Model 67 users.
Contributors: IBM Cambridge Scientific Center
What changed: Availability followed completion in fall 1967 and an earlier modified Model 40 experiment. This lineage separates computing environments on shared hardware.
October 1971 — paperMultics protection ringsProcedure privilege: Controlled gates mediate entry into more privileged procedures.
Contributors: Schroeder and Saltzer
What changed: The paper describes ordered protection domains within a process. Procedure-level privilege control is a different boundary from a container or virtual machine.
August 2, 1972 — announcementVM/370Machine virtualization: IBM announces its virtual-machine product for System/370.
Contributors: IBM
What changed: This announcement belongs to the machine-virtualization lineage; it is not the invention date of separate virtual computing environments.
October 1973 — paperLampson’s confinement paperInformation confinement: Protecting access does not prevent leakage of legitimately received information.
Contributors: Lampson
What changed: A Note on the Confinement Problem examines retained memory, files, messages, accounting information and shared-system behavior. It extends the protection question to information exits and state between calls.
May 2000 — paperFreeBSD jailsDelegated administration: Delegate familiar UNIX administration while bounding host and neighbor access.
Contributors: Kamp and Watson
What changed: Jails: Confining the Omnipotent Root describes the implementation included in FreeBSD 4.0-RELEASE. Unlike pathname-only confinement, jails also restrict privileged operations and process and networking scope.
2003 — paperXenGuest interfaces: A modified guest-machine interface preserves unchanged application binaries.
Contributors: Xen paper team
What changed: Xen and the Art of Virtualization addresses sharing commodity servers among mutually untrusting users. Guest operating systems require modification, and whole operating systems retain initialization and resource costs beyond ordinary processes.
August 11, 2010 — presentationCapsicumObject capabilities: Remove global namespaces and delegate descriptors with narrowed rights.
Contributors: Watson, Anderson, Laurie and Kennaway
What changed: Presented at USENIX Security, Capsicum adapts object-specific capabilities to UNIX. Its prototype also closes non-delegated descriptors and scrubs process state because entering capability mode alone does not remove previously acquired authority.
November 26, 2018 — announcementFirecrackerReduced device models: A reduced device model brings KVM microVMs to short-lived serverless workloads.
Contributors: AWS
What changed: The announcement describes a design derived from crosvm and already powering Lambda and Fargate. It retains a guest kernel while narrowing the virtual-machine monitor’s supported surface.
Part III — Choose the execution boundary
What a process isolates
An ordinary process normally has its own virtual address space: its writes do not directly become writes into another process’s private memory. That is a useful boundary, but not an authority boundary. A system call enters the operating-system kernel to request privileged work such as opening a file, creating a process, or sending network traffic. The kernel’s decision depends on credentials, namespaces, handles, and policy—not on the fact that the caller has private memory. Schroeder and Saltzer's Multics protection-rings paper (October 1971) addressed procedure privileges within a process: controlled gates permitted entry to more privileged rings. This was a different boundary from separating machines.
Memory changes; handles survive
Process creation preserves more authority than its visual separation suggests. On Linux, fork gives the child a separate memory space initialized from the parent, but inherited file descriptors refer to the same underlying open-file descriptions. execve replaces the running program and initializes new program memory, yet normally retains real identities, supplementary groups, the explicitly supplied environment, and descriptors not marked close-on-exec. A process can therefore inherit a database socket, writable file, secret-bearing environment value, or management channel even after its code and memory image change.
| Property | Created or inherited? | Separate control |
|---|---|---|
| Virtual address space | Separate after fork; replaced by execve | Memory mappings and debugger/trace policy |
| User and group authority | Largely inherited | Dedicated identity, privilege drop, user namespace |
| Open descriptors | Normally inherited | Close-on-exec and explicit descriptor allowlist |
| Filesystem reach | Not removed by process creation | Mount policy, Landlock, AppArmor, brokered access |
| Kernel interface | Shared kernel | seccomp and reduced Linux capabilities |
| Resource use | Consumes shared host capacity | rlimits, cgroups, deadlines, quotas |
Layered process confinement
Additional controls narrow different channels. Linux capabilities divide powers historically associated with root; removing one does not remove ordinary permissions or authority held through open objects. Landlock can add unprivileged restrictions over resource objects for a thread and its descendants, but files opened before confinement remain usable. AppArmor applies loaded profiles to tasks; enabling the module without loading a profile leaves tasks unconfined by AppArmor. Seccomp filters syscall numbers and argument values, but cannot dereference a pointer to inspect a pathname, and its own documentation distinguishes interface reduction from a complete sandbox. Activation order and inherited authority are therefore part of the contract.
Containers restrict the view
A container is a group of ordinary operating-system processes given restricted views and policies. Linux namespaces can separate mount points, process identifiers, network stacks, user and group IDs, and other resource views. Cgroups organize processes hierarchically and control consumption. Images provide executable files and configuration. None of these facts gives the container a private kernel: its processes still invoke the host kernel. This is why an image is packaging, while the effective namespace, mount, credential, syscall, mandatory-access, and resource policies determine isolation. FreeBSD jails, described by Kamp and Watson in 2000, delegated familiar UNIX administration while bounding a tenant's host and neighbor reach.
The filesystem view is assembled, not copied by definition. A bind mount exposes a host path inside the container and is writable by default in Docker; read-only mode blocks writes through that mount but is not a snapshot and does not prove that another path cannot reach the same storage. The Docker daemon is a separate management boundary: a trusted client can ask a privileged daemon to mount the host root into a container. Giving hostile code the host daemon socket can therefore defeat a surrounding container boundary without exploiting the kernel. Rootless mode reduces this management authority by running both daemon and containers without host root privileges, although mounts, networking, kernel interfaces, and ordinary user permissions still require review. By itself, chroot changes pathname resolution without clearing the current directory or open descriptors; it is not a complete sandbox.
Bootstrap belongs to the TCB
Controls also fail during trusted setup. A 2024 runc advisory described descriptor leaks and working-directory validation failures that could leave a container process able to access the host filesystem. The defect lay in runtime bootstrap, not in a deliberately permitted workload operation. The lesson is broader than that patched version: container isolation depends on the runtime and its initialization path as well as the final process policy.
Containers remain valuable when compatibility, startup behavior, density, and ordinary Linux tooling matter. Mature designs layer namespaces with capabilities, seccomp, mandatory-access controls, rootless management where feasible, immutable artifact identity, explicit mounts, host-enforced cgroups, and network policy. The defensible claim is not “containers are safe” or “containers are unsafe,” but that a named configuration constrains named paths while retaining a shared-kernel assumption.
Guest kernels and microVMs
A virtual machine places a guest operating system behind a hypervisor or virtual-machine monitor (VMM). The guest receives virtual CPUs, memory, storage, and networking; the VMM and host mediate access to real resources. Compromising the guest kernel need not grant authority over the host kernel. This removes the shared host-kernel interface from the workload’s direct path, but makes the VMM, the virtualization layer (such as Linux’s Kernel-based Virtual Machine, or KVM), virtual-device backends, management interfaces, host networking and storage, firmware, and hardware part of the security story. IBM's CP/67 made separate computing environments available in July 1968; VM/370 followed as a product announcement in August 1972.
A microVM narrows the monitor and device model for workloads that need a guest kernel without the breadth of a general-purpose machine emulator. “Micro” describes the monitor’s footprint and supported surface, not necessarily the guest program. Smaller, memory-safe VMM implementations and separately jailed device backends can reduce exploitable code and limit what one compromised backend can reach. They do not make escape impossible. Firecracker, announced by AWS in November 2018 for short-lived serverless workloads, retains a guest kernel behind a reduced device model. Its production guidance leaves guest-traffic filtering to the host and recommends explicit host firewall policy, hardware maintenance, and one tenant’s workload per Firecracker process.
The performance tradeoff depends on the path. Guest computation can remain in a hardware virtualization context, while disk, network, and other device operations require host-side servicing through VM exits and resumes. Virtio provides virtualization-aware device interfaces, but frequent boundary crossings still matter. A CPU-heavy transformation and an import-heavy or I/O-heavy build can therefore experience different costs. Likewise, memory reclamation, GPU access, and snapshot support depend on the concrete VMM, guest, drivers, and host arrangement rather than on the word microVM. The Xen paper (2003) explored another interface tradeoff: modified guest operating systems with unchanged application binaries.
Integrations can deliberately weaken separation. NIST’s virtualization guidance calls out shared disks, clipboards, guest tools, and management channels. Firecracker’s virtio-pmem documentation separately warns that sharing one backing file across VMs can create a cross-VM side channel and that flush-heavy guests can force host I/O, motivating operation and bandwidth limits. The boundary must therefore describe virtual devices and host resources, not merely draw a box around the guest kernel.
Compose controls for the workload
Choose an isolation boundary from the workload outward. Ask what code must run, which operating-system interfaces it needs, whether it installs packages or starts subprocesses, which devices it requires, what an escape would expose, how quickly environments must become task-ready, and who can patch and operate the trusted components. Generated tool functions with a narrow host interface may fit an isolate or WebAssembly runtime. Native builds needing a broad Linux environment may require a container or microVM. One product can use different boundaries for different steps. An application kernel offers another boundary. In gVisor, the Sentry services application system calls in user space through a restricted host interface; the Gofer separately mediates filesystem access. Unlike seccomp, it implements calls rather than just filtering them. Unlike a VM, it uses a user-space application kernel, not a separate guest kernel. The host kernel remains trusted.
| Boundary | Primary separation | Useful fit | Material remaining dependency |
|---|---|---|---|
| Process plus OS policy | Address space, identity and selected kernel interfaces | Known native program with narrow host needs | Shared kernel and inherited authority |
| Container | Namespace views, mounts, credentials and host-enforced limits | Broad Linux compatibility and packaging | Shared host kernel and runtime/daemon |
| Application kernel such as gVisor | User-space implementation of much of the Linux API | Linux workloads where reduced host-syscall exposure is valuable | Sentry, filesystem mediator, host kernel and compatibility subset |
| VM or microVM | Guest kernel behind VMM/hypervisor | Hostile native workloads or stronger tenant separation | VMM, devices, KVM, host integrations and management plane |
| WebAssembly/WASI | Checked runtime memory and explicit linked interfaces | Portable modules with constrained host operations | Runtime defects and authority of imported interfaces |
Independence matters
Layers help only when they independently remove, mediate, or contain an attack path. Seccomp inside a container can reduce the shared-kernel interface. Putting the container in a microVM can add a guest-kernel boundary. A host-side broker can keep a credential outside both. Default-deny egress can reduce the consequences of readable data. Conversely, two filters at the same bypassable layer may add complexity without changing reachable authority. Defense in depth is an attack-path argument, not a layer count.
Part IV — Control what the workload reaches
Filesystem views and exports
A clear filesystem contract separates provenance and lifetime. An immutable runtime or base image supplies tools. Identified inputs are mounted read-only. A per-run writable layer holds scratch changes. Persistent stores remain outside the environment, and only selected outputs cross into them. OverlayFS can present a lower read-only layer and an upper writable layer as one tree; opening a lower file for write can copy it into the upper layer, after which operations use the private copy. Arrakis applies this pattern with a shared read-only root and per-sandbox writable overlay.
Trusted path handling
The apparent tree is not the whole boundary. Bind mounts expose live storage. Open descriptors can retain access acquired before confinement. Symbolic links, parent traversal, and mount crossings can redirect trusted exporters or extractors. Linux openat2 lets a trusted component constrain an individual path resolution beneath or inside a supplied directory, disallow symlinks, or prevent crossing mount points. Archive extraction needs additional filename, link, object-count, and size checks and can leave partial output after failure.
Storage limits are also multidimensional. Filesystem quotas can independently restrict allocated blocks and inodes, so one huge file and millions of tiny files are separate exhaustion paths. Read-only inputs, private scratch, and explicit export simplify accounting, but teardown still removes only resources owned by the environment. It does not recall copied bytes, delete an uploaded artifact, invalidate a snapshot, or undo a remote write.
Network paths and egress
Egress is outbound network traffic. A meaningful default-deny policy covers every usable path, not merely the public web. Relevant destinations include loopback and host services, private address ranges, link-local metadata services, internal networks, explicitly supplied bindings, and external services. Protocols, ports, DNS, redirects, existing connections, UDP, and host-browser handoffs can each have distinct enforcement behavior. Disabling public Internet access does not by itself block a cloud metadata endpoint or a host-local daemon.
Mediated outbound authority
A host gateway or enforcement proxy can mediate outbound requests outside the workload. Cloudflare Dynamic Workers, for example, can make workload fetch and connect fail while retaining explicitly supplied bindings, or route them through a loader Worker that inspects and forwards selected requests. A credential-injection gateway can keep a provider token in trusted code and attach it only to matching approved requests. Docker’s documented sandbox architecture similarly uses forward proxying or transparent interception and separately blocks direct external UDP and ICMP. The decisive property is that ignoring proxy configuration does not reveal an unrestricted alternative route.
The destination can change
Destination policy must survive indirection. OWASP’s server-side request forgery guidance distinguishes syntax validation from membership in a permitted destination set and warns that redirects and DNS resolution can move a request after an initial hostname check. One reported agent-tool failure changed a private-repository destination string so a server sent Git credentials to an attacker-controlled endpoint. Network controls and application authorization are complementary: an allowed service can still receive impermissible data or an unauthorized operation.
A proxy is mandatory only when bypass routes are denied
Solid arrows carry request, response or binding data. Dashed arrows are DNS exchanges. Resolve and check the effective destination before forwarding; reject a redirect or repeat destination and credential-scope checks.
Policy records should identify the sandbox, destination, outbound path, matching rule, and decision reason. They support investigation but only for their covered surface. Docker’s documented network-policy log, for example, does not include filesystem mount decisions. Observability is evidence about an enforcement path, not evidence that every path was mediated.
Identity, authority, and capabilities
A sandboxed action can involve several principals: the requester, represented user or service, tenant, agent runtime, workload, broker, and downstream service. Local Unix identity determines some operating-system decisions. It does not determine what a cloud token may do. The protected service must still authorize the actor, action, resource, represented subject, and current conditions. Privacy and Data Governance develops the governing principles: least privilege, complete mediation, and fail-safe defaults. Here they become runtime mechanisms outside model-controlled behavior.
A capability joins designation and authority: it identifies a resource or operation and grants its holder permission to use it. This differs from a Linux capability such as CAP_DAC_OVERRIDE, which is one unit of operating-system privilege and may apply broadly. Capsicum, presented by Watson, Anderson, Laurie and Kennaway in 2010, removed global namespaces in capability mode and delegated file descriptors with narrowed rights. Existing descriptors and process state still needed cleanup. WebAssembly System Interface (WASI) similarly represents runtime resources through per-instance handle tables and explicitly linked interfaces. In application systems, a short-lived token for one resource action or a broker stub exposing one checked method can play a related role.
Broker the operation
The safer design is often to keep the reusable credential outside the sandbox. The workload receives a narrow interface such as queryCustomerDatabase(customerId, fields); trusted code validates the method, arguments, tenant scope, and current policy before using its own credential. Cloudflare’s generated-code example exposes database and logging bindings but no general network or secret access. The same principle supports short-lived executor capabilities bound to actor, subject, audience, plan, and lifetime rather than standing credentials.
Lifecycle of authority
A secret placed in an environment variable, mounted file, open descriptor, or ordinary process memory should generally be treated as readable by hostile code in that boundary. A narrower token remains a reusable bearer credential unless its receiving service enforces its scope and lifetime. Expiry is also not identical to successful revocation: Vault documents a failure case in which an expired dynamic database credential could not be revoked because the database was unavailable. Receipts should therefore preserve issuance, use, expiry, revocation attempt, and authoritative downstream status separately.
Part V — Bound time, state, and tenants
Independent resource ceilings
Untrusted execution can deny service without escaping. An infinite loop consumes scheduled CPU; allocation pressure consumes memory; a fork bomb consumes process identifiers; tiny files consume inodes; large files consume blocks; output can fill pipes or memory; device traffic can saturate I/O; and many individually cheap API calls can exhaust a remote quota. Each resource needs a meter, an enforcement point, a limit, an observable failure mode, and a cleanup check.
A resource ledger
| Resource | Example enforcer | What the limit means | Failure or response |
|---|---|---|---|
| CPU | cpu.max, RLIMIT_CPU | Scheduled CPU per period or accumulated CPU seconds | Throttling, signal, then possible kill |
| Elapsed time | External service manager | Time in active lifecycle state | Termination request and failed state |
| Memory | memory.high, memory.max, RLIMIT_AS | Pressure threshold, cgroup ceiling, or virtual address space | Reclaim/throttle, allocation failure, or group OOM kill |
| Processes | pids.max | Maximum tasks in a cgroup subtree | New process creation rejected |
| Descriptors | RLIMIT_NOFILE | Open descriptors per process | Open or duplication fails |
| Storage | Block and inode quotas, RLIMIT_FSIZE | Total bytes, object count, or one file’s growth | Write failure, signal, or quota denial |
| I/O and network | io.max, gateway limits | Device throughput, operations, connections, or requests | Throttle or rejection |
| Output | Bounded stream collector | Retained bytes and pipe-drain policy | Truncation, spill, or controlled failure |
Name the semantics
A reservation promises capacity; a quota bounds an allocation or entitlement; throttling slows consumption; termination stops execution. They produce different observations. Likewise, CPU seconds are not elapsed time, virtual address space is not resident memory, and an individual file-size limit is not total workspace storage. Values must follow workload measurements and consequences rather than a universal “safe” preset.
Stopping one process is not necessarily stopping its descendants. Cgroup-wide termination and PID-namespace supervision can address process trees; systemd’s KillMode=control-group targets remaining processes and can escalate to SIGKILL, whereas process-only mode can leave children alive. A stopped process group still says nothing about retained files, credentials, queued work, or remote effects.
Lifecycle, snapshots, and external effects
An environment lifecycle should make ownership and terminal conditions explicit. A useful sequence is requested, provisioned, running, stopping, terminated, collected, and expired. Provisioning establishes the artifact, identity, policy, limits, and private state before code starts. Stopping prevents new work and drives termination of the whole execution subtree. Collection exports only declared artifacts and receipts. Expiry removes retained resources according to policy. Failures at any transition need retries and an owner; “the command exited” is not equivalent to “the environment and everything it started are gone.”
What a snapshot preserves
Snapshots change the local recovery boundary. Arrakis pauses a VM, captures guest memory, separately saves the writable filesystem layer, and resumes it. This can restore processes and local files without rebuilding earlier work. A snapshot is not self-contained by definition: Firecracker restoration also needs referenced disk files, network interfaces, and host resources. Reusing saved state can duplicate identifiers, random seeds, entropy pools, or cryptographic tokens; repeated resumption requires an explicit uniqueness design.
Two recovery boundaries
Terminating or restoring a sandbox does not reverse accepted remote effects. A timeout can leave an unknown outcome: success or failure is unconfirmed. See Represent uncertain external outcomes.
Recover effects explicitly
Use a stable operation identity when the receiving service supports idempotency, and reuse it only for the same logical intent and parameters. The receiving boundary must coordinate duplicate detection with the mutation; merely writing the identifier to a local log does not prevent duplicate effects. When status remains unknown, reconcile against authoritative provider state before retrying. Compensation is a new operation that counteracts completed work; it can fail and need human resolution, so it is not rollback.
Local termination does not resolve a remote write
Example operation op-42; this provider supports authoritative lookup by operation identity. Rows are event order, not measured durations.
| Event | Environment | Supervisor / caller knowledge | Actual provider state |
|---|---|---|---|
| 1 · Dispatch | Running; sends op-42 | Awaiting response for op-42 | Accepts op-42 and commits the write |
| 2 · Response lost | Running | No completion response received | Write remains committed; reply is lost |
| 3 · Timeout | May still be running | Outcome unknown: timeout is not failure confirmation | op-42 remains committed |
| 4 · Confirm termination | Whole execution subtree terminated | Local termination confirmed; remote outcome still unknown | op-42 remains committed |
| 5 · Reconcile | Remains terminated | Supervisor queries op-42; authoritative reply confirms the write | Reports committed op-42; no new mutation is requested |
Tenant separation and warm reuse
Multi-tenant isolation has two dimensions. Simultaneous tenants need distinct identities, storage and network contexts, authorization, capacity controls, and placement rules so one workload cannot read or starve another. Sequential tenants add residual state: a new invocation or restarted process can encounter memory, temporary files, caches, connections, background work, snapshots, credentials, or shared host-side stores left by an earlier run. Lampson's confinement paper (October 1973) made the distinction explicit: preventing unauthorized access does not stop a service from leaking information it legitimately received, including through state retained between calls.
Warm-reuse responsibilities
| Surface | Safe possibilities | Evidence needed |
|---|---|---|
| Process memory | New instance, zeroed memory, or same-tenant reuse | Cross-run canary and runtime design |
| Scratch files and caches | Private layer destroyed or tenant-bound | Filesystem inspection after reset |
| Connections and background work | Closed and subtree terminated | Host observation after cancellation |
| Credentials | Never present, expired, revoked, or tenant-bound | Broker and downstream authorization records |
| Snapshots | Bound to immutable base, policy, tenant, and uniqueness procedure | Restore manifest and negative tenant test |
| Host-side shared stores | Partitioned, immutable, or omitted | Effective integration configuration |
Reuse is not reset
AWS Lambda documents that global objects, temporary files, reusable connections, and unfinished background work can survive environment reuse; even a failure reset does not clear /tmp. Its tenant-isolation mode reuses environments only for a supplied tenant identifier, but all tenants still use the function’s execution role. Environment assignment and external-service authorization are therefore separate. Docker’s agent sandbox documentation offers another boundary reminder: a writable workspace or shared skills store can carry changes outside the VM, and host stdio integrations execute with host permissions.
Warm pools can reduce startup work, but cross-tenant reuse requires demonstrated reset coverage for every retained surface in the deployment: memory, kernel caches, files, devices, credentials, background work, and host integrations. Define who resets each surface and how a failed reset prevents reassignment. Where that coverage has not been established, use single-use environments or reuse only within the same explicitly authorized tenant and policy domain.
Part VI — Escape and assurance
Contain failure beyond the wall
A sandbox escape breaches the intended execution-isolation boundary, giving untrusted code access that boundary was meant to prevent. An in-sandbox crash is not automatically an escape. Vulnerability research on V8 distinguishes faults within sandboxed objects from exploit chains that achieve effects outside the boundary. Conversely, an allowed network connection or overprivileged tool can harm an external resource without an escape: that is misuse of granted authority. Security claims must identify both the authority reached and whether isolation was defeated.
Different boundaries, different paths
Escape paths depend on the mechanism. Processes and containers expose shared-kernel paths; VMs expose VMM, KVM, virtual-device, management, and host-integration paths; runtimes expose parser, compiler, host-interface, and embedding defects. Privileged container settings, host daemon sockets, writable host mounts, leaked bootstrap descriptors, overpowered brokers, network routes, and control-plane credentials can bypass or enlarge the boundary without a classic kernel or VM exploit.
Controls play different roles. Minimal interfaces, memory-safe implementations, syscall filtering, and reduced device models shrink attack surface. Independently enforced nested boundaries can require an attacker to defeat additional controls. Tenant-aware placement, absent credentials, brokered capabilities, and restricted egress can reduce consequences while their enforcement remains trustworthy. After host compromise, credential brokering and egress restrictions require enforcement outside the compromised trust domain; host-controlled checks cannot supply that protection. Host telemetry and policy records aid detection. Patching, revocation, isolation of affected hosts, and immutable replacement support recovery. AI Security’s attack-path method is the right organizing principle: attach each control to the edge it blocks, narrows, observes, or repairs.
A model instruction to avoid production, an approval prompt, or a complete audit log does not establish containment. Agents can remain within supplied tools and still choose a path that violates the intended constraint. Deterministic authorization, scoped capabilities, semantic review where needed, and meaningful human escalation belong outside the worker’s uncontrolled decision loop. Even then, the architecture can add cost and latency and leaves residual risk.
Evidence for a bounded claim
Sandbox assurance is always versioned and scoped. Record the execution contract, workload artifact digest, base image, effective mounts, identities, policies, limits, runtime, kernel or hypervisor, host integrations, and test fixture. A policy file proves that text exists. Effective configuration shows what the runtime accepted. A negative test shows an attempted prohibited outcome failed under stated conditions. Host or provider observations establish later effects. None alone proves universal safety.
Requirement-to-check matrix
| Promise | Effective configuration | Positive check | Negative or failure check | Remaining assumption |
|---|---|---|---|---|
| Filesystem | Mounts, descriptors, devices and export policy | Read named input; export declared result | Attempt host path, symlink escape and oversized archive | Kernel/runtime and trusted exporter correctness |
| Network | All outbound paths and gateway policy | Reach approved service through broker | Try direct IP, redirect, private range and metadata endpoint | Gateway, DNS and host-network correctness |
| Identity and secrets | Workload principal, token audience and broker bindings | Perform one authorized tenant operation | Cross-tenant object, expired grant and secret-read attempt | Downstream authorization correctness |
| Resources | Applied cgroup, rlimit, quota and deadline values | Complete representative workload | Fork, allocate, fill blocks/inodes, flood output and overrun time | Enforcer and host capacity remain available |
| Lifecycle | Supervisor ownership, process subtree and retention policy | Collect result and destroy owned resources | Cancel during child creation; crash broker; inspect survivors | Host observation is complete enough |
| Tenancy | Placement, reuse, snapshot and reset policy | Same-tenant authorized reuse if supported | Sequential and concurrent cross-tenant canaries | No untested retained or side-channel surface |
| External effects | Stable operation identity and reconciliation path | Confirmed mutation with provider receipt | Timeout after possible acceptance, then safe reconciliation | Provider enforces its idempotency contract |
Exercise the rule, not its presence
Tests should cover both sides of policy rules. Firecracker’s published seccomp validation test compiles per-thread filters, exercises permitted calls and arguments, then alters constrained arguments and expects rejection. That is stronger than checking that a filter file exists, but it remains bounded to the calls, arguments, version, and helper exercised. The same discipline applies to mounts, network destinations, tenant records, process cleanup, and snapshot restoration.
Adversarial evaluation should observe effects rather than model rhetoric; AI Security develops that method. Governance assurance should connect each requirement to an owner, implementation, assessment, expected result, and response to failure; see Verify and revisit decisions. The defensible conclusion is deliberately narrow: under these versions, policies, identities, integrations, workloads, and attack attempts, the named permitted paths worked and the named prohibited effects were not observed. Patching, incident drills, and reassessment are required as any of those conditions changes.
Open questions
How can a platform prove that a warm environment is clean enough for a different tenant? A general answer must cover process memory, files, caches, connections, devices, credentials, background work, snapshots, and host-side integrations. Progress would look like a versioned reset contract with complete surface ownership, failure injection, and cross-tenant canary tests rather than an invocation-level reset claim.
How should portable sandbox policy remain equivalent across laptops, clouds, and private clusters? Filesystem, network, identity, runtime, and management primitives differ, so identical policy text may not imply identical enforcement. Progress would require a portable contract compiled into platform-specific controls plus conformance tests that observe the same permitted and denied effects in every target.
How can capability brokers remain small and trustworthy as agents need more operations? Each new method, argument, destination, and tenant rule enlarges the broker’s attack and confused-deputy surface. Progress would combine narrow typed interfaces, resource-level authorization, stable delegation records, robust path and destination handling, and adversarial tests of both broker and downstream policy.
How should snapshots preserve useful state without duplicating identities and credentials? Machine snapshots can retain random seeds, tokens, connection assumptions, and identifiers that must be unique after restoration. Progress would define which state is restored, regenerated, rebound, or rejected and would validate those rules across cloning, repeated resume, migration, and tenant changes.
What evidence should justify stronger isolation at acceptable operational cost? Comparisons across containers, application kernels, conventional VMs, and microVMs require matched workloads, stated threat assumptions, and explicit measurement endpoints. Startup, task readiness, I/O behavior, memory overhead, density, observability, and patch burden answer different questions. Useful comparisons would report these separately alongside the security boundaries and operating responsibilities of each configuration.
