Saltar al contenido
Menú
¿Lo necesito?Lo que un agente puede alcanzar en tu máquinaCómo funcionaLas capas entre el agente y tu sistemaCompararSandboxes integrados, Docker y VMsConfigurarAbre solo lo que la tarea necesitaSeguridadEl modelo de amenazas y sus límitesDescargarBinarios, checksums y notas de la versiónInstalar
Cómo funciona

Qué pasa cuando escribes ai-jail claude

ai-jail construye una copia pequeña y cerrada de tu sistema, mete tu proyecto dentro y arranca el agente ahí. Las paredes son funciones del propio sistema operativo, así que el agente corre a toda velocidad y no puede apagarlas. En cada arranque, la red está cerrada salvo el host de la API del propio agente, abierta a unos pocos hosts con nombre, o abierta del todo.

Para el ingeniero que quiere saber qué se aplica de verdad. A todos los demás les basta el primer párrafo y la primera imagen.

Qué pasa al arrancar

Tarda un instante, cada vez, y después nada queda corriendo en segundo plano.

↔ Desliza hacia un lado para ver el diagrama completo

ai-jail construye el sandbox desde cero en cada arranque y lo descarta al salir. Solo tu proyecto conserva sus cambios.

Lee tus reglas

ai-jail confía en tu propio archivo ~/.ai-jail. A un archivo .ai-jail dentro del proyecto lo trata como no confiable: ese archivo puede endurecer el sandbox, pero nunca abrirlo. Los flags de la línea de comandos mandan sobre ambos.

Construye el sandbox

ai-jail prepara cada una de las capas de abajo antes de que el agente exista y mapea las toolchains que tienes (mise, cargo, cachés de npm y otras) en solo lectura o en una caché propia de la jaula. Si un archivo de configuración es ilegible o inválido, ai-jail se detiene en lugar de arrancar con reglas más débiles.

Arranca al agente dentro

El agente, y cada script, paquete y servidor MCP que arranca, hereda los mismos muros. Cuando el agente termina, ai-jail también termina.

Todos los flags y claves de config

Tres caminos hacia la red

Cada arranque elige uno de tres modos de red. El modo por defecto es el más estricto: ninguna ruta de salida salvo lo que deja pasar el proxy filtrado, que es el host de la API de un agente conocido en ambas plataformas y, en Linux con las toolchains activadas (lo normal), una lista corta de registries de paquetes. Los otros dos son flags que pasas a propósito.

↔ Desliza hacia un lado para ver el diagrama completo

Apagada es el valor por defecto, con una puerta para el host de la API del propio agente y, en Linux, los registries. Filtrada abre una puerta solo hacia hosts con nombre. Abierta quita el muro del lado de la red.

Apagada

El modo por defecto. El sandbox recibe un namespace de red privado sin ruta de salida, salvo a través del proxy filtrado. Para un agente conocido el proxy deja pasar el host de su propia API, en Linux y macOS, así que un simple ai-jail claude funciona. En Linux, con las toolchains activadas (lo normal), también deja pasar una lista fija de registries de paquetes, así que npm install y cargo build funcionan; en macOS los registries siguen cerrados. --no-network lo deja completamente sin conexión.

Filtrada

--allow-host HOST, repetible. El namespace sigue cerrado; un puente pequeño dentro reenvía el tráfico a un proxy CONNECT fuera, que se conecta solo a los hosts de la lista y sus subdominios. El proxy resuelve cada nombre una sola vez, fuera, y se conecta a la dirección que comprobó. ai-jail define http_proxy dentro, y un programa que lo ignora no llega a ningún lado.

Abierta

--network. El muro desaparece del lado de la red, y el agente puede enviar fuera todo lo que puede leer.

LinuxmacOS
La valla en modo filtradoEl propio namespace de red, más el puente dentro de élUna regla de sandbox-exec que permite conexiones salientes solo al puerto del proxy
DNS dentro del sandboxFalla. El proxy resuelve los nombres fuera.El resolver del sistema no está vallado, así que queda un canal DNS de poco ancho de banda
Los flags, las salvedades y lo que registra el proxy

