AIRLOCK

Nada llega a producción sin pasar por la esclusa.

Una consola de control de cambios para trabajo de producción irreversible. Cada cambio peligroso —una migración de esquema, una corrección masiva de datos, una solicitud de derecho al olvido, un reembolso, una concesión de acceso a producción, cuarenta mil correos— se solicita en inglés, se ejecuta primero contra una copia sombra del sistema real, se prueba en un sandbox y solo entonces se presenta a una persona para su aprobación, con la evidencia adjunta.

Construido sobre TrueForge para el Agent Harness Hackathon, del 24 al 30 de agosto de 2026.

La idea en una sola regla

La frase de cierre de TrueFoundry en la página del hackathon es "construye el agente con el que confiarías el root". AIRLOCK es la respuesta literal: un agente que se comporta como si no se le confiara el root, y lo demuestra cada vez antes de preguntar.

Cualquier otra compuerta de aprobación es «el agente dice que va a hacer X — clica en aceptar». Eso pide a una persona que confíe en un plan. La compuerta de AIRLOCK no puede ofrecerse hasta que el agente haya producido un certificado, y hay dos tipos:

El Certificado de Deshacer — para cambios reversibles. El agente aplica el cambio a una rama sombra, aplica su propio rollback, recalcula los checksums una tercera vez y demuestra que los datos volvieron a su estado inicial byte a byte. El cambio ya lo hizo, y lo deshizo, y aquí están los checksums que coinciden. Ahora sí puede pedir.

El Certificado de Alcance — para cambios genuinamente irreversibles. No puedes probar que un borrado es reversible, así que el agente prueba lo contrario: exactamente qué será destruido, en todos los sistemas, y nada más — además de una lista explícita de exclusiones sobre lo que deliberadamente no toca y por qué. No puede prometerte que puedas deshacerlo. Puede prometer que él sabe exactamente qué quiere decir «esto».

certificate.status !== "PROVEN"  →  the approval gate is never offered.

No atenuado. Sin aviso. Nunca se renderiza.

Esa regla es un tipo, no un if

El control de aprobación acepta un ApprovalGrant. ApprovalGrant lleva un símbolo privado del módulo que solo openGate() puede acudir, de modo que no existe ningún valor que un desarrollador pueda pasar para aprobar un cambio sin probar — ni por error, ni a propósito sin editar la propia compuerta.

// packages/contract/src/gate.ts
const GATE_WITNESS: unique symbol = Symbol('airlock.gate.witness');

export interface ApprovalGrant {
  readonly [GATE_WITNESS]: true;   // unforgeable outside this module
  readonly irreversible: boolean;
  readonly seals_required: number;
  readonly final: boolean;
  // …
}

Seis intentos de falsificarlo se afirman como errores de compilación en gate.typetest.ts. Si alguien debilita el tipo, los errores esperados desaparecen, tsc reporta un @ts-expect-error sin uso, y la compilación falla.

La misma regla se ejecuta también en el servidor. Aprobar a través de la API HTTP, sin que un navegador esté de por medio, se rechaza de forma idéntica:

$ curl -XPOST localhost:3000/api/dossiers/dos_currency_fix/decision -d '{"decision":"approved"}'
{"error":"CERTIFICATE_FAILED","message":"Verification ran and failed. This change cannot be approved from this dossier."}
403

$ # …and a dossier that lies, claiming match:true with checksums that differ:
{"error":"CHECKSUM_MISMATCH","message":"The data did not return to its starting state after rollback."}
403

AIRLOCK nunca confía en la bandera match del propio verificador. Recalcula por sí mismo pre === post_rollback, de modo que un fallo del motor o una carga falsificada no pueden abrir la compuerta.

Pruébalo sin instalar nada. La página de entrada incluye una compuerta en vivo: construye un dossier de cambio real a partir de un conjunto de controles y lo pasa al openGate() real. Cada combinación es una evaluación genuina. A ver si encuentras alguna que abra una puerta que no debería.

Related MCP server: mcp-nixreview

Ejecución

git clone https://github.com/Rohit-ATS/Airlock && cd Airlock
npm install
npm run build --workspace @airlock/contract
npm run dev --workspace @airlock/console

