What the sandbox guarantees
Only this repo
The repo is mounted read-write at
/<reponame>. Your home directory,
~/.ssh, ~/.aws, and every other repo simply do not exist inside.Only allowlisted hosts
The sandbox sits on an internal Docker network with no route out. Its only
exit is the Airlock proxy, which refuses any host not on the allowlist.
Every request logged
Allowed or denied, each connection is appended to
~/.airlock/logs/<repo>/audit-<date>.jsonl.Your keys stay yours
The agent gets its own isolated home. MCP credentials live in
~/.airlock/secrets.toml, never in the repo.Why it exists
Agents are increasingly run with permissions skipped so they can work without interruption. That is only reasonable if the blast radius is bounded. Airlock makes the boundary structural rather than cooperative: a process that ignores proxy settings still has nowhere to go, because the network it is on has no route to the internet.For HTTPS, TLS stays end-to-end between the agent and the provider — the proxy
sees only the hostname. Plain
http:// requests are forwarded by the proxy,
which does see those in the clear.Then: what did it actually read?
Containment bounds the blast radius. It does not tell you what the agent did with the access it legitimately had — and once you connect an internal system, that becomes the question worth asking. So Airlock also publishes agent transcripts to a database you control and serves a local review UI over them: sessions, prompts, tool calls, and returned data, plus the open prediction-market contracts each conversation maps to.Next steps
Quickstart
Install the CLI and open your first sandbox.
CLI reference
Every command, what it does, and when to use it.
Configuration
Policy files, the egress allowlist, mounts, and env passthrough.
MCP connectors
Give the agent scoped access to Notion or Confluence.
Chat audit log
Publish transcripts to Supabase, and the schema they need.
Exposure detection
How a conversation gets mapped to live market contracts.