Airlock, an on-device firewall for AI agents.

Constraint

An autonomous agent reads more than its operator writes. Web pages, emails, documents, tool results: the working material of real tasks arrives from sources nobody vetted, and a model treats whatever it reads as candidate instructions. This is the mechanism behind prompt injection, and it is why one poisoned invoice can turn "summarize my inbox" into an attempt to mail credentials to an attacker.

The standing defense is the permission prompt, and it gates the wrong side of the loop. It interrupts the agent's actions, asks a human to review each one, and in practice gets switched off precisely by the teams who run coding agents like Claude Code autonomously, because an agent that stops to ask is not autonomous. We run our own fleet with permissions bypassed, so this exposure is one the lab carries itself. Airlock is the layer we built to gate the other side: not what the agent does, but what it reads. The gate is not a hardened frontier model, which stays remote, closed, and retrained on someone else's schedule; it is a boundary the operator owns, a small open model on the operator's own hardware deciding what reaches the large one.

Two tiers

Airlock guards an agent at two layers, and either tier stands alone. The network tier, airlock run, wraps any command in a sandbox whose only route out is Airlock's screening proxy. Every response is screened before the agent reads it, every outbound request is checked against a host allowlist, and request bodies are scrubbed of key-shaped material before they leave, even toward allowed hosts. Because this tier operates at the network boundary rather than inside the agent, it works unchanged for Claude Code, Codex, opencode, or a shell script.

The tool tier, airlock protect, sits closer to the model. It intercepts MCP tool results for a specific agent and screens the exact text a tool hands back, which covers the cases where no network hop exists to intercept. On Linux the sandbox is enforced by the kernel: a network namespace with a default-drop firewall makes the proxy the only egress, so a process that ignores its proxy settings is dropped rather than trusted. On macOS the enforcement falls back to the proxy environment, and the boundary between the two is stated in the threat model rather than blurred.

The screener

Every verdict is a local model call. Content goes to Gemma 3 through Ollama on the operator's own hardware, under a contract that returns allow or quarantine together with the threat family, the malicious span quoted back as evidence, and a confidence, at temperature zero, failing closed on any malformed response. An embedding stage runs alongside: EmbeddingGemma compares incoming content against a reference corpus of known attack families and forces a quarantine when similarity crosses threshold, which catches obfuscated variants of known attacks that a fresh reading might rate as ambiguous.

On-device is the architecture rather than a deployment option. A cloud screening service would have to receive the very content being screened, which includes the secrets and the attacks themselves. Nothing about a screened session leaves the machine.

The trust ledger

Every source an agent reads accumulates a record. A quarantine writes a dated trust revocation citing the exact span that triggered it, and the ledger is bi-temporal, so the state of trust at any past moment can be replayed as it stood then. The operator surface is a live feed of verdict cards rather than a dashboard: each card carries the content, the decision, and the highlighted span, and a quarantine interrupts the feed the way it interrupts the agent.

Architecture

The full path, end to end: content enters through the sandbox, faces the screener, and only what survives reaches the model. What does not survive is written down, twice: once as a withheld notice to the agent, once as a dated revocation in the ledger.

Evidence

Zero-shot, across the public deepset prompt-injections benchmark and a held-out corpus combined, the 12B screener holds a 76.5% true-positive rate at 5.4% false positives, scoring 68.3% on the public set alone. The held-out corpus spans seven attack families, from direct override to base64-obfuscated exfiltration, and both the 4B and the 12B model catch 21 of 21 payloads there, with the submitted demo running the 4B on a consumer laptop. The 1B model collapses to 13.6% combined, which is the instructive result: screening discipline emerges with scale, and the smallest viable screener is a 4B model running locally. The benchmark harness ships in the repository and reproduces the table in one command.

Recognition

Airlock took 2nd place in the Google DeepMind track of the RAISE Summit hackathon, the largest AI hackathon in the world. The track's brief, set by Google DeepMind, asked for applications running Gemma locally for offline, privacy-first inference, and the placement was judged on the demo, the public repository, and the written description. Notes from the event are here.