-
-
AirLock Architecture
Inspiration
Autonomous coding agents can create files, run commands, and interact with external services—but that power raises a difficult question: How can we let an agent work independently without immediately trusting every effect it produces?
A disposable container alone is not enough. Changes to mounted folders can survive after the container exits, credentials may still be exposed, and unrestricted networking can create a path for data exfiltration.
AirLock was inspired by database transactions and information-flow security. Instead of allowing an agent to modify the real project directly, we give every run a temporary environment, inspect its output, and commit only the changes that pass deterministic policy and human review.
We also designed Airlock around the “lethal trifecta”: access to private data, exposure to untrusted content, and unrestricted external communication.
A security breach becomes possible when an agent has all three capabilities at once. Airlock breaks this combination structurally by withholding sensitive files from the Agent Runtime and restricting external traffic to the model gateway, instead of relying solely on the agent to ignore malicious instructions.
What it does
AirLock is a capability-scoped, transactional runtime for autonomous coding agents.
For every task, AirLock:
- Copies the live workspace into an isolated staging area.
- Screens the prompt and classifies staged files before the runtime starts.
- Withholds content above the run’s security clearance.
- Runs Codex inside a restricted, disposable container.
- Calculates the exact files added, modified, or deleted.
- Evaluates those changes using deterministic security rules.
- Displays the proposed changes, triggered rules, runtime policy, and audit timeline.
- Promotes approved changes or completely discards rejected ones.
Sensitive changes—including .env files, credentials, symlinks, path traversal, .git, .codex, and protected instruction files—are rejected automatically. Ordinary source code, tests, and documentation wait for human approval while the real workspace remains unchanged.
AirLock also preserves Agent CRUD, lifecycle controls, asynchronous runs, persistent workspaces, Playground chat, and multi-turn Codex sessions.
How we built it
We built the control plane using Node.js, Fastify, and TypeScript. It coordinates agent lifecycle operations, run state, workspace transactions, policy evaluation, session handling, audit evidence, and approval or rejection decisions.
The interface uses React, Vite, TypeScript, and Motion. Its Playground lets users chat with an agent and inspect genuine execution evidence before deciding whether its work should become permanent.
Every run receives:
- A unique staging workspace
- A private per-agent Codex home
- A read-only container filesystem
- A bounded temporary filesystem
- Resource and execution-time limits
- Dropped Linux capabilities
- A deterministic policy snapshot
- A structured and redacted audit trail
Workspace promotion uses cryptographic digests to detect concurrent changes. Promotion then uses a recoverable rename sequence so a failure does not leave the live workspace partially updated.
For network security, we created an Ark-only egress gateway. Runtime containers operate on an internal network without direct public internet access. They receive a short-lived, HMAC-signed run token instead of the real Ark API key. The gateway validates that token and forwards only supported model requests to Volcengine Ark.
We used deterministic fake runners for middleware tests and reserved the live Ark model for final end-to-end validation.
Challenges we ran into
Our largest challenge was enforcing security at boundaries we genuinely control. Codex operates autonomously inside its runtime, so our application cannot honestly claim to intercept every tool call before it executes. We therefore enforce policy through container mounts, runtime limits, network topology, staged workspaces, and controlled promotion.
Network isolation presented another challenge. The runtime needs to reach the remote model while being prevented from contacting arbitrary destinations. Our gateway solves this by separating model access from general internet access and keeping the real Ark credential outside the Agent container.
Session consistency was also more subtle than expected. A rejected Codex conversation may assume that discarded files still exist. We therefore made the session transactional: approval commits both the files and proposed thread, while rejection discards the files and resets the contaminated session state.
Other challenges included detecting nested protected paths, preventing symlink escapes, safely handling interrupted runs, redacting secrets from evidence, preserving withheld files during promotion, detecting concurrent workspace edits, and supporting Docker and Podman across Linux and WSL2.
Accomplishments that we're proud of
We are especially proud that AirLock provides evidence for its security decisions instead of presenting users with a vague success or failure message.
The review interface shows:
- The exact proposed file changes
- The policy applied to the run
- Triggered ingress and change-control rules
- Whether sensitive content was withheld
- The runtime’s network mode and capabilities
- A correlated audit timeline
- Confirmation that the live workspace remains unchanged
We implemented conflict-safe approval, rejection, cancellation, deletion, restart recovery, session rollback, secret redaction, and automatic denial of protected changes.
The current project passes the complete npm run check pipeline: TypeScript validation, production builds, and 101 automated tests across 14 test files. We also validated that a runtime peer cannot access the public internet in Ark-only mode while still being able to reach the controlled gateway.
What we learned
We learned that a container is an execution boundary, but not automatically a persistence or confidentiality boundary. Agent security requires deliberate control over what enters the runtime, what can leave it, and what is allowed to become permanent.
We also learned that deterministic policy and model-based classification should have different responsibilities. Rules enforce known invariants such as protected paths and credential patterns. A model can assist with ambiguous documents, but in AirLock it can only raise a classification—never override or weaken a deterministic security decision.
Most importantly, audit logs are evidence of enforcement, not enforcement themselves. The strongest controls are structural: unavailable credentials, inaccessible mounts, closed network routes, short-lived capabilities, and transaction boundaries the Agent cannot bypass.
What's next for AirLock
AirLock is currently a single-user proof of concept, so our next step is to evolve it into a hardened multi-user platform.
Future improvements include:
- Production identity, authentication, and role-based authorization
- Stronger isolation through microVMs or hardened sandbox runtimes
- A destination-aware network broker for approved package and API access
- OCR and richer classification for scanned or image-based documents
- Support for encrypted and complex archive formats
- Distributed, transactional persistence for multiple control-plane instances
- Configurable organizational clearance and declassification workflows
- Signed audit exports and integration with security monitoring platforms
- Broader adversarial testing against indirect prompt injection and data exfiltration
- Production deployment and observability on Volcengine ECS
Our long-term goal is to make transactional execution a standard pattern for autonomous agents: let them work freely in quarantine, make every important effect reviewable, and commit only what should become real.
Log in or sign up for Devpost to join the conversation.