Las capas, de fuera hacia dentro

ai-jail no confía en que un solo muro aguante por sí mismo. En Linux el agente queda detrás de cinco, cada uno impuesto por el kernel, más dos filtros sobre lo que entra y lo que sale.

↔ Desliza hacia un lado para ver el diagrama completo

Cada muro cubre un posible error del que tiene por fuera.
  1. Namespaces

    bubblewrap
    Qué es
    Un namespace es el kernel dándole a un proceso su propia vista privada del sistema. ai-jail le pide a bubblewrap que los cree, la misma herramienta pequeña que Flatpak usa para aislar aplicaciones de escritorio, y no necesita root.
    Qué detiene
    El agente recibe su propia lista de procesos, su propio hostname (ai-sandbox), ningún canal entre procesos hacia los programas del host y un namespace de red sin salida, salvo que abras una con --allow-host o --network. Si ai-jail muere, todo lo que hay dentro muere con él.
  2. Sistema de archivos

    montajes
    Qué es
    Dentro del namespace solo existe lo que ai-jail monta. El proyecto está en lectura y escritura en su ruta real, los directorios del sistema como /usr están en solo lectura, y el directorio home y /tmp son nuevos y viven en memoria. Las toolchains que tienes (mise, cargo, cachés de npm) se mapean en ese home nuevo, en solo lectura o como una caché propia de la jaula.
    Qué detiene
    ~/.ssh, ~/.aws, ~/.gnupg, ~/.docker y los perfiles del navegador están en una lista integrada que nunca se monta. El directorio de estado del propio harness, por ejemplo el ~/.claude de Claude, es la excepción: ai-jail lo monta en lectura y escritura por defecto para que el agente arranque con la sesión iniciada, y --no-agent-state lo deja fuera. Todo lo que se escribe fuera del proyecto desaparece cuando termina la sesión.
  3. Landlock

    kernel 5.13+
    Qué es
    Landlock es una función del kernel de Linux que permite a un proceso renunciar para siempre al acceso a archivos. ai-jail la usa para repetir las reglas del sistema de archivos como una segunda lista de permitidos dentro del kernel.
    Qué detiene
    Un error o un truco en la capa de montajes no basta para llegar a una ruta fuera de la lista, y lo que es de solo lectura sigue siéndolo. En kernels 6.12 o más nuevos también valla los sockets Unix abstractos y las señales, en modo best-effort. En kernels demasiado antiguos para Landlock, ai-jail lo avisa y continúa con las demás capas.
  4. seccomp

    llamadas al sistema
    Qué es
    Los programas le piden cosas al kernel mediante llamadas al sistema (syscalls). seccomp es un filtro sobre esas llamadas, y ai-jail lo usa para rechazar las que un agente de programación nunca necesita.
    Qué detiene
    El filtro bloquea ptrace, mount, bpf, los módulos del kernel, io_uring, el keyring del kernel, los sockets raw y TIOCSTI, una llamada que puede escribir pulsaciones de teclas en tu terminal. Es una lista de bloqueo a propósito, para que los compiladores y runtimes sigan funcionando. El único proceso que arranca antes de que se apliquen Landlock y seccomp es el pequeño puente que saca el tráfico de red filtrado, así que solo él queda sin restricciones.
  5. Límites de recursos

    rlimits
    Qué es
    Topes que el kernel impone a cuánto puede usar un árbol de procesos: 4096 procesos y 65 536 archivos abiertos, con los core dumps desactivados. El modo lockdown los baja a 1024 y 4096.
    Qué detiene
    Una fork bomb o un script desbocado chocan con el techo dentro de la jaula en lugar de congelar tu máquina. El agente no puede volver a subir los límites.
  6. Lista de permitidos del entorno

    lo que entra
    Qué es
    Tu shell está llena de variables, y algunas son claves de API. ai-jail limpia el entorno y pasa solo una lista corta: PATH, HOME, TERM, el locale y los ajustes de proxy y de certificados.
    Qué detiene
    Los tokens y las credenciales de la nube exportados en tu shell nunca llegan al agente, salvo la clave de API del propio harness que arrancas, por ejemplo ANTHROPIC_API_KEY para Claude, que se copia por defecto junto con su login; --no-agent-state lo impide. Dejas pasar otra por su nombre con --env cuando una tarea lo necesita.
  7. Proxy de terminal

    lo que sale
    Qué es
    El agente corre detrás de su propia pseudoterminal, y lo que imprime pasa por un parser de terminal antes de llegar a tu pantalla. El mismo proxy dibuja la barra de estado de ai-jail en la última fila.
    Qué detiene
    El proxy filtra las secuencias de escape que tocan tu portapapeles o consultan tu terminal. Dentro de tmux o zellij se desactiva solo, porque las terminales anidadas se pelean por el redimensionado.