La consola se siembra a sí misma desde contracts/examples/ en el primer arranque, así que aterrizas en una cola de aprobaciones en vivo con once cambios reales — dos listos para validar, seis sellados por seis motivos distintos, y tres historiales decididos sellados en una cadena de hash — sin base de datos, sin clave de API y sin registro.

Esos once cambios son fixtures de consola. Ejercitan la tarjeta de certificado, la cola, el motor de políticas y el registro. No son evidencia sobre la base de datos de nadie, y los no decididos se reanclan a la hora actual cuando se siembran, porque un certificado tiene una ventana de validez y una demo caducada para siempre no demuestra nada. Con AIRLOCK_NO_SEED=1 arranca vacía.

Para conducir el agente en lugar de los fixtures, apúntalo a un servidor TrueForge:

npx @truefoundry/trueforge@latest              # http://localhost:8790
NEXT_PUBLIC_TRUEFORGE_BASE_URL=http://localhost:8790 npm run dev --workspace @airlock/console

En Windows, usa Docker. TrueForge 0.1.4 no arranca de forma nativa en Windows (Only URLs with a scheme in: file, data, and node are supported… Received protocol 'c:'), y las opción de sandbox local solo puede en macOS/Linux. Consulta docs/TRUEFORGE-NOTES.md.

Lo que evalúa un juez

El agente tiene exactamente una única puerta

AIRLOCK se distribuye como un servidor MCP (packages/mcp). Alscriberlo es lo que hace que el principio de mínimo privilegor sea estructural y no solo una aspiración:

{ "name": "airlock",
  "command": "npx", "args": ["-y", "@airlock/mcp"],
  "enable_tools": ["@all"],
  "require_approval_for_tools": ["airlock_request_approval"] }

El agente puede leer la política, abrir un cambio, adjuntar una prueba y preguntar a una persona. Ese es el conjunto completo de verbos que tiene. No existe ninguna herramienta que aplique una modificación a producción, y la única herramienta que hace avanzar un cambio está en manos del motor hasta que una persona responda.

Los conectores de producción se montan como @read-only junto a él, y como los subagentes de TrueForge heredan el ámbito MCP del agente raíz, la garantía se extiende automáticamente a todos los subagentes: ningún principal de la ejecución puede alcanzar una persona. producción sin que una persona, una. Eso se comprueba en CI mediante scripts/check-agents.mjs, así que no puede desviarse.

Siete clases de cambios

La prueba de admisión no es «¿es una escritura de base de datos?» sino «si esto sale mal, ¿puedes revertirlo?». Enviar cuarenta mil correos es tan irreversible como implementar una columna, y considerablemente más difícil de pedir perdón.

La política: la segunda pregunta

El certificado de responde a «¿este cambio es lo que dice ser?». La política responde a otra: *«¿Este cambio está permitido en absoluto, quién y ahora mismo?». Una prueba no puede responder a esa pregunta, porque no es una propiedad del cambio — es una propiedad de la organización.

Ambas se evalúan con el mismo openGate, así que un cambio que está genuinamente probado y no está permitido se sella por la segunda razón y se le comunica exactamente por qué. Detalle completo en docs/ POLÍTICA.md, generado a partir de la política para que ambas no puedan discrepar.

Cuatro reglas que merece la pena destacar:

• Una prueba es una mercancía perecedera. Pasada la ventana de validez, un certificado describe un sistema que ya no existe. Diez minutos para una concesión de acceso; treinta para una migración.

• Deriva de producción. Antes de abrir la compuerta, AIRLOCK vuelve a hacer checksums de la produzione contra el estado todos el archivo sustained by a holographic. tomo la prueba. Si otra migración ha aterrizado entre medio, el cambio se sella — incluso cuando el propio verificador informó de que todo era correcto. El riesgo se toma en serio; la seguridad se verifica de nuevo.

• El quórum cuenta personas, no clics. Las firmas se almacenan por identidad, de modo que la misma persona firmando dos veces cuenta como una sola — y la persona que solicitó el cambio nunca puede ser una de las personas del quórum.

• No prometer necessarily access. Cada concesión debe tener una caducidad, de modo que acceso privilegiado en gestión.

estado por defecto es que nadie tiene las llaves.

