Project
CorpoClaw
Banking-grade containment for AI coding agents and local model inference. Container-agnostic, Linux base, kernel-enforced boundaries, hard kill switch.
Drawing
CONTAINMENT
ARCHITECTURE
Sheet
1 of 1 · SELF-CONTAINED
Revision
REV 2
Supersedes Rev 1.
3 findings force changes — see Rev. history.
Status
FOR REVIEW
Internal

Every control that lives inside the agent's reach is not a control. CorpoClaw puts the boundary underneath the agent — a separate kernel it cannot rewrite, an egress policy it cannot edit, and a kill switch that fires in the kernel before its syscall completes.

01

Threat model

What the boundary is for

Three adversaries, one regulator. Every design choice downstream traces back to one of these.

T-1
Agent goes rogue

Prompt injection turns the agent into an insider. It exfiltrates source, keys, or customer data over a channel it was already allowed to use. It deletes, commits, or pushes things it shouldn't.

T-2
Generated code executes

The agent writes code and runs it. That code is untrusted by construction. A kernel exploit inside it must not reach the host or any other tenant.

T-3
Tenant bleed

One desk's agent must not see, reach, or affect another's — not through the kernel, not through the network, not through shared state on the node.

Proof that agent-side sandboxes are not boundaries

In March 2026, Ona researchers watched Claude Code reason its way past its own command denylist via /proc/self/root/… and then disable its own bubblewrap sandbox to finish the job. Separately, a leaked bashPermissions.ts showed a 50-subcommand cap that failed open — to a permission prompt, not a block. Even Ona's own kernel-level binary-hash check at the BPF LSM execve hook was bypassed through the ELF dynamic linker: mmap, not execve.

Claude Code, Gemini CLI and Codex CLI all ship sandboxes. Use them — as the innermost layer. Never as the boundary.

02

Containment section

Cut A–A · hover a balloon

A cut-through of one sandbox. Read it bottom-up: that is both the boot order and the trust order. The heavy rule is the only line in this drawing enforced by silicon.

Fig. A — Containment cross-section, one workload Balloons ①–⑫ index the bill of materials
EVERYTHING THE AGENT CAN REACH, READ AND REWRITE Its own sandbox config lives in here. So it can turn it off. Assume it will. ENFORCEMENT PLANE — OUT OF REACH Policy, kill switch and audit tap all sit below the boundary, on the host. AGENT PROCESS — UNTRUSTED Claude Code · Gemini CLI · Codex CLI · Ollama (llama.cpp) + its own bubblewrap / Landlock / seccomp sandbox — innermost layer, not the boundary T-1 · T-2 OCI CONTAINER read-only root · tmpfs/overlay workspace · CPU / RAM / PID caps · secrets scrubbed from env GUEST KERNEL — ONE PER WORKLOAD kata-agent · virtio-blk / virtiofs · virtio-net · virtio-vsock a kernel exploit in here stops at the rule below TRUST BOUNDARY · KVM · HARDWARE-ENFORCED A A VMM — SELECTED PER TIER Cloud Hypervisor (T1) · Firecracker + jailer (T2) · QEMU + VFIO (T3) host-side process, itself jailed in namespaces + seccomp device model = attack surface eBPF ENFORCEMENT PLANE Cilium — default-deny egress, IP/SNI allowlist · Tetragon — in-kernel SIGKILL, audit tap HOST LINUX KERNEL + KVM /dev/kvm · cgroups v2 · seccomp · LSM BARE-METAL HOST CPU · IOMMU (VT-d / AMD-Vi) · NVMe · NVIDIA GPU — optional: SEV-SNP / TDX EGRESS KILL VALVE 1 2 3 4 5 6 7 8 9 10 11 12 audit tap → SIEM restored from snapshot, not cold-booted
The agent owns everything above the rule and nothing below it. Cilium and Tetragon sit on the host side deliberately: an agent that talks its way out of its own sandbox still cannot edit the policy that kills it.
03

Trust tiers

One framework, three VMMs

Kata is the framework. The VMM underneath it is the actual decision, and it is not one VMM — it is three, chosen by what the workload is allowed to touch.

