jai - una herramienta sencilla de aislamiento para agentes de IA

 (jai.scs.stanford.edu)
3 puntos por GN⁺ 2026-03-29 | 1 comentarios | Compartir por WhatsApp
  • Herramienta ligera para ejecutar agentes de IA en aislamiento en entornos Linux, que ofrece un límite de ejecución seguro con un solo comando sin configuraciones complejas de contenedores
  • A medida que se acumulan casos en los que herramientas de IA eliminan o dañan datos al acceder al sistema de archivos real, se vuelve más evidente la necesidad de un entorno de ejecución seguro
  • Protege el directorio personal con un overlay copy-on-write y separa /tmp y /var/tmp para evitar cambios en los archivos originales
  • Ofrece tres modos de aislamiento: Casual, Strict y Bare, para elegir el nivel de seguridad y el alcance de acceso
  • Proyecto open source desarrollado por un equipo de investigación de Stanford, que brinda una medida de protección práctica para usar herramientas de IA con mayor seguridad

jai, una herramienta ligera para aislar agentes de IA

  • jai es una herramienta diseñada para aislar (containment) fácilmente agentes de IA en entornos Linux
    • Ofrece un límite de ejecución seguro con un solo comando, sin necesidad de configuraciones complejas de contenedores o máquinas virtuales
    • Puede aplicarse de inmediato a flujos de trabajo existentes, como asistencia de programación o ejecución de scripts

  • Casos reales del problema

    • Varios usuarios reportaron pérdida de archivos y eliminación de directorios mientras usaban herramientas de IA
      • Nick Davidov informó que 15 años de fotos familiares fueron eliminados mediante un comando de terminal
      • Claude Code de Anthropic eliminó el directorio personal, causando la pérdida de proyectos de desarrollo
      • Se reportó que Cursor vació el árbol de trabajo y que “todo desapareció”
      • Un usuario de Reddit mencionó que Antigravity eliminó por completo la unidad D
      • Otro usuario de Cursor reportó la eliminación de 100GB de archivos
    • Estos casos muestran una brecha de seguridad que aparece cuando se permite a herramientas de IA acceder a una cuenta real

  • Funciones principales de jai

    • Configura automáticamente una frontera entre la cuenta de ejecución y el directorio personal
      • El directorio de trabajo mantiene permisos completos de lectura y escritura
      • El directorio personal se protege con un overlay copy-on-write, de modo que los archivos originales no se modifican
      • /tmp y /var/tmp se separan en espacios independientes, y el resto de los archivos se limita a solo lectura
    • Basta con anteponer jai al comando para ejecutar en aislamiento
      • Ejemplos: jai codex, jai claude, o simplemente jai para abrir un shell
    • Puede usarse de inmediato sin Dockerfile ni proceso de construcción de imágenes
      • No hace falta configurar banderas complejas de bwrap ni escribir scripts

  • Elección del modo de aislamiento

    • Ofrece tres modos: Casual / Strict / Bare
      • Casual: protege el directorio personal con copy-on-write y permite leer la mayoría de los archivos
      • Strict: se ejecuta con un usuario jai separado y ofrece un aislamiento fuerte con el directorio personal vacío
      • Bare: deja el directorio personal vacío pero mantiene el UID del usuario
    • Cada modo difiere en confidencialidad (confidentiality), integridad (integrity) y compatibilidad con NFS
      • El modo Strict ofrece el aislamiento más fuerte, pero no admite directorios personales en NFS

  • Comparación con herramientas alternativas

    • Docker
      • Es adecuado para reproducir entornos basados en imágenes, pero resulta pesado para sandboxing temporal de herramientas del host
      • No ofrece una función de overlay para el directorio personal
    • bubblewrap
      • Es un sandbox potente basado en namespaces, pero requiere especificar manualmente la configuración del sistema de archivos
      • jai elimina esa complejidad
    • chroot
      • No es un mecanismo de aislamiento de seguridad y no se recomienda para sandboxing en Linux, ya que carece de funciones como montajes, namespaces de PID y separación de privilegios

  • Límites de seguridad

    • jai no garantiza seguridad completa
      • Como “casual sandbox”, reduce el alcance del daño, pero no bloquea todos los ataques
      • El modo Casual ofrece poca protección de confidencialidad, y el modo Strict también difiere del nivel de aislamiento de un contenedor o una máquina virtual
      • En entornos multi-tenant o situaciones de alto riesgo, se recomienda usar contenedores o máquinas virtuales

  • Contexto del proyecto

    • Desarrollado en conjunto por el grupo de investigación Stanford Secure Computer Systems (SCS) y la Future of Digital Currency Initiative (FDCI)
    • Se ofrece como software open source gratuito y busca ayudar a los usuarios a usar la IA de forma más segura

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-03-29
Comentarios de Hacker News

  • Basta con agregar la siguiente configuración en .claude/settings.json

    {
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowRead": ["."],
      "denyRead": ["~/"],
      "allowWrite": ["."],
      "denyWrite": ["/"]
    }
  }
}

    Si quieres permitir acceso a directorios externos, solo hay que modificar la parte de allowRead
    Esta función se agregó hace 10 días como una nueva opción de sandbox

    • He visto a claude confundirse con el directorio actual o ejecutar comandos como rm -rf *
      Por suerte no pasó al mismo tiempo, pero da escalofríos solo imaginarlo
      La idea del sandbox es buena, pero para que sirva de verdad debe aplicarse forzosamente a bajo nivel
      Como claude mismo es un programa enorme hecho por IA, agregar una capa de seguridad de menos de 3000 líneas escrita por humanos puede ser una defensa valiosa
    • Una futura versión de claude-code podría cambiar silenciosamente el nombre de esta configuración o eliminarla
      Por eso algunas personas podrían preferir software de sandboxing aparte
    • Compartieron un ejemplo de configuración medio en broma que permite usar GPU pero solo evita borrar /
      Es una configuración que permite acceso a dispositivos /dev/nvidia*, una configuración satírica que básicamente asume el riesgo de fuga de datos
    • Ya existen herramientas de seguridad tradicionales probadas durante décadas
      Si ejecutas claude como un usuario con permisos limitados, el aislamiento se hereda automáticamente a los subprocesos
    • En Linux (Arch) y macOS (Tahoe) la función de sandbox no estaba funcionando bien
      Hay un issue relacionado abierto
      bubblewrap y seatbelt funcionan bien por separado, pero al ejecutarlos mediante claude-code parecen quedar desactivados

  • Sorprende que la gente instale tan fácilmente agentes de IA en sus computadoras personales
    Llevamos décadas protegiendo la seguridad de los sistemas y, de repente, les damos todos los permisos a software impredecible

    • Antes ya se ignoraban las advertencias cuando las herramientas de build traían dependencias automáticamente, y ahora los ataques a la cadena de suministro se siguen repitiendo
      La comodidad de corto plazo termina pesando más que la seguridad de largo plazo
    • En realidad, quienes aceptan este tipo de riesgos y quienes priorizan la seguridad son grupos distintos
    • En entornos corporativos el acceso ya está restringido, así que esto es más sensible en una PC personal
      En mi VM remota de desarrollo solo tengo datos que Claude puede ver sin problema
    • En los primeros días de Docker también había una actitud de “¡solo descarga la imagen y ya!”
      Pero la industria pronto entendió el riesgo de seguridad y reaccionó

  • Incluso una simple separación de permisos Unix es suficiente
    Basta con tener dos cuentas de usuario y agrupar solo las carpetas que se compartirán con la IA
    Ver esta entrada de blog relacionada

  • En la página principal dice “deja de confiar ciegamente”, pero el método de instalación propone un build manual en lugar de curl | bash

    • Descomprimir el archivo tar manualmente e instalar con makepkg -i es mucho más seguro
      El PKGFILE tiene unas 30 líneas y la función de build solo 7
      En cambio, scripts como rustup (910 líneas), claude (158 líneas) u opencode (460 líneas) son mucho más complejos
    • En cambio, encadenar curl | tar | makepkg en una sola línea sí sería una forma poco confiable

  • El proyecto está bien diseñado y parece un poco más seguro y conveniente que mi método
    Yo aíslo al agente creando una cuenta de usuario aparte
    A veces se enredan los permisos, pero lo corrijo con scripts
    Al final, la forma más segura es darle una laptop aparte
    No hay nada más seguro que un equipo físicamente separado

    • Pero si necesita comunicarse con servicios externos, hay que darle API keys, y existe el riesgo de que se filtren
      El agente ya tiene capacidades al nivel de pruebas de penetración, así que una simple separación por usuario no da tanta confianza
    • Yo también uso actualmente el método de separación por usuario
      Si usas contenedores, el agente se confunde cuando intenta crear contenedores por sí mismo

  • El sitio parece de baja calidad porque fue “vibe-coded”, pero la herramienta real fue implementada directamente por un profesor de Stanford
    Ver el enlace al FAQ

    • Hablando como el propio autor: no soy bueno en diseño web, pero sí soy experto en sistemas operativos
      Ya corregí el contenido de la documentación para que sea preciso, así que pueden confiar en él
      Es un poco irónico que haya dejado el sitio tal como lo generó la IA
    • El autor es David Mazieres, alguien que investiga sistemas de archivos a nivel de usuario desde principios de los 2000
      Dirige el grupo Stanford Secure Computer Systems
    • jai es una herramienta de alto riesgo, pero como el sitio web es simple, no molesta tanto que sea vibe-coded
    • Aun así, personalmente creo que una página HTML sencilla sería mejor

  • Preocupa que, si el agente tiene permiso de escritura en el directorio del proyecto, sea posible un exploit persistente
    Archivos como .pyc, .venv o .git/hooks podrían ejecutarse fuera del sandbox
    Eso también se confirmó en esta conversación de ChatGPT
    Por eso, la forma más segura es una transferencia de archivos basada en git patch
    La idea es exportar fuera del sandbox solo archivos modificados que correspondan a elementos ya committeados en git

    • Sería bueno agregar una opción para dejar el directorio .git/ en solo lectura
      Con jai -D se puede convertir el CWD en un overlay, pero fusionar los cambios es complicado
    • Yo directamente ejecuto el código solo dentro del sandbox (a nivel de VM)
      El agente trabaja en una rama de git worktree separada, y solo se fusiona después de revisar
      Así se mantiene un flujo de seguridad basado en revisión
    • Nunca se debería permitir un git hook

  • Como alternativa simple, se puede ejecutar el agente por ssh desde una cuenta de usuario aparte
    Se controla el acceso montando el directorio del proyecto con bind mount
    Combina bien con la función ssh remote de VSCode

    • Yo también llevo 6 meses usando una cuenta dedicada, y solo hay que gestionar qué directorios son accesibles
      Es una forma de aislamiento mucho más simple y eficiente que sistemas de seguridad complejos

  • En la práctica hay problemas más sutiles que rm -rf
    Una vez claude-code creó una carpeta /public/blog/ para guardar un SVG y eso rompió el routing de Apache
    No fue un problema de borrado ni de permisos, pero por un comportamiento no intencional el blog empezó a devolver 404
    jai probablemente evitaría errores graves así, pero este tipo de problemas finos siguen siendo difíciles

  • Excelente proyecto, pero el título deja que desear
    Me gusta la estructura de dar acceso total al directorio actual, dejar el resto en solo lectura y tratar el directorio home con copy-on-write
    Este enfoque debería ser el modelo de seguridad por defecto para agentes de IA

    • Como el sitio no tiene título, algo como “jai - filesystem containment for AI agents” le quedaría mejor