El registro es a prueba de manipulaciones

Un sistema de control de cambios cuyo registro de auditoría es editable es teatro de control de cambios. Cada cambio ya decidido se sella con el hash del anterior, así que editar cualquier registro histórico rompe todos los eslabones posteriores:

$ npm run verify:ledger
  ok  #000  dos_orders_index         a41f9c02be7d8e5f31c4…
  FAIL #001  dos_gdpr_batch          9e02cc71a4bb0d3f2871…
         fault      : content-modified
FAIL — the chain breaks at record 1. Every record after that point is no longer trustworthy.

Esto no hace el registro infalsable — cualquiera que pueda reescribir el archivo puede recalcular la cadena entera. Lo que realiza puede es: la manipulación sea visible para cualquier persona que tenga una copia antigua de un solo hash, lo cual es la que protectiona import, porque quien te audita no es quien la editar.

Los recibos individuales se separan y se verifican a su cuenta, sin acceso a la consola: GET /api/dossiers/{id}/receipt → node scripts/verify-ledger.mjs receipt.json.

La página de entrada lleva esto en el navegador. Reescribe un registro y observa cómo se rompe la cadena.

La consola de tres zonas

La rúbrica de Savile Row pide una interfaz que presente lo que el agente qué está haciendo, qué espera y qué hizo — y pide permiso antes del paso irreversible. Pues estas son las tres zonas, así nombradas exactamente.

• DOING — la ejecución en directo: dephatches de subagentes en secundario, cada subagente con su modelo y coste de ejecución, el registro del sandbox depende de ello, las llamadas a herramientas seestán resolviendo en tiempo real.

• WAITING — la cola de aprobaciones: cada cambio que esperando a una persona, qué bloquea esa persona, cuántas firmas necesita aún, y cuánto esperano ya ha pasado.

• DID — el registro de cambios inmutable: quién solicitó, quién aprobadores, qué certificado, qué checksums, y el recibo del que lo sella.

La sala de control

/control es para el otro tipo de público. La pregunta no es "¿apruebo este cambio?" sino "¿Qué sostiene este sistema, qué ha rechazado, y puedo seguir confiando en sus registros de lo que hizo?"

La cifra principal es lo que la compuerta rechazado, no lo que ha aprobado — una cola vacía no jardín de prueba de seguridad; pero sí lo es una cifra de cambios detenidos con sus motivos. También verifica de nuevo el registro en el navegador, sin fiarse de un servidor que polássegura que todo está bien.

El panel del Harness

Un panel persistente con todas las 22 capacidades de TrueForge. Cada capacidad está apagada hasta que un evento real del harness la demuestre, y solo entonces se enciende, con una marca de tiempo agrega y un enlace al paso que lo demuestra.

Una lámpara no puede encenderse desde el código de la aplicación. El único escritor para ellos es detectors.ts, alimentado por un observador de habla censión in at surface.— envolver alrededor del flujo de eventos de TrueForge en observedServer.ts. Los eventos se observan y de pasan sin modificar — nunca se sintetizan, reordenruo nor editanatch. Un run de ejecución que no ejerza una capacidad se queda por encima de 22, y ese es el resultado correcto.

Las filas apagadas continúan siendo legibles a propósito. Esconder lo que no ocurrió haría que el contador no significara nada; mostrarlo es lo que da cresta a las que están encendidas. En the información que lo ha probado, no lo han hecho. página de destino todos los indicadores están apagados, porque allí no ha habido ninguna ejecución.

Véase docs/CAPABILITIES.md — generado desde el registro, y asi lo que afirmamos y lo que el panel puede demostrar no puede divergir.

La tarjeta de certificado

El permiso.

Una tarjeta de expedición—banner con el veredicto, magnitud, política aplicada y sus objctos, firmas, operaciones de avo y de rollback lado a lado, las tablas afectadas con los counts reales y el perfil de bloqueo y de reescritura de la tabla, la cadena completa de checksums, la comprobación de deriva de la puesta en marcha, impacto sobre el código, la lista de exclusiones, el coste de ejecución por modelo, el recibo y la decisión.

