Sandboxes de agentes, explicados: por qué TrueForge trata el sandbox como una herramienta

Un sandbox puede aislar la ejecución de código, archivos y shell sin convertirse en el tiempo de ejecución completo del agente. Esa elección cambia los costes, la exposición de credenciales, el ciclo de vida y la semántica de recuperación.

Un sandbox responde a una pregunta más limitada que "¿es seguro el agente?".

Un agente puede necesitar ejecutar código, manipular archivos, inspeccionar un repositorio o ejecutar comandos de shell. Esas operaciones no deberían compartir un límite de proceso sin restricciones con el servidor de orquestación o la infraestructura de producción de la organización. Un sandbox crea un entorno de ejecución restringido para ese trabajo.

Pero "agente aislado" es una frase imprecisa. Puede significar que todo el bucle del agente se ejecuta dentro de una máquina aislada, incluidos los clientes de modelos, las credenciales de herramientas y el estado. O puede significar que el bucle del agente permanece en un tiempo de ejecución gestionado e invoca un entorno aislado solo para tareas de ejecución intensiva. TrueForge elige el segundo diseño: el sandbox como herramienta.

La distinción cambia qué se aísla, cuándo existe el cómputo, dónde residen los secretos y qué sobrevive a un fallo. También evita que un sandbox se convierta en una etiqueta de seguridad mágica. El límite solo protege las operaciones y el tráfico que realmente se colocan detrás de él.

La arquitectura mantiene el modelo que contiene los secretos y los clientes MCP en el lado del arnés, mientras que otorga al código y al trabajo de shell un límite de ejecución separado. El conector es una ruta de capacidad, no una transferencia de credenciales al sandbox.

Dos arquitecturas, diferentes compromisos

En una arquitectura de agente dentro de un sandbox, cada ejecución o entorno de agente puede contener el bucle de orquestación, el cliente de modelo, las herramientas, las credenciales y los archivos de trabajo. El aislamiento es conceptualmente simple porque la mayor parte de la actividad ocurre dentro de un solo límite. Los costes son un aprovisionamiento más pesado, una inyección de secretos más compleja y reconstrucciones de imágenes cuando cambian las dependencias del tiempo de ejecución.

En la arquitectura documentada de sandbox como herramienta de TrueForge, el bucle del agente se ejecuta en el servidor de TrueForge. El sandbox se aprovisiona solo cuando el agente necesita código, archivos, shell, una habilidad o el Modo Código. Los turnos de conversación simples y las llamadas MCP no requieren cómputo de sandbox. Las credenciales del modelo y de MCP permanecen en el arnés, y las llamadas MCP del Modo Código se redirigen al arnés en lugar de proporcionar esos tokens al sandbox.

Esto reduce la superficie que contiene secretos y permite que el estado de la conversación sobreviva a un bloqueo del sandbox. También significa que el sandbox no es el perímetro de red para cada llamada de modelo y herramienta. El tráfico del proveedor de modelos y las operaciones MCP se originan a través de la ruta del arnés, y necesitan sus propios controles de puerta de enlace, identidad, credenciales y red.

El ciclo de vida documentado tiene el alcance de una sesión

TrueForge documenta el sandbox como desactivado por defecto para cada agente. Cuando se habilita y se necesita, se aprovisiona bajo demanda. El sandbox se reutiliza en los turnos de la misma sesión, por lo que los archivos persisten mientras continúa la conversación. Tras un periodo de inactividad, se detiene, se archiva y, finalmente, se elimina según la configuración del proveedor.

Ese ciclo de vida es más útil que un "contenedor desechable por prompt", pero introduce cuestiones de gestión de estado. Un archivo del Turno 1 puede influir en el Turno 5. Un archivo malicioso extraído al principio puede permanecer presente después de que se haya olvidado la tarea inmediata. Una dependencia instalada durante un turno puede cambiar la ejecución posterior. La continuidad de la sesión es una funcionalidad; la acumulación de estado no gestionada es un riesgo.

Las aplicaciones deben etiquetar los artefactos con su evento de origen, resumen de contenido, clasificación de datos y vida útil prevista. Antes de que un turno posterior ejecute un archivo, verifique que todavía pertenece a la tarea activa y que el usuario actual está autorizado para acceder a él. Cuando la reproducibilidad sea importante, registre la instantánea del sandbox o la identidad de la imagen, el estado de bloqueo de dependencias y los comandos que produjeron el artefacto.

La reutilización entre turnos se muestra como una funcionalidad y un riesgo. Los archivos pueden preservar el trabajo útil después de una pausa, pero cada artefacto restaurado necesita procedencia, clasificación y una regla de ciclo de vida en lugar de heredar la confianza solo de la sesión.

Las credenciales fuera del sandbox reducen, pero no eliminan, la autoridad

Mantener las credenciales del modelo y de MCP en el arnés evita que el código arbitrario del sandbox pueda leer esos secretos directamente. Se trata de un límite sólido. Sin embargo, un script en un sandbox aún podría solicitar al arnés que realice una llamada MCP a través de un puente controlado. La cuestión de seguridad relevante pasa a ser: ¿qué llamadas puede solicitar este código, con qué identidad, usando qué argumentos y bajo qué política?

El puente debe exponer una capacidad limitada en lugar de una credencial genérica. Las definiciones de herramientas, la identidad del sujeto, el destino, la clasificación de datos, los presupuestos acumulados y los requisitos de aprobación deben evaluarse fuera del sandbox. Los resultados devueltos al código deben minimizarse, ya que pueden convertirse en archivos, registros o entradas de comandos dentro del entorno.

Del mismo modo, la ausencia de credenciales del modelo no garantiza que el sandbox no tenga salida. La configuración del proveedor determina la accesibilidad a la red. Un despliegue robusto define por separado los destinos de salida, el comportamiento del DNS, la política de instalación de paquetes, el acceso al servicio de metadatos, los montajes del sistema de archivos, los límites de recursos y los controles de terminación. TrueForge orquesta el proveedor del sandbox; la organización sigue siendo responsable de validar dicho proveedor y su configuración frente a su modelo de amenazas.

Mapear explícitamente los límites de confianza

Exponer