Fig. B — Tier ladder Boundary strength ↑ · I/O cost ↑
TIER WORKLOAD RUNTIME VMM BOUNDARY NOTE 0 Trusted internal, reviewed code no untrusted input, no generated code runc (hardened) — shared host kernel never for agents 1 Remote-API agentic CLIs Claude Code · Gemini CLI · Codex CLI Kata · kata-clh Cloud Hypervisor Rust · ~50k LoC · PCI bus · snapshot boot ≈200 ms 1alt Same, where /dev/kvm is unavailable gVisor (runsc) — userspace kernel −76% random I/O 2 Untrusted generated code · max density ephemeral, one sandbox per task, destroyed after Kata · kata-fc Firecracker + snapshots 5 virtio devices · no PCI · <5 MiB overhead GPU impossible 3 Ollama · local model inference weights read-only · egress off once pulled Kata kata-qemu-nvidia-gpu QEMU + VFIO the only path NVIDIA + Kata both document bare metal only 3cc Ollama on residency- or IP-sensitive data operator is a documented adversary CoCo / Kata-CC QEMU + SEV-SNP / TDX kata-qemu-nvidia-gpu-snp / -tdx ≈4 GB/s CPU↔GPU
Tenant separation (vCluster + vNode, or per-tenant node pools) is orthogonal and layers over all of the above.
04

VMM selection

Two questions decide it

The device model is the attack surface, the feature set and the boot time. Choosing a VMM is choosing where you sit on the line between "fewer devices" and "more capability". Two questions get you there.

Fig. C — VMM decision tree 2 Firecracker/GPU branch corrected at Rev 2
WORKLOAD NEEDS A GPU? YES BARE METAL? YES kata-qemu-nvidia-gpu QEMU + VFIO · GPU Operator NO gVisor + nvproxy CUDA only · host driver in TCB NO /dev/kvm PRESENT? NO gVisor (runsc) the no-KVM floor YES UNTRUSTED CODE? YES kata-fc Firecracker + snapshot warm pool NO kata-clh Cloud Hypervisor · default kata-fc ✕ GPU no PCI bus. no VFIO. PCIe work paused 2025.
The Firecracker dead-end is why E2B, Fly.io Sprites and Vercel Sandbox are all CPU-only. If a vendor sells you Firecracker sandboxes and GPU workloads, ask which VMM actually runs the GPU path.
VMMLang / sizeDevice modelCold boot SnapshotVFIO / GPUConfidentialUsed by
FirecrackerRust · ~50k 5 virtio · no PCI, USB, BIOS~125 ms YES ~4 ms NONE NO Lambda, Fargate, E2B, Vercel
Cloud HypervisorRust · ~50k virtio + PCI (~16 devices)~200 ms YES + userfaultfd YES, less mature TDX Northflank, Fly.io GPU
QEMUC · ~2M 40+ devices, full emulationseconds YES YES — most mature SNP + TDX everyone, eventually
DragonballRust · in-shim virtio + VFIOultra-light — YES — Ant / Alibaba
libkrunRust · library virtio + virtio-gpu<200 ms — macOS path only SEV / TDX Podman, RamaLama, microsandbox
HyperlightRust · library none — no kernel, no OS1–2 ms ~900 µs warm n/a — Azure edge (early)

2 Trap — libkrun is not a drop-in Firecracker

libkrun's own documentation states that the guest and the VMM sit in the same security context and should be thought of as one entity — host resources reachable by the VMM are potentially reachable by the guest. It expects you to wrap the VMM in namespaces. That is a fundamentally different posture from Firecracker's jailer. Do not put libkrun in Tier 2 without an independent host-side jail around it.

RULED OUT
Hyperlight · unikernels

Hyperlight exposes the guest a linear slice of memory and a CPU — no kernel, no OS. Unikraft is single-address-space and single-purpose. Neither can run a shell, git, npm or Ollama. An agentic CLI exists to fork and exec subprocesses; that is the one thing these are built not to do.

REPURPOSED
Nitro Enclaves

No network, no persistent storage, no PCI — so no GPU, no remote-API CLI, no weights. Useless as an agent sandbox. Excellent as the key broker: mint capability tokens and hold API keys inside an attested enclave, so a root-compromised orchestrator still cannot exfiltrate them.