El triple de checksum es el argumento en hora visible: las líneas 1 y 3 se encasillan juntas, la línea 2 está deliberadamente menos énfasis porque se espera que sea diferente, y si hay un desajuste se reserva exactamente el carácter y el párrafo.— es last-div:

resalte el carácter exacto en que el que los hash difieren en lugar de imprimir una X roja.

Break-glass

Si

Controlada por política, desactivada por defecto, y no abre la puerta: BreakGlassOverride lleva un símbolo privado distinto de ApprovalGrant, y ninguna función acepta ambos. Lo que hace es registrar, permanentemente, que un humano identificado por su nombre saltó una puerta sellada, con una razón escrita de al menos 40 caracteres, en la misma cadena de hashes que todo lo demás.

El argumento para tenerla: la gente lo hace de todos modos. En toda organización llega un momento en que la ruta segura no está y alguien abre una sesión de psql en su lugar. Un plano de control que finge lo contrario no evita la anulación — solo garantiza que no quede registro de ella. Se requieren dos interruptores para activarla, y ERASURE, MONEY_MOVEMENT y COMMS_BLAST la prohíben sin discusión.

Arquitectura

contracts/dossier.schema.json     the Change Dossier — the one contract everything shares
packages/contract/                types, the gate, policy, receipts, capabilities, detectors
  src/gate.ts                     the invariant, as an unforgeable type
  src/policy.ts                   quorum, ceilings, freshness, freezes, no standing access
  src/receipt.ts                  the tamper-evident hash chain, isomorphic
  src/detectors.ts                the ONLY thing that can light a lamp
  src/capabilities.ts             the 22, each with its load-bearing use and its evidence
packages/mcp/                     AIRLOCK as an MCP server — the agent's one doorway
apps/console/                     Next.js 15, React 19, Tailwind v4
  app/page.tsx                    the landing page
  app/console/                    the three-zone operator console
  app/control/                    the control room
  src/server/observedServer.ts    the passthrough tap on the real TrueForge stream
agents/                           four agent specs: least privilege, model routing
skills/                           seven skill packs, one per domain the agent must not improvise

La consola es el SDK. TrueForgeUI acepta un componente de diseño (layout) personalizado renderizado dentro de su propia pila de proveedores, por lo que AIRLOCK se pasa como layout={AirlockConsole}: la transcripción, el compositor, la lista de hilos, las tarjetas de aprobación de herramientas, las tarjetas de pregunta al usuario y la pantalla OAuth de MCP son componentes propios de @truefoundry/trueforge-ui, re-tematizados. No es un clon de apariencia construido a su lado.

Notas sinceras

Tres cosas del plan original resultaron depender de una API que no existe, y están construidas de otra manera en lugar de fingirse. Detalles completos en docs/TRUEFORGE-NOTES.md §4.

1. Los subagentes son dinámicos, no declarados. TrueForge los genera en tiempo de ejecución mediante create_sub_agent; la especificación no tiene un bloque por subagente. Así que «cuatro subagentes nombrados, cada uno con su propio ámbito de herramientas», no es implementable.

2. El ámbito de herramientas por subagente no existe. La documentación es explícita: «los subagentes tienen acceso a las mismas herramientas MCP y al mismo entorno sandbox que el agente raíz». AIRLOCK, en su lugar, aplica el menor privilegio en el límite del agente: conectores de producción montados con @read-only y única vía hacia delante es una herramienta de nuestro propio servidor MCP que sujeta el harness. Dado que los subagentes heredan ese ámbito, ningún participante en la ejecución puede tocar producción sin un humano. Esa es una afirmación más fuerte que una caja de herramientas más pequeña, y es real.

3. El enrutamiento de modelo por subagente tampoco existe. El enrutamiento es real en el límite del agente — véase airlock-scout, airlock-privacy y airlock-treasury — y el modelo y el coste mostrados por carril se leen de la fuente real thread.created.agentInfo.model y de los bornes turn.done.state.metrics.total_cost_in_usd.

Tres detectores de capacidades dependen de señales que no pudimos confirmar en la documentación: el nombre de la herramienta Code Mode, el marcador de descarga de resultados grandes y si se emite un evento de compactación. Se listan como no verificados. Si un ejecución real no los prueba, esas lámparas se quedan oscuras y el denominador baja. Un 19/19 honesto vale más que un 22/22 recortado que un juez desmiente con un clic en una lámpara.

