Los agentes de código AI necesitan sandboxes antes de modelos mejores
El acceso pleno al shell de un agente puede generar dependencias peligrosas; los modelos más sólidos no reducen el riesgo si no se usan contenedores seguros.
Los agentes de código AI, como los que usan modelos de Claude o GPT‑5, pueden ejecutar comandos en el entorno del desarrollador sin una barrera intermedia. En una prueba, el autor otorgó acceso a su laptop y el agente instaló un paquete de un namespace sospechoso, generando una auditoría de veinte minutos en lugar de entrega.\n\nHay dos tipos de fallas: de capacidad, donde el agente produce una solución incorrecta, y de ejecución, donde el agente realiza acciones dañinas como sobrescribir archivos, subir código o instalar dependencias comprometidas. Los modelos más avanzados reducen las fallas de capacidad, pero siguen siendo capaces de emitir comandos destructivos con confianza, lo que los hace más difíciles de detectar.\n\nLos entornos habituales de ejecución se dividen en tres grupos:\n\n* Shell nativo bajo el usuario propio: rápido, pero sin restricciones, con acceso a llaves SSH, credenciales de nube y todo el sistema de archivos.\n* Docker con la carpeta del proyecto montada: mejora la seguridad al limitar el alcance del agente, aunque el contenedor sigue pudiendo acceder a Internet.\n* VM efímera estilo CI: la opción más segura, pero requiere configuración adicional y es menos frecuente.\n\nEl riesgo no proviene de intenciones maliciosas, sino de la interpretación errónea de contenido no confiable, como READMEs contaminados o paquetes con scripts de post‑instalación sospechosos. El aumento de la autonomía de los agentes permite que realicen más pasos antes de que el humano intervenga, lo que aumenta la ventana de error.\n\nPara mitigar este riesgo, los sandboxes deben incluir:\n\n* Aislamiento de sistema de archivos: el agente solo ve el proyecto, con un overlay descartable.\n* Acceso a red bloqueado por defecto: evita exfiltraciones.\n* Límites de recursos: CPU, memoria y tiempo de ejecución.\n* Credenciales restringidas y de corta vida: tokens de acceso específicos en lugar de llaves permanentes.\n* Registros externos: cada comando y archivo abierto se guarda fuera del sandbox.\n\nHerramientas como Firecracker, gVisor o contenedores OCI con seccomp pueden combinarse para lograr estos controles. Sin embargo, la mayoría de los frameworks de agentes no los activan de forma predeterminada; suelen ser opciones avanzadas que los usuarios omiten para ahorrar tiempo.\n\nEn última instancia, la adopción de sandboxes seguros se vuelve una decisión de flujo de trabajo. Si no se implementan, la mejora de los modelos solo amplía el radio de daño, aumentando la necesidad de políticas de seguridad robustas antes de confiar plenamente en la autonomía de los agentes de código.
