Ejecución en Sandbox
Ejecuta todo lo que un agente genera o invoca dentro de un entorno aislado y desechable, sin credenciales ambientales, con sistema de ficheros acotado, salida controlada y límites duros de recursos. El sandbox no está porque el agente sea malicioso, sino porque su entrada puede serlo.
Definición
La ejecución en sandbox es la práctica de correr el código generado por el agente y las acciones que invoca dentro de un entorno aislado y efímero cuyo sistema de ficheros, red, credenciales y recursos los acota el anfitrión y no el agente, de forma que un agente secuestrado o equivocado no pueda afectar a nada fuera de él.
Problema
Un agente que ejecuta código en el anfitrión hereda el anfitrión: sus credenciales, su sistema de ficheros, su posición de red. Una inyección con éxito o un comando confiadamente equivocado pasan entonces a ser indistinguibles de un compromiso de la máquina.
Cuándo usarlo
Úsala siempre que un agente ejecute código, corra comandos de shell, instale paquetes o procese ficheros no confiables. El umbral es bajo: si el agente puede provocar ejecución, la ejecución va en un sandbox.
Solución
Hazlo efímero. Crea el entorno por tarea, destrúyelo al terminar y no arrastres estado que la siguiente tarea no haya pedido. La persistencia es cómo un compromiso puntual se convierte en punto de apoyo.
Elimina las credenciales ambientales. Nada del entorno debería ser utilizable solo por estar presente; inyecta únicamente los secretos acotados que la tarea necesita, durante lo que dure.
Acota el sistema de ficheros al conjunto de trabajo. Monta el repositorio o la entrada y nada más, y monta en solo lectura todo lo que no necesite escritura.
Restringe la salida dentro del sandbox, no alrededor. Desde el punto de vista del atacante el aislamiento y la política de red son el mismo control, y un sandbox con red abierta es una celda con teléfono.
Limita recursos: CPU, memoria, disco, tiempo de reloj, número de procesos. El consumo desbocado es el modo de fallo que llega primero y más a menudo, normalmente sin ningún adversario.
Registra lo que cruzó la frontera: qué ficheros entraron, cuáles salieron, a qué destinos se llegó. La frontera solo sirve si puedes ver qué pasó por ella.
Componentes
Beneficios
- Convierte «el agente ejecutó algo malo» de incidente en contenedor descartado.
- Hace seguro dar a un agente capacidad real de ejecución, que suele ser justo lo que lo hace útil.
- Acota los errores honestos igual que los ataques: el mismo control atrapa un bucle infinito y un payload inyectado.
- Da un buen sitio donde observar: todo lo que la tarea tocó cruzó una única frontera.
Riesgos
- Aislamiento más débil de lo supuesto: un kernel compartido no es una frontera de seguridad frente a un escape decidido, y tratar un contenedor como una microVM es un error de categoría.
- Credenciales coladas por comodidad: un solo fichero de configuración montado deshace el patrón entero.
- Sandboxes que se vuelven persistentes en silencio porque reconstruir es lento, y con ello desaparece la efimeridad que sostenía la garantía.
- Escape por la superficie compartida que queda: volúmenes montados, la API del orquestador o la red a la que el sandbox sigue llegando.
Cuándo no usarlo
- Agentes de solo lectura sin capacidad de ejecución, donde no hay nada que aislar y el coste no compra nada.
- Rutas en línea críticas en latencia donde el arranque del entorno domina la tarea y encaja mejor un control más estrecho: un intérprete restringido, una función pura.
- Cuando el sandbox necesitaría justo las credenciales que existe para retener, que es señal de que la tarea hay que partirla en lugar de aislarla.
Tecnologías
Ejemplos
- Un agente de programación que clona en un contenedor nuevo por tarea, con el repositorio montado, sin credenciales de nube presentes y con salida limitada al registro de paquetes. Una instalación de dependencia maliciosa destruye un contenedor y nada más.
- Un agente de análisis de datos que ejecuta Python generado en una microVM con el dataset montado en solo lectura, sin red alguna y con límite de tiempo de reloj. El código generado puede estar mal; no puede salir caro ni exfiltrar.
- Un agente de procesamiento documental que abre PDFs no confiables dentro de un entorno desechable, porque un exploit del parser en un fichero subido es una vía real al anfitrión y el fichero vino de fuera.
KPIs
- Porcentaje de ejecuciones en sandbox
- El número de cobertura. Lo que corre fuera del sandbox es la postura de seguridad real, diga lo que diga la parte que sí está dentro.
- Vida del sandbox
- Cuánto duran los entornos. Vidas crecientes significan que la efimeridad se está erosionando hacia la persistencia.
- Choques con límites de recursos
- Tareas detenidas por una cuota o un timeout. Una mezcla útil de generaciones desbocadas y límites legítimos puestos demasiado estrechos.
- Secretos presentes en ejecución
- Número de credenciales alcanzables dentro del entorno. El objetivo es el mínimo que la tarea necesite, y a menudo cero.
Modos de fallo observados
- El montaje por comodidad: un directorio home, un fichero de credenciales o un socket montados para que una tarea dejara de fallar.
- Reutilización persistente: el entorno deja de ser por tarea porque reconstruir cuesta demasiado, así que sobreviven el estado y el compromiso.
- Salida abierta dentro de la frontera: aislamiento fuerte con red libre es contención solo frente al sistema de ficheros.
- Alcance al orquestador: el sandbox puede llamar a la API que gestiona sandboxes, lo que es escapar por diseño y no por exploit.
Lecciones aprendidas
- Aísla la ejecución antes de confiar en la generación. El sandbox es lo que hace razonable dejar que un agente ejecute código.
- Lo efímero es la propiedad de seguridad; el aislamiento por sí solo únicamente aplaza el problema.
- La credencial que no está presente no se puede robar, y es el único control que aguanta después de un escape.
- La mayoría de activaciones del sandbox son errores honestos, no ataques. Eso es el patrón funcionando, no la prueba de que sobraba.
FAQs
- ¿Basta un contenedor o necesito una microVM?
- Depende de qué corre dentro. Para código propio con riesgo de inyección, un contenedor endurecido sin credenciales y con salida acotada suele ser proporcionado. Para código arbitrario de origen no confiable, asume que el kernel compartido se puede escapar y usa una microVM.
- ¿En qué se diferencia del mínimo privilegio en herramientas?
- El mínimo privilegio acota lo que el agente puede pedir; el sandbox acota lo que ocurre cuando algo se ejecuta igualmente. Uno gobierna la petición y el otro el entorno donde se ejecuta, y un agente que corre código necesita ambos.
- El sandbox lo ralentiza todo, ¿compensa?
- Compáralo con el coste de la alternativa, no con cero. Casi toda la latencia es el arranque del entorno, que los pools y las imágenes precalentadas eliminan en buena parte; el fallo que evita es un compromiso del anfitrión que ejecuta el agente.