El código generado no tiene que ser malicioso para causar daño. Basta con que interprete mal una ruta, abra una conexión inesperada o consuma toda la memoria al procesar un archivo. Cuando el agente puede ejecutar, el error deja de ser texto y se convierte en efecto.
Un sandbox reduce ese efecto. No convierte el código en confiable ni sustituye permisos, revisión o copias de seguridad.
El límite de confianza
El agente, sus dependencias, los archivos de entrada y el código que produce deben tratarse como potencialmente inseguros. El sandbox se interpone entre ellos y el host, la red corporativa, otros usuarios y los sistemas de producción.
Un contenedor aporta empaquetado y aislamiento del sistema operativo, pero comparte kernel. NIST SP 800-190 describe riesgos específicos de imágenes, registros, orquestadores, contenedores y host (NIST). Para código altamente no confiable o multitenant puede convenir una frontera adicional.
Cuatro fronteras habituales
| Aislamiento | Ventaja | Límite |
|---|---|---|
| proceso y permisos del SO | rápido y simple | frontera débil ante código hostil |
| contenedor endurecido | ecosistema maduro y eficiente | comparte kernel y exige configuración |
| kernel de aplicación | reduce superficie directa al host | compatibilidad y rendimiento variables |
| microVM | barrera de virtualización fuerte | más operación y arranque |
gVisor implementa una interfaz de kernel Linux en espacio de usuario para interceptar llamadas y reducir el contacto directo con el kernel host; su propia documentación explica también lo que no protege (gVisor). Firecracker utiliza microVMs sobre KVM y un modelo mínimo de dispositivos para reducir superficie (Firecracker). No existe una elección universal: depende de amenaza, compatibilidad, densidad y latencia.
Una sesión no debería ver a la siguiente
La unidad de aislamiento puede ser ejecución, conversación, usuario o proyecto. Para código arbitrario, aislar por ejecución o sesión limita persistencia accidental y movimiento lateral.
Al terminar, destruya procesos y disco temporal. Los artefactos que deban persistir se copian a un almacén controlado después de validarlos. “Persistir el workspace” no debería equivaler a conservar todo el sistema de archivos.
La red es una herramienta, no una propiedad
Permitir Internet completo facilita instalar paquetes y consultar APIs. También permite exfiltrar datos, descargar payloads y atacar servicios internos.
Empiece sin red. Cuando una tarea la necesite, use un proxy con destinos y métodos permitidos, resolución DNS controlada y bloqueo de rangos internos y metadatos cloud. Registre solicitudes sin volcar tokens. Un navegador automatizado merece políticas similares: navegar no debe abrir acceso implícito a intranet y sesiones personales.
Secretos que aparecen solo en el momento justo
No inyecte todas las credenciales al arrancar. Entregue un token corto a la herramienta concreta, con audiencia y permisos mínimos. Si el código necesita guardar un resultado, exponga una API mediada en lugar de montar credenciales de producción.
El modelo no necesita ver el secreto. La capa de herramientas puede sustituir un identificador por la credencial al ejecutar y redactarla de stdout, errores y trazas.
Un secreto dentro del sandbox debe considerarse accesible para todo código que corre allí.
Límites que evitan accidentes ordinarios
- CPU, memoria, disco y número de procesos.
- Tiempo total y tiempo sin progreso.
- Tamaño de entrada, salida y logs.
- Usuario sin privilegios y sistema base de solo lectura.
- Dispositivos, syscalls y capacidades mínimas.
- Montajes explícitos sin rutas del host.
- Imagen fijada, escaneada y recreable.
- Cancelación y destrucción comprobadas.
Los límites deben producir errores comprensibles para que el agente no reintente indefinidamente. Una terminación por memoria no se corrige ejecutando el mismo script cinco veces.
Verificar la salida antes de confiar en ella
El sandbox contiene ejecución, no valida resultados. Un archivo puede incluir macros, fórmulas peligrosas, HTML activo o contenido manipulado. Analice tipo real, tamaño, estructura y malware; renderice cuando corresponda; y publique mediante una acción separada.
Pruebe el aislamiento con intentos explícitos: leer rutas del host, acceder a metadatos, alcanzar otro sandbox, escapar mediante montajes, agotar recursos y filtrar un token. Repita tras actualizar runtime, kernel, imagen u orquestador.
Preguntas frecuentes
¿Docker es un sandbox suficiente?
Puede serlo para cargas controladas y bien endurecidas. Para código arbitrario multitenant, evalúe una frontera adicional como gVisor o microVM según el modelo de amenaza.
¿Se puede permitir instalar paquetes?
Sí mediante repositorios aprobados, versiones bloqueadas, caché y análisis. Instalar desde cualquier URL durante la ejecución amplía mucho la cadena de suministro.
¿Cómo persiste un proyecto entre sesiones?
Guarde solo un directorio de trabajo o artefactos en almacenamiento aislado y versionado. Monte esa persistencia con permisos mínimos en un sandbox nuevo.
¿El sandbox protege frente a prompt injection?
Limita el impacto de acciones, pero no impide que el agente siga instrucciones maliciosas. Necesita controles de contenido, herramientas y autorización además del aislamiento.
Diseñe para poder perder el sandbox
Si destruir una sesión pone en peligro datos o interrumpe un proceso irrecuperable, se ha guardado demasiado estado dentro. El sandbox más seguro y operable es el que puede desaparecer y reconstruirse sin drama.
Fuentes y lecturas recomendadas
- NIST SP 800-190: Application Container Security Guide
- Introduction to gVisor security
- Firecracker microVM
- SPIFFE workload identity
Fuentes y vigencia revisadas el 18 de agosto de 2026.