En macOS el muro es más delgado

macOS no tiene namespaces, Landlock ni seccomp. ai-jail convierte la misma política en un perfil para sandbox-exec, el sandbox integrado de Apple. La documentación de ai-jail dice claramente que esto no equivale al aislamiento de Linux.

↔ Desliza hacia un lado para ver el diagrama completo

macOS recibe la misma política y los mismos flags detrás de menos muros.
LinuxmacOS
Backendbubblewrap, y luego Landlock, seccomp y límites de recursossandbox-exec con un perfil generado en cada arranque. Apple lo marcó como obsoleto, y no existe nada mejor sin extensiones del kernel.
Directorio homeUn home nuevo en memoria. El real no está montado.El perfil parte sin lecturas globales y luego permite solo las rutas que el agente necesita, así que tu home real sigue cerrado.
/tmpPrivado, se descarta al salirEl /tmp del host, porque no hay namespace de montaje. TMPDIR apunta a una carpeta privada creada para ese arranque, y esa es la única ruta temporal concedida.
Mapeos copy-on-write--overlay-map deja que el agente escriba en una copiaSe trata como un mapeo de solo lectura
RedCerrada por defecto: ninguna ruta de salida salvo el host de la API de un agente conocido y los registries de paquetes permitidos cuando las toolchains están activadas. --allow-host o --network abren más, --forward-port reenvía un puerto del loopback del host, --no-network cierra todo. Bajo --lockdown la red abierta siempre se bloquea, incluso con --network.El mismo valor por defecto y los mismos flags, incluido el host de la API del agente conocido, pero sin --forward-port, los registries ni los mapeos de caché de toolchains, que son solo para Linux. Lockdown también bloquea aquí la red abierta.
Otros programasInvisibles: lista de procesos propia, sin IPC del hostMach, IOKit y el IPC del host están denegados salvo que pases --macos-host-ipc

Por qué estas piezas

ai-jail escribe el mínimo posible de código de seguridad propio. Maneja bubblewrap, que es pequeño, está empaquetado en todas las distribuciones importantes y Flatpak lo pone a prueba a diario, y le suma funciones del kernel.

OpciónPor qué no
FirejailPuede hacer el trabajo, pero es un binario setuid root, y varios CVE vienen de ese diseño. bubblewrap funciona sin root.
Reescribir bubblewrap en RustMás de 500 líneas de código sensible para la seguridad que mantener y parchear en solitario, para evitar una dependencia de unos 50 KB que recibe correcciones de upstream.
nsjailEs capaz, pero está pensado para servidores, se maneja con archivos de configuración protobuf y está empaquetado en menos sitios.
systemd-nspawnRequiere systemd, así que falla dentro de contenedores y en sistemas que no lo tienen.

Leer la evaluación completa

Tan pequeño que se puede leer

Toda la herramienta es un solo programa síncrono en Rust, sin runtime async, daemon ni imagen de contenedor.

1
binario que instalar
11
dependencias directas
959
tests unitarios en el código
23
tests que intentan escapar de un sandbox real

Dependencias contadas en el repositorio de ai-jail en la versión 2.9.0; tests en la versión 2.9.0.

Pon a tu agente tras las rejas

ai-jail es un único binario que no necesita daemon ni root. Añades una palabra delante del comando que ya usas.

terminal
brew tap akitaonrails/tap && brew install ai-jailai-jail claude