Sandboxing for Agentic Execution.

A word that means nothing.

"Sandbox" gets stamped on Docker containers with seccomp profiles, on browser tabs, and lately on agent policy frameworks whose enforcement runs beside the very agent they claim to contain. An LLM-driven agent effectively executes untrusted code: its behavior is a function of its prompt, its tools, and whatever it read moments earlier. Conflating a syscall filter with a virtualization boundary creates a false sense of security exactly where the stakes are highest.

The gap is not theoretical. Edera's SandboxEscapeBench put LLM-driven agents against 18 real-world escape scenarios. Roughly half succeeded against Docker. Hypervisor-isolated zones blocked 16 of the 18, mitigated one, and were exposed once, through a misconfiguration rather than a kernel exploit. A shared kernel is the difference between roughly half and nearly none, and the one exposure that remained came from configuration, which is exactly the surface a sandbox definition needs to remove.

"Sandbox" now covers everything from a browser tab to a hardware-isolated guest, and the difference is the whole security story. The fix is not a better adjective; it is a fixed set of testable properties.From the white paper

The definition.

A sandbox is an execution environment with a small, enumerable trusted computing base, in which the workload runs as a guest against its own kernel, behind an isolation boundary enforced outside the workload's reach. The guest holds no ambient authority: every capability it can use ships, declared, in a single reproducible, hash-verifiable image. Resource ceilings are enforced outside the guest and hold under adversarial load. State is ephemeral, and the supported configuration surface is validated so that no supported option can widen what the guest can reach.

A sandbox collapses the trust problem from "do I trust this agent?" to "do I trust this specification?" by making the execution environment a verifiable function of its source specification, enforced by an isolation boundary the workload cannot reach and supported configuration cannot widen.

Two evidence classes qualify as the boundary today: hardware-assisted virtualization (hosted hypervisors like KVM, and type-1 multi-domain designs), and formally verified separation kernels of the seL4 class. What unites both is the requirement, not the mechanism: the workload shares no application kernel with the host.

Threat model.

The definition operates under a zero-trust assumption. Agents may be well-intentioned, compromised, or malicious, and the three states are indistinguishable at runtime. An agent that was benign at deployment can be subverted by a poisoned dependency, a prompt injection, or a tool response it had no reason to distrust. Execution threads are treated as running potentially malicious code from the moment they start, up to and including a fully compromised guest kernel.

The model separates four objectives, because each is enforced by a different component and fails differently:

• Protect the host from the guest. The primary objective, enforced by the isolation primitive and the device model.
• Protect guests from each other. Enforced by the same boundary plus host-side scheduling and storage separation.
• Bound denial of service. Enforced by external resource ceilings at the sandbox, node, and shared-service levels.
• Preserve the integrity of the record.Enforced by anchoring the audit trail outside the guest, so a compromised workload cannot rewrite the account of what it did.

Out of scope, and said so explicitly: a malicious host kernel or hypervisor, and microarchitectural side channels under extreme threat models. Both are genuine risks; neither is fully solved by any isolation primitive deployable today.

The seven properties.

Each property states a claim, names the component that enforces it, says what it eliminates, and carries a falsification test an independent evaluator can run.

1. Guest-kernel isolation with an explicit host-side TCB.

The workload shares no application kernel with the host. Eliminates the entire class of "sandboxes" that rely on syscall filtering and namespace partitioning inside a shared kernel.

2. Zero ambient authority.

No implicit access to any external resource. Every capability is explicitly granted, narrowly scoped, and revocable mid-run.

3. Minimal, enumerable trusted computing base.

The security-critical code surface is small, auditable, and published as an inventory, not gestured at with a single number.

4. Reproducibility and verifiability.

Images are built reproducibly from a declarative specification and are hash-verifiable by anyone who rebuilds them. The image, plus its validated launch configuration, is the specification.

5. Externally enforced resource ceilings.

CPU, memory, and I/O are hard-limited and enforced outside the workload, and they hold under adversarial load, not just best-effort accounting.

6. Ephemerality and state containment.

Clean state at start, sanitized teardown, and persistence only when explicitly declared and scoped. Checkpoints, where taken, are governed as sensitive state.

7. Validated configuration surface.

No supported configuration option can widen what the guest can reach. Most container escapes require no kernel exploit at all, just one YAML line that was always there.

Where existing technologies land.

Every "sandbox" claim sorts on a single question: where does enforcement execute? If the mechanism that says no runs where the workload can reach it, it is a guardrail. If it runs outside a boundary the workload cannot cross, it is a sandbox. Scored against that question, unforgivingly and including our own stack:

• Containers + seccomp/AppArmor. Not a sandbox by this definition; fails the guest-kernel gate structurally in every configuration.
• gVisor. Meaningful hardening. The Sentry absorbs the workload's syscalls, but it is itself a host process whose own syscalls the host kernel serves, so the host kernel stays in the trust path.
• Agent policy runtimes (for example NVIDIA OpenShell). Not a sandbox by default: a policy overlay sharing the trust boundary of the agent it polices. A reachable guardrail is a bypassable guardrail.
• Kata Containers. Passes the guest-kernel gate. The general-purpose guest kernel and in-guest agent with its control channel still owe the minimal-TCB and validated-configuration properties.
• Firecracker microVMs and upstream urunc.Pass the gate natively, with a minimal guest, no in-guest control agent, and no guest-to-host control channel.

Surveying what agent runtimes actually ship tells the same story one layer up: AWS Bedrock AgentCore and Fly Machines name Firecracker per session; Azure names Hyper-V. Some platforms claim isolation without naming the primitive at all, which by this standard is not yet a checkable sandbox claim.

How NOFire applies this.

NOFire AI's Brain runs LLM-driven investigations against production systems holding credentials to customer infrastructure. This definition is not academic for us; it is the standard our own execution layer is held to.

Upstream urunc, the open-source OCI runtime and CNCF sandbox project, supplies the boundary: one microVM per task, no in-guest control agent, no guest-to-host control channel. The NOFire enterprise stack adds the remaining properties: deny-by-default policy for zero ambient authority, single-application kernel builds for a minimal TCB, reproducible images built with bunny, externally enforced resource ceilings, and per-step checkpoint and rollback, shipped today and governed as sensitive state.

Open problems.

We are explicit about what this definition does not cover, because a security document that claims everything protects nothing.

• Side channels. Timing and microarchitectural attacks remain open under extreme threat models.
• A malicious host. The definition protects the host from the agent, not the agent from the host. Hardware TEEs with remote attestation are the natural extension, and an active direction for us rather than a shipped property.
• Capability-level exfiltration. A sandbox confines effects to declared channels; it does not decide whether a declared channel is being misused.
• Introspection as trusted code. Host-side VM introspection reads untrusted guest state from privileged code, which makes the introspection stack itself attack surface.