La integración de agentes de inteligencia artificial locales con acceso al sistema de archivos representa un salto cualitativo en productividad, pero también abre la puerta a incidentes que van desde la pérdida accidental de datos hasta la corrupción de configuraciones críticas. En Q2BSTUDIO, donde desarrollamos aplicaciones a medida que integran IA, ciberseguridad y cloud, hemos observado que muchos equipos subestiman los riesgos reales. No se trata de modelos maliciosos, sino de errores de interpretación que, combinados con permisos amplios, pueden causar daños considerables. Este artículo presenta patrones de sandboxing que cualquier equipo puede implementar para que sus agentes trabajen con archivos sin comprometer la seguridad del sistema.
El riesgo más común: la confianza equivocada
Cuando un agente local tiene capacidad de escritura, el peligro no suele venir de un ataque externo, sino de una orden malinterpretada. El modelo puede entender “limpia este directorio” como “elimina archivos temporales” y, en lugar de eso, sobrescribir un archivo de entorno. O puede decidir reorganizar la estructura del proyecto moviendo ficheros esenciales. En Q2BSTUDIO hemos visto casos donde un agente, al intentar optimizar código, modificó un archivo de configuración de base de datos que luego provocó caídas en producción. La lección es clara: hay que planificar defensas contra la estupidez confiada primero, y contra la malicia después.
Patrón 1: Lista blanca de directorios raíz
El enfoque natural es prohibir zonas sensibles como /etc o ~/.ssh. Pero las listas negras fallan porque siempre se olvida algún caso. La alternativa es invertir la lógica: definir explícitamente los directorios que el agente puede tocar. En nuestros proyectos, fijamos dos o tres rutas autorizadas —por ejemplo, el directorio del proyecto activo y un área de trabajo temporal— y bloqueamos todo lo demás por defecto. Además, es imprescindible resolver las rutas antes de validarlas: un path como “proyecto/../../.ssh/id_ed25519” pasa un filtro superficial. Usamos realpath para obtener la ruta canónica y luego comprobamos que esté dentro de la lista blanca. También tratamos los enlaces simbólicos con sospecha, porque un symlink dentro de una ruta permitida puede apuntar a cualquier lugar.
Patrón 2: Ocultar dotfiles y secretos por defecto
Aunque el agente opere dentro de un directorio autorizado, hay ficheros que no debería ni leer. Archivos que empiezan por punto (.env, .git, .ssh) contienen claves, tokens o credenciales que, si se exponen al modelo, pueden acabar en logs, mensajes de commit o resúmenes que salgan del sistema. En Q2BSTUDIO aplicamos una política de denegación por defecto para cualquier archivo cuyo nombre coincida con patrones de secretos. Esto se implementa con expresiones regulares que bloquean tanto lecturas como escrituras. El agente recibe un error claro (“denied: .env matches denied pattern”) y, sorprendentemente, los modelos grandes aprenden rápido a no intentarlo de nuevo.
Patrón 3: Modo dry‑run con diff visible
Antes de permitir escrituras reales, cada herramienta de archivos debería tener un modo que muestre qué va a hacer sin ejecutarlo. En lugar de un mensaje genérico como “voy a actualizar config.ts”, mostramos el diff unificado con las líneas antes y después. Esto permite al desarrollador revisar cambios propuestos y detectar anomalías. En Q2BSTUDIO mantenemos este modo activado durante las primeras interacciones con un nuevo agente o modelo, y solo lo desactivamos cuando hemos visto suficientes ejemplos de comportamiento correcto. Es una capa de seguridad barata que transforma la confianza ciega en verificación consciente.
Patrón 4: Montajes de solo lectura para referencias
A menudo el agente necesita leer documentación, repositorios de dependencias o bases de código de referencia que no debe modificar jamás. En lugar de añadirlos a la lista blanca de escritura, los montamos como bind mounts de solo lectura a nivel de sistema operativo. Con “sudo mount --bind -o ro /ruta/origen /ruta/destino” logramos que incluso si hay un error en nuestra envoltura de TypeScript, el kernel impida la escritura. Esta defensa en profundidad nos ha salvado en varias ocasiones. Para un aislamiento mayor, se puede ejecutar todo el agente dentro de un contenedor con volúmenes específicos, pero el bind mount cubre el 80% de los casos en un minuto.
Patrón 5: Lista de verificación del radio de explosión
Antes de habilitar cualquier herramienta de sistema de archivos para un agente, respondemos cinco preguntas por escrito: ¿Cuál es la peor llamada que esta herramienta puede hacer? ¿Es reversible esa catástrofe? (archivos bajo git sí, eliminaciones fuera del repositorio no). ¿Qué puede leer esta herramienta y podría contener secretos? ¿Puede la salida de esta herramienta influir en una llamada más peligrosa? (una herramienta de lectura que alimente a una de escritura abre la puerta a inyección a través del contenido). ¿Cuál es el alcance más estrecho que sigue siendo útil? Si la respuesta a la segunda pregunta es “irreversible”, la herramienta se bloquea o se protege con confirmación humana. Este proceso es idéntico al que usamos en revisiones de contratos inteligentes, y se transfiere perfectamente al mundo de los agentes.
