Los sandboxes para agentes de codificación con IA se están convirtiendo en una disciplina de seguridad seria, no en una ocurrencia tardía
Dale a un agente de codificación con IA acceso completo a tu repositorio, tu shell y tus variables de entorno, y le habrás entregado el mismo radio de explosión que el de un pipeline de CI comprometido. Eso solía ser un riesgo aceptable cuando los agentes ejecutaban tareas de un solo turno, supervisadas por un humano, que duraban unos pocos minutos. Dejó de ser aceptable en el momento en que los agentes empezaron a funcionar sin supervisión durante horas, coordinando múltiples sub-agentes y ejecutando comandos de shell para probar sus propios cambios.
La respuesta de la industria ha convergido en un patrón: ejecutar los agentes dentro de entornos aislados y desechables —sandboxes, contenedores o worktrees efímeros de git— en lugar de hacerlo directamente sobre el checkout activo del desarrollador. Esto ya no es una precaución experimental. Se está convirtiendo en infraestructura básica, y los equipos que la omiten están acumulando un riesgo que no han tasado.
Por qué el enfoque ingenuo se desmorona
La forma obvia de ejecutar un agente de codificación es apuntarlo a tu directorio de trabajo y dejarlo editar archivos directamente. Esto funciona bien para ediciones pequeñas y supervisadas. Se desintegra en tres ejes a medida que aumenta la autonomía:
Exposición de credenciales. Un agente con acceso al shell puede leer archivos .env, claves SSH, credenciales de CLI en la nube y tokens de API que estén en el entorno —no porque tenga esa intención, sino porque un paso de depuración o una instrucción mal interpretada lo lleva a hacer cat sobre un archivo que no debería. La inyección de prompts desde una dependencia maliciosa, un README envenenado o un registro de paquetes comprometido puede convertir esto en una exfiltración activa en lugar de un accidente.
Efectos secundarios irreversibles. Un agente que prueba una migración de base de datos, ejecuta un script de limpieza o experimenta con un comando de despliegue contra infraestructura real puede causar daños que una revisión de código nunca aprobaría —porque nadie lo revisó antes de que se ejecutara.
Contaminación de estado. Cuando múltiples agentes o múltiples intentos comparten un único árbol de trabajo, las ediciones parciales de un intento fallido se filtran al siguiente. La depuración se convierte en arqueología: ¿qué cambios vinieron de qué ejecución?
Cómo es realmente el patrón sandbox más worktree
El patrón que ha surgido combina dos mecanismos separados que cumplen dos funciones distintas.
Los worktrees de git (o clones completos del repositorio) proporcionan aislamiento a nivel de sistema de archivos. En lugar de que un agente edite tu única copia desplegada del repositorio, obtiene su propio árbol de trabajo —un directorio separado respaldado por el mismo historial de git pero con archivos independientes y estado de rama propio. Múltiples agentes, o múltiples intentos paralelos de la misma tarea, obtienen cada uno un árbol limpio. Nada se confirma en la rama principal hasta que un humano —o un paso de verificación— aprueba el diff.
Los sandboxes de ejecución proporcionan aislamiento a nivel de proceso y red. Los comandos de shell del agente se ejecutan dentro de un contenedor, una máquina virtual o un contexto de ejecución restringido que no tiene acceso a las credenciales del host, no tiene ruta a internet más allá de una lista de permitidos explícita, y no tiene capacidad de tocar nada fuera de su worktree asignado. La Antigravity de Google, por ejemplo, ejecuta su modo de razonamiento profundo /boost dentro de lo que llama worktrees aislados y efímeros, específicamente para que los sub-agentes de implementación puedan ejecutar objetivos de compilación y suites de pruebas localmente sin tocar el estado de trabajo real del desarrollador —y para que una hipótesis fallida pueda simplemente descartarse en lugar de revertirse manualmente.
En conjunto, esto significa que se le pueden dar al agente permisos genuinamente amplios —leer todo el código, ejecutar comandos de shell arbitrarios, instalar paquetes, acceder a servicios locales— sin que esos permisos se extiendan a nada que al desarrollador le importe proteger de verdad. El radio de explosión es el sandbox desechable, no la máquina ni la cuenta.
El paso de verificación sigue importando
El sandbox resuelve el problema de contención, no el de corrección. Un agente puede ejecutarse completamente dentro de un entorno aislado y aun así producir código incorrecto, inseguro o sutilmente defectuoso. Lo que el sandbox te da es la capacidad de dejar que el agente itere —escribir código, ejecutar pruebas, ver fallos, reintentar— sin que cada paso intermedio necesite un humano en el bucle. La revisión sigue teniendo que ocurrir en el punto en que se propone un diff para merge, y cada vez más ese paso de revisión está también automatizado: pasadas de verificación independientes que vuelven a ejecutar la suite de pruebas completa contra los cambios en sandbox antes de que lleguen a una persona.
Esta es también la razón por la que el patrón de sandbox escala mejor que los diálogos de permiso. Pedir a un humano que apruebe cada escritura de archivo o comando de shell que un agente quiere ejecutar no mejora realmente la seguridad —entrena a las personas para pulsar aprobar sin leer, el mismo modo de fallo que hizo que los diálogos de permiso del navegador y las alertas de UAC resultaran prácticamente inútiles. Aislar el radio de explosión desde el principio y luego revisar el diff final es un modelo de seguridad más honesto que esperar a que un desarrollador agotado lea cada diálogo de confirmación.
Qué hacer al respecto
Si hoy estás ejecutando agentes de codificación con IA contra repositorios reales, tres cambios importan más que cualquier herramienta de un proveedor concreto:
Separa las credenciales del agente de las tuyas. No permitas nunca que un agente se ejecute dentro de un shell que tenga tus claves SSH personales, credenciales de proveedor en la nube o tokens de API de producción disponibles. Usa tokens con alcance limitado y corta duración para el acceso que el agente realmente necesite, y nada más.
Da a los agentes su propio worktree, no tu checkout activo. Ya sea mediante git worktree add, un contenedor desechable por tarea, o una plataforma gestionada que lo haga por ti, asegúrate de que una ejecución fallida o maliciosa no deje rastro en la copia del código en la que realmente trabajas.
Trata la salida de red como un permiso, no como un valor por defecto. Un agente que puede instalar paquetes arbitrarios desde internet público durante una ejecución en sandbox sigue siendo un riesgo para la cadena de suministro. Siempre que sea posible, restringe el acceso de red saliente a una lista de permitidos explícita en lugar de dejarlo abierto por defecto.
Nada de esto es infraestructura exótica —los worktrees y los contenedores son anteriores en años a la oleada actual de herramientas de codificación con IA. Lo nuevo es la urgencia: los agentes que operan durante horas seguidas, se coordinan con otros agentes y ejecutan código sin un humano vigilando cada paso han convertido el límite de aislamiento en un requisito, no en una tarea de endurecimiento que puedes dejar para después.