Airlock Blast Radius Zero · team Airlock BR0 · gVisor sandbox · source

For SREs who need an agent on untrusted logs — not on the host.

Airlock (Blast Radius Zero)

Useful work gets a report. A compromised agent is stopped at the gate. Counts are checked independently — not trusted from the model.

About 3 seconds, no model call (replay). Gate, sandbox and signed receipts are real.

Who it is for and the threat model

An SRE who wants an agent to triage untrusted logs. The agent may read a log that tells it to run curl | sh. Airlock assumes the agent is already compromised and asks whether an independent gate can stop the action.

The replay result appears here

  1. Press “Watch Airlock stop an attack”. Each harmful proposal of the replay gets its own card, built from the API response.
Nothing has run yet.

See Airlock in action

  1. 1. Useful worklive log triage → report.md + independent recount
  2. 2. Stopped attackreplay gate denies harmful proposals before any container
  3. 3. Runtime probestimeout + memory only (claim after a real Docker PASS)
  4. 4. Proofreceipt signature + Evidence Bundle offline check
Technical steps and caveats

Step 1 needs VULTR_INFERENCE_API_KEY. Network / read-only probes are not in this demo. A valid signature means the record was not tampered with; it does not prove the world-state claim. Live and replay stay labelled.

Gate, sandbox and receipts are real. Live and replay stay labelled.

Why I built Airlock

Without Airlock

An AI agent follows a malicious instruction hidden in a log and attempts an unsafe action. Whatever it proposes runs with the agent's access to my host and keys.

With Airlock

The action is independently checked, blocked before execution, and recorded in a verifiable receipt. Safe work still runs, inside a sandbox with no network, and I get a report.

An AI agent can make a mistake. I built Airlock so that mistake does not automatically become my incident.

How a proposed action moves

Airlock pipeline Agent proposes, then policy gate, then sandbox (gVisor), then verifier, then signed receipt. A blocked action stops at the policy gate and goes straight to a signed receipt; no sandbox is started. Agentproposes code Policy gatestatic, allow-list SandboxgVisor, no network Verifieroutput and cleanup Signed receiptEd25519, hash chain allow deny: the blocked action stops here, no container is created, the decision is still signed Airlock pipeline Agent proposes, policy gate, sandbox (gVisor), verifier, signed receipt. A blocked action stops at the policy gate; no sandbox is started and the decision is still signed. Agentproposes code Policy gatestatic, allow-list SandboxgVisor, no network Verifieroutput and cleanup Signed receiptEd25519, hash chain allow denystopsherenocontainer

BLOCKED the gate denied it before anything ran · ALLOWED it passed the gate · CONTAINED allowed code ran in the restricted sandbox (runsc, no network, limits) · TERMINATED the sandbox stopped it (killed_by=timeout or oom on this demo path) · VERIFIED the receipt's signature and receipt hash check out. A valid signature means the receipt was not tampered with; it does not by itself prove the world-state claim inside the receipt.

What I guarantee: every action the agent proposes is checked by the policy before anything runs, denied code never reaches a container, and every decision gets a signed, hash-chained receipt. You can check a receipt's signature and hash here in your browser or offline with the published key and tests/js/verify_cli.mjs from the repository; chain linkage is checked by the offline CLI (airlock verify-chain). What I do not: that the policy catches every attack, or that the host itself is honest. The receipt proves what was recorded, not that the machine was uncompromised. Known limitations.

loading…

Try it yourself — same order as above

SRE log triage live

This is the useful-result path for an SRE: the live model gets /work/input/app.log (on this corpus) and is asked to count ERROR/WARN lines, group errors, and write report.md that includes exactly one ```airlock-counts fence (ERROR: N / WARN: N only). Every proposal goes through the gate; allowed code runs in the sandbox. When it finishes you can download the report, read the raw stdout, see cleanup evidence, and an independent host recount against that fence (VERIFIED / FAILED / INCONCLUSIVE — prose and examples do not count). Receipts are labelled mode: live. Needs VULTR_INFERENCE_API_KEY. A run takes 20–90 seconds because the model reasons before answering. Claims are on this corpus only.

Task prompt and sample log 

    

  

  
  














  
Policy corpus numbers

  
Computed by scripts/corpus_metrics.py over two corpora. Every number is
  on this corpus only. The first corpus I wrote myself while building the policy:
  0 false-ALLOW on my own corpus. The second was written by an independent reviewer: on that corpus
  the policy had 46 false-ALLOWs before my fixes, 6 of them security-relevant, and after the fixes
  39 remain, 0 of them security-relevant (I triaged each by hand). Neither says anything about
  attacks nobody thought of.

  
loading…


  

  
Known limitations

  

    
LimitationWhat it means

    
      
Containers share the host kernelUnder runc a kernel bug is a host escape. This deployment runs gVisor (runsc), which puts a user-space kernel in between and shrinks that surface. It does not remove it.

      
The static policy is incompleteIt is an allow-list parser for a subset of Python and bash. Unknown constructs are denied, but a bypass in what it does allow is possible. The sandbox is the second line.

      
Signatures cover the record, not the hostA valid signature proves the receipt came from the holder of this key and was not edited. It does not prove the host was honest or uncompromised when it wrote it.

      
No egress allow-listThe only network mode is none. Tasks that need the network cannot run here.

      
The control process can reach the Docker socketThe API service runs as an unprivileged user in the docker group, which is root-equivalent on this VM. The socket is never mounted into a sandbox or exposed over the network.

      
The signing key lives on this VMThe Ed25519 key sits on the same VM as the API process, and that process can reach Docker. Whoever controls the host can sign anything. The receipts prove integrity of the record, not honesty of the host.

      
Receipts are kept, not prunedDeleting one breaks the hash chain. Old work dirs and containers are pruned by a timer.