Dos errores encontrados en el upstream

• @truefoundry/trueforge-ui@0.2.4 tiene un conflicto de dependencias: @assistant-ui/core depende como peer de zustand@^5 mientras que los renderizadores de OpenUI usan zustand@^4, que npm eleva. La compilación falla con 'useShallow' is not exported from 'zustand/shallow'. Lo solucionamos con un bloque overrides en la raíz package.json.

• Su styles.css distribuye un conjunto completo de utilidades Tailwind en el layer @layerShaft @layer tfy-agent-ui-utilities. Importado después de tailwindcss, esa capa se registra más tarde, así que el .hidden simple de este SDK le gana your .xl\:flex sin importar la media query — rompiendo silenciosamente cada variante responsive de la app anfitriona. Se corrige con una sentencia explícita de orden de @layer en globals.css.

Pruebas

npm test        # 92 tests, 11 fixtures, 4 agent specs

Cuatro suites, y cada una fija una propiedad en lugar de una implementación:

Dos comprobaciones estructurales que se ejecutan en CI:

• check-fixtures.mjs — cada fixture se parsea contra el contrato y produce el veredicto de puerta que su nombre de archivo implica, por lo que un fixture llamado .parado .standby.json de justice es rechazado porque no tiene fecha de espera, no porque nadie reparó en otro motivo.

• check-agents.mjs — ningún conector de producción es escribible; y cualquier agente que pueda escribir en algún lugar exige AIRLOCK se monte y sostiene exactamente una herramienta para aprobación.

Los artefactos generados artefactos (contracts/dossier.schema.json, docs/CAPABILITIES.md, docs/POLICY.md, las fixtures) salen de npm run gen y son idempotentes, de modo que lo que la documentación afirma y lo que el código hace no pueden separarse.

Equipo

Rohit Maruri — la consola, la landing page, la sala de control, el panel de Harness, la tarjeta de certificado, el gate, el motor de políticas, el registro mayor a prueba de no manipulación, el servidor de MCP, las definiciones y concesiones de agentes, el contrato, el webhook y las funciones. Damir — el motor de comprobación, el ciclo de vida de la shallow branch, el cálculo del scope y los datos de semilla.

Licencia MIT.Controlada por política, desactivada por defecto, y no abre la puerta: BreakGlassOverride lleva un símbolo privado distinto de ApprovalGrant, y ninguna función acepta ambos. Lo que hace es registrar, de forma permanente, que un humano identificado por su nombre saltó una puerta sellada, con una razón escrita de al menos 40 caracteres, en la misma cadena de hashes que todo lo demás.

El argumento para tenerla: la gente lo hace de todos modos. En toda organización llega un momento en que la ruta segura no está disponible y alguien abre una sesión de psql en su lugar. Un plano de control que finja lo contrario no evita la anulación — solo garantiza que no quede registro de ella. Se requieren dos interruptores para activarla, y ERASURE, MONEY_MOVEMENT y COMMS_BLAST la prohíben sin discusión.

Arquitectura

contracts/dossier.schema.json     the Change Dossier — the one contract everything shares
packages/contract/                types, the gate, policy, receipts, capabilities, detectors
  src/gate.ts                     the invariant, as an unforgeable type
  src/policy.ts                   quorum, ceilings, freshness, freezes, no standing access
  src/receipt.ts                  the tamper-evident hash chain, isomorphic
  src/detectors.ts                the ONLY thing that can light a lamp
  src/capabilities.ts             the 22, each with its load-bearing use and its evidence
packages/mcp/                     AIRLOCK as an MCP server — the agent's one doorway
apps/console/                     Next.js 15, React 19, Tailwind v4
  app/page.tsx                    the landing page
  app/console/                    the three-zone operator console
  app/control/                    the control room
  src/server/observedServer.ts    the passthrough tap on the real TrueForge stream
agents/                           four agent specs: least privilege, model routing
skills/                           seven skill packs, one per domain the agent must not improvise