05

GPU passthrough

The tier that constrains the rack

Tier 3 is where the architecture stops being a software choice. Handing a guest a real PCIe device hands it a DMA engine — the IOMMU is the only thing between that and host memory.

Fig. D — GPU path and its cost Bare metal · IOMMU enabled in BIOS
NVIDIA GPU physical PCIe device Hopper / Blackwell vfio-pci unbind from nvidia, rebind to vfio IOMMU VT-d / AMD-Vi enforces DMA isolation groups must be clean KATA GUEST (QEMU) guest kernel + NVIDIA driver Ollama · llama.cpp weights volume — READ ONLY egress OFF once pulled DMA — THE RESIDUAL RISK a passed-through device can address host memory. the IOMMU is the boundary. dirty groups undo the microVM. NVIDIA GPU OPERATOR sandboxWorkloads · kataManager ccManager · drives the VFIO bind HARD CONSTRAINT nested virt gives you KVM. it does not give you VFIO. ALTERNATIVES gVisor + nvproxy — CUDA only, host NVIDIA driver stays in the TCB, does not mitigate driver CVEs Firecracker — no PCI bus, no VFIO. Not a degraded option. Not an option.
Red Hat's RamaLama proves you can run a model in a microVM — but its GPU path is macOS/Apple Silicon (virtio-gpu → Venus → MoltenVK → Metal). On Linux, libkrun was CPU-inference only as of mid-2025. Do not architect Tier 3 on it today.
06

Egress & kill switch

The control that actually stops exfiltration

Exfiltration is a network problem. If the agent's packet cannot leave, the injection failed — regardless of how thoroughly it owned the sandbox.

Fig. E — Packet path and enforcement point Enforcement lives outside the agent's reach
AGENT'S REACH — ASSUME COMPROMISED agent process → connect() guest kernel → virtio-net the agent can rewrite everything in this box TRUST BOUNDARY HOST · eBPF · OUT OF REACH CILIUM default-deny egress allowlist by IP/CIDR + TLS-SNI — never hostname suffix. see below. TETRAGON in-kernel SIGKILL — fires before the syscall completes 1–3% CPU · also the audit tap ON THE ALLOWLIST → egress permitted api.anthropic.com · statsig · sentry (Claude Code) Ollama after weights are pulled: nothing. zero egress. NOT ON THE ALLOWLIST → KILL 1 · Tetragon SIGKILLs the process in-kernel 2 · microVM destroyed — network severed, state discarded 3 · event → tamper-evident store → SIEM → on-call WHY NOT HOSTNAME MATCHING Claude Code shipped a SOCKS5 null-byte injection that walked straight through a naive hostname allowlist, plus a second documented allowlist bypass (CVE-2025-66479). Match on what the packet actually carries — the resolved IP and the TLS SNI — not on a string the agent controls. Codex CLI already does the right thing by default: network OFF during the agent phase, i.e. exactly when injection risk peaks.
Placement is the whole point. Both enforcement components sit on the host, below the boundary. The agent can defeat its own sandbox — as it demonstrably has — and still not touch the policy that kills it.
07

Snapshot & warm pool

2 New at Rev 2 — highest-leverage work

Rev 1 argued for gVisor at Tier 1 on latency grounds. Snapshots delete that argument: you pay the microVM boot cost once, at template build, then restore per task in single-digit milliseconds.

Fig. F — Sandbox lifecycle Build once · restore per task
BUILD — ONCE, AT TEMPLATE TIME boot VM 125–300 ms warm the toolchain node · python · git pkg caches primed SNAPSHOT memory + device state PER TASK — EVERY AGENT INVOCATION RESTORE 4 – 30 ms agent runs the task egress allowlisted, kill armed DESTROY state discarded back to warm pool THE DELTA cold boot, per task 125 – 300 ms restore from snapshot 4 – 30 ms Hyperlight warm-start, for scale ≈900 µs — but no kernel, so no CLI TWO BUGS THIS INTRODUCES 1 · Cloned VMs share CSPRNG state. Reseed the kernel (RNDADDENTROPY) AND userspace PRNGs per fork — or every sandbox mints the same nonces. 2 · A snapshot captures guest memory and device state, not the block device. Snapshot the filesystem separately or your rollback is inconsistent.
Firecracker restore has been measured as low as ~4 ms by its own authors. Cloud Hypervisor v52.0 (May 2026) added userfaultfd demand-paged restore and sparse snapshot files, which matters for large guests.
08

