Intro
Cuando un agente solo resume texto, el problema principal suele ser la calidad de la respuesta. Cuando ese mismo agente puede abrir un browser, ejecutar comandos, llamar un servidor MCP, leer archivos o tocar red, el problema cambia por completo. Ya no alcanza con preguntarse si “razona bien”. Hay que preguntarse qué daño puede hacer, cuánto puede escapar de su contexto y cuánto control real tiene la plataforma sobre esa ejecución.
Ahí aparece el sandbox como pieza de arquitectura, no como accesorio.
Un sandbox bien diseñado no busca prometer aislamiento perfecto. Busca algo más honesto y más útil: reducir blast radius, limitar permisos, volver observable la ejecución y hacer viable la operación diaria. Si la capa de contención es demasiado débil, el agente queda sobreexpuesto. Si es demasiado pesada o incómoda, el equipo termina saltándosela.
La pregunta importante entonces no es “qué herramienta de sandboxing está de moda”, sino cómo combinar controles para que el entorno sea seguro sin volverse inviable de operar.
Qué hay que aislar de verdad
El error más común es pensar el sandbox como “una cajita para correr código”. En la práctica, hay varias superficies distintas y cada una necesita decisiones propias.
Proceso y usuario
El agente no debería correr como root ni heredar privilegios amplios del host. Necesita un usuario aislado, namespaces propios y límites claros sobre qué procesos puede crear, inspeccionar o señalizar.
Filesystem
El directorio de trabajo del agente debería ser explícito, acotado y, en muchos casos, efímero. Montar el proyecto entero, el home del operador o volúmenes sensibles por comodidad rompe gran parte del valor del sandbox. Lo más sano suele ser combinar un workspace temporal con mounts puntuales y deliberados.
Red
La salida a internet no debería quedar “abierta por defecto”. Un agente que puede resolver cualquier DNS y llamar cualquier destino tiene mucho más margen para exfiltrar datos, descargar payloads o encadenar acciones no previstas. La política de egress importa tanto como la del filesystem.
Secretos y credenciales
Si el agente recibe variables de entorno amplias, tokens persistentes o acceso indirecto a credenciales del host, el sandbox queda agujereado aunque el proceso esté bien encerrado. Las credenciales deberían ser de corta vida, por alcance mínimo y, cuando se pueda, emitidas por tarea.
Recursos y tiempo
Sin límites de CPU, memoria, procesos, disco y duración, el problema no es solo seguridad. También aparece riesgo operativo: loops, runaway jobs, consumo excesivo y degradación del nodo donde corren otros workloads.
Herramientas y MCPs expuestos
No alcanza con aislar el proceso si después el agente tiene un menú excesivo de herramientas peligrosas. El catálogo de herramientas disponibles, sus argumentos, sus permisos efectivos y su trazabilidad también forman parte del diseño del sandbox.
Principios de diseño que sí ayudan
1. Diseñar para contener impacto, no para “confiar” en el agente
Aunque el agente acierte muchas veces, la arquitectura debería asumir que en algún momento va a interpretar mal, encadenar una acción riesgosa o recibir input hostil. Por eso conviene pensar el entorno como si cada run pudiera fallar de forma torpe pero suficientemente dañina.
2. Hacer que lo seguro sea el camino por defecto
Si el flujo normal obliga a pedir excepciones todo el tiempo, el equipo va a buscar atajos. Un sandbox sano no depende de heroicidades operativas. Depende de defaults razonables: sin privilegios, sin mounts amplios, sin salida libre, sin secretos persistentes y con cleanup automático.
3. Separar aislamiento de política
El sandbox resuelve contención técnica. La política decide qué está permitido. Mezclar ambas cosas en una sola capa suele volver todo más frágil. Conviene que la ejecución esté aislada aunque además exista una capa superior que controle herramientas, destinos de red, approvals o scopes por tenant.
4. Preferir entornos efímeros cuando la tarea lo permita
Cuanto más dura una sesión, más estado acumula y más difícil se vuelve razonar sobre residuos, credenciales, caches y contaminación cruzada. Para tareas discretas, el modelo más sano suele ser crear, ejecutar, observar y destruir.
Decisiones de arquitectura que cambian mucho el resultado
Sandbox por tarea, por sesión o por tenant
Un sandbox por tarea reduce contaminación entre runs y simplifica cleanup, pero puede costar más en arranque. Un sandbox por sesión mantiene contexto útil durante una investigación o debugging, aunque aumenta el riesgo de arrastrar estado inesperado. Un sandbox por tenant baja costos operativos, pero exige mucha más disciplina para no mezclar datos, caches o credenciales entre flujos incompatibles.
En general, por tarea suele ser el mejor default para acciones automáticas y de riesgo medio o alto. Por sesión puede servir en workflows interactivos bien observados. Por tenant solo conviene cuando el modelo de confianza está realmente claro.
Efímero vs persistente
La persistencia no es gratis. Facilita continuidad, pero también deja restos. Si necesitás memoria o caches, conviene separar explícitamente qué estado vale la pena conservar y bajo qué política. Persistir “todo por las dudas” suele ser la forma más rápida de perder control.
Contenedor endurecido vs microVM
Un contenedor endurecido puede ser un baseline muy razonable cuando el riesgo está acotado y el objetivo es operar con bajo costo. Pero contenedor no significa aislamiento fuerte por sí solo. Si el blast radius potencial es alto, si hay multi-tenant real o si el agente ejecuta código no confiable con frecuencia, una microVM o una capa más robusta puede justificar su complejidad.
La pregunta no es cuál tecnología es más elegante. La pregunta es cuánto aislamiento necesitás para el tipo de ejecución que vas a permitir.
Ejecución local vs worker remoto
Correr cerca del sistema principal simplifica latencia y acceso, pero agranda el riesgo sobre el host. Mover ejecución riesgosa a workers remotos efímeros ayuda a separar dominios de falla, a endurecer red y a limitar impacto lateral. Para browser automation, scraping, code execution o tools con superficie rara, esta separación suele valer bastante.
Controles mínimos para producción
Hay muchas combinaciones posibles, pero algunos controles aparecen una y otra vez en sandboxes que intentan ser serios.
- sin privilegios reales: sin root efectivo, sin
--privileged, sin Docker socket, sin capabilities innecesarias; - namespaces y cgroups: aislamiento de procesos, red y límites de recursos;
- seccomp y AppArmor o SELinux: reducción de syscalls y perfiles de acceso;
- filesystem temporal: writable solo donde haga falta y mounts explícitos cuando un recurso tenga que entrar;
- egress control: allowlist de destinos, puertos y resolución DNS restringida;
- credenciales efímeras: emitidas por tarea o por sesión corta, con scopes mínimos;
- timeouts y kill automático: para cortar loops o tareas colgadas;
- logs y trazas por run: quién ejecutó, qué herramientas usó, qué política aplicó, qué red tocó y cómo terminó.
No hace falta activar todo el catálogo el día uno. Sí hace falta saber qué capa cubre cada riesgo y dónde hoy hay huecos.
Qué enfoque conviene según nivel de riesgo
Riesgo bajo a medio: contenedor endurecido y efímero
Si el agente trabaja sobre un workspace acotado, con herramientas limitadas y sin tocar datos especialmente sensibles, un contenedor endurecido puede ser suficiente. La clave está en endurecer de verdad: usuario no privilegiado, mounts mínimos, red controlada y limpieza automática.
Riesgo medio a alto: contención reforzada
Cuando el agente ejecuta código arbitrario, automatiza browser contra sitios externos o interactúa con herramientas poco predecibles, conviene sumar más separación. Acá aparecen opciones como gVisor o workers remotos más encerrados, para bajar la confianza depositada en el kernel o en la configuración del host principal.
Riesgo alto o multi-tenant fuerte: microVMs o aislamiento equivalente
Si el impacto potencial justifica separación dura entre ejecuciones, las microVMs o enfoques equivalentes empiezan a tener más sentido. No son gratis: agregan complejidad, costo de arranque y más piezas operativas. Pero a veces esa complejidad es menor que el costo de un incidente serio.
Errores de diseño muy frecuentes
Creer que “está en Docker” alcanza
Docker ayuda, pero por sí solo no resuelve política, secretos, egress, observabilidad ni control fino de herramientas. Un contenedor cómodo y demasiado abierto puede ser apenas una ilusión de orden.
Pasar secretos amplios por conveniencia
Si el sandbox recibe la misma credencial multipropósito que usa el operador o que usa la plataforma entera, cualquier contención posterior vale menos. El secreto correcto para un agente suele ser más chico, más corto y más revocable.
Montar volúmenes sensibles o persistentes sin necesidad
Compartir caches, homes, repos completos o rutas del host porque “es más práctico” suele reintroducir justo el tipo de acoplamiento que el sandbox quería evitar.
Dejar internet abierto y observar poco
Muchos equipos endurecen el filesystem pero dejan la red casi libre. Eso es un problema. Si además hay poca trazabilidad, después cuesta muchísimo reconstruir qué hizo un run cuando algo salió mal.
Usar el sandbox como excusa para descuidar el resto
El sandbox no reemplaza evals, approvals, scopes finos ni control de herramientas. Tampoco corrige prompt injection, abuso lógico o malas políticas de acceso aguas arriba.
Una arquitectura práctica para empezar bien
Para muchos equipos, un buen punto de partida es este:
- sandbox efímero por tarea para toda ejecución con shell, browser o código;
- workspace temporal y mounts explícitos solo cuando una ruta deba entrar;
- salida de red por allowlist o por perfiles de destino según herramienta;
- credenciales de corta vida emitidas para la tarea concreta;
- catálogo acotado de tools/MCPs con scopes y trazabilidad;
- límites de recursos y timeout obligatorio;
- logs correlacionados por run para poder auditar después;
- aprobaciones o policy checks en acciones irreversibles o externas.
No es una arquitectura perfecta ni universal. Pero sí es bastante mejor que dejar al agente correr “cerca del host” con permisos heredados y confianza implícita.
La idea importante para llevarse
Un sandbox eficiente y seguro para agentes de IA y MCPs no se define por una sola tecnología. Se define por cómo combinás aislamiento, permisos, red, secretos, límites y observabilidad para que el agente pueda trabajar sin que una mala decisión se convierta en incidente.
Cuando esa capa está bien pensada, el equipo gana dos cosas a la vez: menos blast radius y más capacidad real de operar agentes en serio. Y en esta etapa de adopción, esa combinación vale mucho más que cualquier promesa abstracta de autonomía.