La consola es el SDK. TrueForgeUI acepta un componente de diseño (layout) personalizado renderizado dentro de su propia pila de proveedores, por lo que AIRLOCK se pasa como layout={AirlockConsole}: la transcripción, el compositor, la lista de hilos, las tarjetas de aprobación de herramientas, las tarjetas de pregunta al usuario y la pantalla OAuth de MCP son componentes propios de @truefoundry/trueforge-ui, retematicados. No es una réplica visual construida aparte.

Notas sinceras

Tres cosas del plan original resultaron depender de una API que no existe, y se construyeron de forma distinta en lugar de fingirlas. Detalles completos en docs/TRUEFORGE-NOTES.md §4.

1. Los subagentes son dinámicos, no declarados. TrueForge los crea en tiempo de ejecución mediante create_sub_agent; la especificación no tiene un bloque por subagente. Así que «cuatro subagentes nombrados, cada uno con su propio ámbito de herramientas», no es implementable.

2. El ámbito de herramientas por subagente no existe. La documentación es explícita: «los subagentes tienen acceso a las mismas herramientas MCP y al mismo entorno sandbox que el agente raíz». AIRLOCK, en su lugar, aplica el menor privilegio en el límite del agente: conectores de producción montados con @read-only y una única vía de avance a través de una herramienta de nuestro propio servidor MCP que sujeta el harness. Dado que los subagentes heredan ese ámbito, ningún participante en la ejecución puede tocar producción sin un humano. Esa es una afirmación más fuerte que un conjunto de herramientas más pequeño, y es real.

3. El enrutamiento de modelo por subagente tampoco existe. El enrutamiento sí es real en el límite del agente: ver airlock-scout, airlock-privacy y airlock-treasury. El modelo y el coste mostrados por carril se leen de thread.created.agentInfo.model y turn.done.state.metrics.total_cost_in_usd.

Tres detectores de capacidades dependen de señales que no pudimos confirmar en la documentación: el nombre de la herramienta Code Mode, el marcador de descarga de resultados grandes y si se emite un evento de romaje. Quedan clasificados como sin verificar. Si una ejecución real no los justifica, esas lámparas se quedan oscuras y el denominador baja. Un 19/19 honesto vale más que un 22/22 inflado que un juez pueda desmentir con un clic en una trampa.

Dos bugs detectados en el upstream

• @truefoundry/trueforge-ui@1.4.4 introduce un conflicto de dependencias: @assistant-core requiere como peer zustand@^5, mientras que los renderizadores de OpenUI arrastran zustand@^4, que npm eleva y resuelve. La compilación falla con 'useShallow' is not exported from 'zustand/shallow'. Se resolvió con un bloque overrides en el package.json raíz.

• Su styles.css incluye un conjunto completo de utilidades Tailwind dentro de @layer tfy-agent-ui-utilities. Al importarse después de tailwindcss, esa capa se registra más tarde, por lo que el .hidden simple del SDK le gana a tu .xl\:flex sea cual sea la media query — fure rompe silenciándote cada variante responsive del host. Corregido con la sentencia explícita de orden en globals.css.

Pruebas

npm test        # 92 tests, 11 fixtures, 4 agent specs

Cuatro suites, y cada una asegura una propiedad, en vez de un comportamiento concreto:

Dos comprobaciones estructurales se suman en CI:

• check-fixtures.mjs — cada fixture parsea contra el contrato y produce el veredicto de puerta que implica su filename; así, un fixture llamado .parado verdaderamente se rechazará por ausência de expiración, no porque el sistema no interpreta otra cosa.

• check-agents.mjs — ningún conector de producción es escribible, y cualquier agente que pueda escribir en algún lugar monta AIRLOCK y conserva exactamente una herramienta para el approval.

Los artefactos generados (contracts/dossier.schema.json, docs/CAPABILITIES.md, docs/POLICY.md, as fixtures) proceden de npm run gen y son idempotentes, de modo que lo que los docs declaran y lo que hace el código no pueden divergir.

Equipo

Rohit Maruri — la consola, el landing page, la sala de control, el panel de Harness, la tarjeta de certificado, la puerta, el policy engine, el led aval, el registro sellado, el servidor MCP, las definiciones y skills de los agentes, el contrato, el webhook y los roles. Damir — el motor de verificación, el ciclo de vida de la rama intermedia, la computación de scope y los datos de partida.

Licencia MIT.