Deployment ladder

2 AWS changed this in Feb 2026

Same OCI image, same RuntimeClass mechanism, four substrates. Descend the ladder only as far as the environment forces you — and know exactly what you give up on each rung.

Fig. G — Substrate ladder, best to floor Local · private cloud · public cloud
RUNG 1 — BEST BARE METAL on-prem, colo, or *.metal All tiers. Full VFIO. GPU passthrough. Confidential computing. Required for Tier 3. There is no substitute — see Fig. D. T0 · T1 · T2 · T3 · T3-CC RUNG 2 NESTED VIRT standard cloud VMs You get /dev/kvm. Kata, Firecracker and CLH all run properly. AWS since 12 Feb 2026 (C8i/M8i/R8i, later C7i/M7i/R7i/I7i/X8i + GovCloud). Azure since 2017 (v3+). GCP since 2017 (KVM only, Haswell+, ~10% CPU hit). T0 · T1 · T2 — no GPU nested virt ≠ VFIO RUNG 3 PEER PODS kata-remote CoCo cloud-api-adaptor. The Kata shim calls the cloud API and gets a real VM per pod. No nested virt, no bare metal needed. AWS · Azure · GCP · IBM · vSphere · libvirt. CoCo's own docs: won't work well for small, short-lived workloads — i.e. not for ephemeral agent sandboxes. LONG-LIVED PODS ONLY RUNG 4 — FLOOR gVISOR runsc No KVM required. Runs literally anywhere. Still a real boundary — a userspace kernel, not a shared one. Pay the tax: −76% random I/O, −42% HTTP throughput. But the lowest API latency of the three (6.6 ms). Also the GPU fallback via nvproxy — CUDA only, host driver stays in the TCB. T0 · T1 — degraded
Rev 1 said "no /dev/kvm on public cloud → fall back to gVisor." That was true then. AWS shipping nested virt on non-metal instances in Feb 2026 makes Rung 2 the realistic default for Tiers 1 and 2.
09

Confidential tier

Where the operator becomes the adversary

This is the tier that answers "who could have read the prompt?" with a cryptographic measurement instead of an org chart.

Fig. H — Attestation and key release CoCo · SEV-SNP / TDX · NVIDIA CC
WORKLOAD OWNER policy TRUSTEE / KBS attestation service + reference values holds the keys ① evidence ② key — only if measurement matches CONFIDENTIAL VM — MEMORY ENCRYPTED AMD SEV-SNP · Intel TDX · kata-qemu-nvidia-gpu-snp / -tdx attestation agent + confidential data hub image-rs image pulled INSIDE Ollama · model weights decrypted in-enclave the host never sees the image, the weights, or the prompt NVIDIA CC GPU Hopper / Blackwell, CC mode joins the TEE · own attestation ≈4 GB/s CEILING encrypted bounce buffer SPDM WHAT THIS BUYS YOU WITH A REGULATOR Cryptographic evidence of exactly what code ran. Container images never exposed to the untrusted host. The infrastructure operator is a documented adversary you hold controls against — not a trusted party you hope behaves.
Hardware prerequisites are not a config change: SEV-SNP or TDX CPU with correct BIOS, a CC-capable Hopper/Blackwell GPU with the right VBIOS, and a current host OS. Budget a refresh. Blackwell + TDISP removes the bounce-buffer ceiling; Hopper does not.
10

Audit & the permitted-action gap

