Imagina contratar a un empleado genial que trabaja 24 horas al día, nunca se queja y resuelve tareas en minutos. Solo hay un detalle: en su primer día, recibe la llave de todas las salas de la empresa. Del cofre, del archivo de RRHH, de la sala de servidores. Nadie haría eso con un humano, por bueno que sea el currículum. Y sin embargo, eso es exactamente lo que la mayoría de las personas hace cuando instala un agente de IA en la computadora: le da acceso a todo y espera que salga bien.
Este post presenta el ai-jail, una herramienta gratuita y de código abierto creada por el brasileño Fabio Akita, uno de los ingenieros de software más respetados del país. La propuesta de esta herramienta cabe en una frase: poner al agente de IA en una jaula donde pueda trabajar, pero no pueda causar daños. Entenderás por qué esto se convirtió en un requisito obligatorio para quienes usan agentes, cómo funciona la jaula por dentro y cómo usarla en la práctica, incluso sin ser de la zona técnica. Al final hay una lista de verificación con los comandos listos.
El agente necesita acceso, y el acceso es el problema
Agentes de IA que trabajan de verdad (como Claude Code, Codex y similares) no solo charlan: leen archivos, crean documentos, ejecutan comandos, instalan componentes. Eso es lo que los hace útiles. Un agente sin acceso a la computadora es solo un chat bonito.
El problema es que el mismo acceso que permite crear un informe permite leer las contraseñas guardadas en el navegador, copiar las claves que dan entrada a los servidores de la empresa y borrar carpetas enteras. El agente no necesita ser malicioso para causar daño. Basta con una instrucción ambigua, un momento de confusión del modelo, y el comando incorrecto se ejecuta en la carpeta incorrecta. Esto no es una hipótesis: ya hemos contado aquí el caso del modelo de IA que borró archivos solo, sin que nadie se lo pidiera.
Y existe un segundo riesgo, más silencioso. Los agentes instalan componentes de terceros todo el tiempo, es parte de su trabajo. Si uno de esos componentes viene adulterado (lo que sucede con frecuencia creciente en el mundo del software), el código malicioso se ejecuta dentro de tu computadora con los mismos permisos del agente. Es como un proveedor que entrega una pieza saboteada dentro de tu fábrica: el problema no entró por la puerta principal, entró con la mercancía.
Es decir: necesitas dar acceso para que el agente trabaje, pero cada acceso adicional es una superficie de riesgo. La pregunta correcta no es "¿confío en el agente?", sino "¿qué pasa si se equivoca?".
¿Qué es el ai-jail?
El ai-jail es un programa pequeño (menos de 1 MB) que funciona como un portero riguroso. En lugar de abrir el agente de IA directamente, abres el agente a través del ai-jail. A partir de ahí, el agente ve una computadora diferente a la tuya: una computadora donde solo existe la carpeta del proyecto en el que debería trabajar.
La mejor analogía es una sala de reuniones con vidrio. El consultor externo entra, recibe solo los documentos de ese proyecto y trabaja tranquilo dentro de la sala. No circula por el edificio, no abre cajones de otros departamentos ni sabe dónde está el cofre. Cuando la reunión termina, la sala se limpia por completo. Todo lo que produjo de útil queda en el expediente del proyecto; cualquier papel que haya esparcido fuera de allí va a la trituradora.
El punto más importante: no es una regla que el agente promete seguir, es una pared que no puede atravesar. La restricción sucede en el nivel del sistema operativo, debajo de la IA. No depende de que el modelo sea obediente, y eso es lo que diferencia este enfoque de simplemente escribir "no toques otras carpetas" en las instrucciones del agente. Como ya hemos mostrado en guardrails no son suficientes, la instrucción es un pedido; la pared es una garantía.
Qué es lo que la jaula esconde y qué es lo que permite
Por defecto, el ai-jail organiza la computadora en tres zonas:
No entran en la sala. Las claves de acceso a servidores, las credenciales de servicios en la nube, los datos del navegador. Para el agente, esos archivos simplemente no existen. No los ve, no los lee ni puede copiarlos, porque dentro de la jaula no están.
Visible, pero intocable. Los programas del sistema están disponibles solo para lectura. El agente puede usar las herramientas de la computadora, pero no puede alterarlas ni romperlas.
Libre. La carpeta del proyecto actual es el único lugar donde el agente escribe de verdad. Es su mesa de trabajo. Todo lo que produce de útil queda allí.
Y está el detalle de la mesa limpia: áreas temporales se crean nuevas en cada sesión y se destruyen cuando el ai-jail cierra. Si el agente esparció archivos fuera del proyecto, eso se evapora al salir.
Un cuidado que el propio autor destaca: archivos de contraseña que viven dentro de la carpeta del proyecto (el famoso archivo .env, donde muchos sistemas guardan credenciales) siguen visibles, porque están en la mesa de trabajo. Para esos, existe un comando específico que los enmascara, y está en la lista de verificación al final.
Cómo usar en la práctica
La instalación es una línea en la terminal (funciona en Mac y Linux; en Windows funciona a través de WSL, el entorno Linux que Microsoft incluye en el sistema). Quien ya usa el administrador Homebrew instala con un solo comando.
Y el uso diario cambia casi nada en la rutina: en lugar de abrir el agente escribiendo claude, escribes ai-jail claude. Solo eso. El agente se abre normalmente, trabaja normalmente, y ni siquiera se da cuenta de que está en una jaula. Lo mismo vale para otros agentes: ai-jail codex, ai-jail opencode y así sucesivamente.
Tres recursos merecen destaque para quien está empezando:
- Ensayo sin riesgo: el comando con
--dry-runmuestra exactamente qué es lo que la jaula va a esconder y permitir, sin ejecutar nada. Bueno para revisar antes de confiar. - Máscara de contraseñas:
--mask .envesconde los archivos de credenciales que viven dentro del proyecto. El agente ve un archivo vacío en su lugar. - Modo candado:
--lockdownes el modo más restrictivo, donde el agente no escribe en ningún lugar y se queda sin red. Es el modo correcto para analizar código que viene de fuera y en el que no confías.
Y lo mejor para el día a día de equipo: las elecciones se guardan en un archivo de configuración dentro del proyecto. En la práctica, esto convierte la protección en política escrita, que se aplica sola cada vez que alguien abre el agente en ese proyecto. No depende de la memoria ni de la buena voluntad de cada persona del equipo.
Qué es lo que el ai-jail no resuelve
El propio autor es directo: no es 100% seguro, y ninguna jaula lo es. Para ejecutar código realmente sospechoso, lo correcto sigue siendo una máquina virtual desechable, una computadora de mentira que tiras después. La jaula protege del error y del descuido, que son la mayor parte de los incidentes, no de un ataque sofisticado dirigido a tu empresa.
Y ella protege la computadora, no la operación entera. Quien decide qué puede hacer el agente en el sistema de la empresa, qué datos accede, quién aprueba acciones sensibles y qué se registra es otra capa de gobernanza, que ya detallamos en control de accesos de agentes de IA y en las 4 puertas que la IA no atraviesa. La jaula es el cinturón de seguridad: no sustituye la dirección prudente, pero nadie debería conducir sin él.
La regla que vale adoptar hoy
Si tu empresa ya usa agentes de IA, o tiene gente del equipo usando por su cuenta (y tiene, aunque no lo sepas), la política cabe en una línea: ningún agente funciona fuera de la jaula. El costo es escribir siete caracteres más en el comando. El beneficio es que el peor día del agente deja de ser el peor día de la empresa.
Es el mismo principio que aplicamos cuando implementamos agentes privados en clientes: el aislamiento no es un accesorio que se añade después del incidente, es parte del diseño desde el primer día. La diferencia entre IA que da resultado y IA que se convierte en titular interna rara vez está en el modelo. Está en lo que tiene permiso de tocar.