The part that should worry you
Fig. I — Evidence chain, and what it misses SOC 2 · ISO 27001 · GDPR
TETRAGON process lineage · file access · every connection correlated to pod + tenant APPEND-ONLY TAMPER-EVIDENT + attestation evidence SIEM alerting · on-call CONTROL MAPPING SOC 2 CC-series · ISO 27001 A.12 / A.14 · GDPR residency per-agent SPIFFE identity · scoped capability tokens · kill-switch runbook THE PERMITTED-ACTION GAP — NOTHING ABOVE CATCHES THIS A prompt-injected agent that stays inside its permitted syscalls, its network allowlist and its IAM scope is indistinguishable from a legitimate one. Kernel isolation does not see it. Egress allowlists do not see it. It is doing only things it was allowed to do — just for someone else's reasons. Closing it needs behavioural detection + task-scoped capability tokens the agent cannot widen. Build that next. A regulator who understands the problem will push here first.
Isolation is necessary and insufficient. Say that out loud in the architecture review — it is the difference between a design that survives scrutiny and one that gets waved through and then fails.
REV 2 · CHANGE 1
Firecracker cannot serve Tier 3

No PCI bus, no VFIO, PCIe work paused 2025. Rev 1 listed it as a GPU-capable Kata backend. It is not, and never was. Tier 3 moves to kata-qemu-nvidia-gpu.

REV 2 · CHANGE 2
Public cloud got nested virt

AWS shipped it on non-metal EC2 on 12 Feb 2026. Rev 1's "fall back to gVisor on public cloud" is superseded. But nested virt still does not give you VFIO, so Tier 3 stays on bare metal.

REV 2 · CHANGE 3
Snapshots beat gVisor's latency case

Restore in 4–30 ms versus a 125–300 ms cold boot. The main reason Rev 1 preferred gVisor at Tier 1 no longer holds. Warm pools become the highest-leverage build item.

BOM

Bill of materials

Everything you actually deploy

Balloon numbers tie back to Fig. A. Filter by tier to see what a single tier costs you.

Filter
#ComponentIdentifier RoleTiers
1Bare-metal hostIOMMU · VT-d / AMD-ViPhysical substrate. IOMMU enabled in BIOS, clean IOMMU groups. Required for any GPU tier.ALL
2Host Linux kernel + KVM/dev/kvmHardware virtualization. Without it, Kata falls back to QEMU TCG at 10–100× slowdown.ALL
—containerd + CRIcontainerdRuntime plumbing. RuntimeClass is the switch that selects everything below.ALL
5Hardened runcruncseccomp-bpf, AppArmor/SELinux, cgroups v2, userns, no-new-privs, dropped caps, read-only root.T0
5Cloud Hypervisorkata-clhTier 1 VMM. Rust, PCI bus, snapshot/restore with userfaultfd, CPU/mem hotplug.T1
5Firecracker + jailerkata-fcTier 2 VMM. Smallest device model in the field. Jailer applies ns + cgroups + seccomp to the VMM itself.T2
5QEMU + VFIOkata-qemu-nvidia-gpu[-snp|-tdx]Tier 3 VMM. The only backend NVIDIA and Kata both document for GPU passthrough.T3 · CC
5gVisorrunscThe no-KVM floor and the GPU fallback (nvproxy). Userspace kernel; pays the I/O tax.T1-alt
5Peer podskata-remoteCoCo cloud-api-adaptor. A real cloud VM per pod. Long-lived workloads only.fallback
7Guest kernel + kata-agentkata-agentOne kernel per workload. In-guest supervisor. This is what makes a kernel exploit non-transitive.T1–CC
7virtio device setvirtio-blk · virtiofs · virtio-net · vsockThe guest's only view of the outside. Fewer devices = smaller surface.T1–CC
8OCI container specread-only root + tmpfsWritable overlay sized to the repo; CPU/RAM/PID caps; secrets scrubbed from env, not inherited by children.ALL
3CiliumCiliumNetworkPolicyeBPF CNI. Default-deny egress; allowlist by IP/CIDR + TLS-SNI. Never hostname suffix.ALL
4TetragonTracingPolicyeBPF enforcement. In-kernel SIGKILL on non-allowlisted egress, sensitive-file access, kmod load. 1–3% CPU.ALL
10Kill switchSIGKILL + VM teardownTwo-stage: kernel kill, then destroy the microVM. Network severed, state discarded, atomically.ALL
12Snapshot template builderboot → warm → snapshotPay boot cost once. Warm the toolchain and package caches before the snapshot is taken.T1 · T2
12Warm pool managerrestore-per-taskRestore in 4–30 ms instead of cold-booting. Destroy after each task.T1 · T2
12PRNG reseed hookRNDADDENTROPY + userspaceCloned VMs share CSPRNG state. Reseed kernel and userspace per fork or sandboxes mint identical nonces.T1 · T2
12Block snapshotoverlay / block layerVM snapshots capture memory + device state, not the block device. Snapshot the filesystem separately.T1 · T2
—NVIDIA GPU OperatorsandboxWorkloads · kataManager · ccManagerDrives the VFIO bind into the Kata VM without breaking the trust boundary.T3 · CC
—vfio-pci bindingvfio-pciUnbind GPU from the nvidia driver, rebind to vfio. Verify IOMMU groups are clean first.T3 · CC
—NVIDIA Attestation SDKlocal verifierGuest pre-start hook. Combined CPU + GPU attestation evidence.CC
—Confidential ContainersCoCo · Kata-CCImages pulled inside the guest (never exposed to the host), attestation agent, confidential data hub, dm-verity.CC
—Trustee / KBSkey broker + attestation serviceReleases keys only to a matching enclave measurement. Reference-value provider.CC
—Attested key brokerNitro Enclave / SEV-SNP TEEHolds API keys and mints capability tokens. A root-compromised orchestrator still cannot exfiltrate them.CC · X
—SPIFFE / SPIREworkload identityPer-agent cryptographic identity — not inherited from the initiating human.ALL
—Capability token mintertask-scoped, non-wideableThe agent cannot widen its own scope. This is half the answer to the permitted-action gap.ALL
—vCluster + vNodetenant isolationControl-plane and node-level tenancy. Orthogonal to, and layered over, the per-workload sandbox.ALL
11Audit tap → store → SIEMappend-only, tamper-evidentTetragon event stream, correlated per tenant. The evidence a SOC 2 / ISO 27001 auditor actually wants.ALL
—Behavioural detectionTO BUILDThe other half of the permitted-action gap. Nothing else in this BOM catches an agent acting within policy for someone else's reasons.ALL
9Claude CodeOCI imageEgress: api.anthropic.com, statsig, sentry. Its own bubblewrap sandbox runs inside, as the innermost layer only.T1
9Gemini CLIOCI imageBubblewrap + seccomp; write-protects .git, hides .env*. Opt-in, so we do not rely on it.T1
9Codex CLIOCI imageLandlock + seccomp, sandboxed by default, network off during the agent phase. The best-behaved of the three.T1
9OllamaOCI image + RO weights volumeGPU via VFIO. Weights read-only. Egress off once pulled — then zero network, permanently.T3 · CC
RISK

Open risks · read before quoting any number

Honest register
Benchmarks are configuration-specific

The −99% / −76% / −42% figures come from one Feb 2026 study plus a 2022 journal paper. gVisor's own docs publish charts, not percentages, and note Netstack is improving. Benchmark your own agent loop — git clone, npm install, build, LLM round-trip — before you trust a tier assignment.

Firecracker's GPU status could change

The PCIe project was paused, not cancelled. The team framed the trade as PCIe costing memory overcommit and boot speed, with GPU snapshotting explicitly out of scope for the first iteration. Re-check before you commit the rack.

CVE-2026-44210

Kata virtiofsd argument injection → host filesystem escape. Recent enough that you should verify patch and advisory status directly against the version you deploy. No boundary is unbreakable; that is why there are four layers.

VFIO hands a guest a DMA engine

Every GPU tier trades a little of the microVM guarantee for hardware access. The IOMMU is the boundary. Dirty IOMMU groups quietly undo it. Verify groups before you trust the tier.

Vendor benchmarks are vendor benchmarks

Edera's numbers come from Edera's own paper. ZeroBoot's comparison table comes from ZeroBoot. Unikraft's "few milliseconds" does not match the independent 232 ms edge measurement. Leads, not evidence.

This market is consolidating quarterly

Apple Containerization v1.0 shipped Jun 2026. Google reported 16× sandbox growth on GKE in under five months. Docker shipped per-agent microVM sandboxes. Treat this drawing as a snapshot with a revision number, not a settled standard.