Seguridad del sandbox de agentes de IA: revisa cada acceso

La seguridad del sandbox de un agente de IA depende de dónde se ejecuta el código y de a qué le permites acceder. Una microVM proporciona a la carga de trabajo un kernel invitado independiente, lo que refuerza uno de los límites de aislamiento. Antes de que un agente reciba código fuente privado o un informe de vulnerabilidad no fiable, sigues necesitando pruebas de que el acceso a sus archivos, a la red, a las credenciales y a las herramientas externas, así como los resultados devueltos, se ajustan a los límites de la tarea.

Empieza con una pregunta concreta antes de dar tu aprobación: ¿qué puede leer y modificar el agente en esta ejecución, con qué destinos puede contactar y qué resultados puede hacer que tu equipo acepte? Documenta la respuesta para la configuración que vayas a utilizar. El diagrama de arquitectura de un producto ayuda a explicar su diseño; tu tarea también necesita una política de acceso y una forma de comprobar que se cumple.

Qué cambia una microVM

Una microVM separa el kernel de una carga de trabajo del kernel del host. Esto cambia el límite de ejecución respecto a un contenedor que comparte kernel, pero la configuración del host y los recursos compartidos de forma deliberada siguen siendo relevantes. La descripción general del sandbox de agentes de Vercel explica esta separación junto con los controles de archivos, red y credenciales.

En su explicación de la arquitectura del 4 de noviembre, Replit describe su migración a microVMs con Cloud Hypervisor, con contenedores dentro de las máquinas invitadas. También describe un monitor de máquinas virtuales sin privilegios, controles de red fuera de la máquina invitada para los sandboxes con una política de tráfico saliente e intermediarios de credenciales para los conectores gestionados. Son controles distintos en la descripción de Replit, no pruebas de que todas las solicitudes o los secretos aportados por los usuarios tengan la misma protección.

Una demostración independiente de Firecracker realizada por PWN Research muestra por qué las condiciones de arranque deben acompañar a las afirmaciones sobre seguridad. El investigador utilizó Firecracker v1.16.1 ejecutado como root y sin jailer, a partir de una capacidad de acceso a la memoria del host que había obtenido previamente. Esto no demuestra una fuga desde un despliegue de producción reforzado ni desde el entorno de Cloud Hypervisor de Replit. Las recomendaciones de Firecracker para hosts de producción exigen ejecución sin privilegios y confinamiento; no demuestran que un jailer necesariamente bloquearía el acceso subyacente a la memoria.

Si estás evaluando una compra, el siguiente paso útil es preguntar qué entorno de ejecución, qué privilegios y qué integraciones con el host utiliza realmente tu carga de trabajo. Conserva esas respuestas junto con la versión y la configuración que apruebes.

Enumera las conexiones que abres deliberadamente

Un agente dentro de un sandbox puede causar daños a través del acceso que le concedes de forma intencionada. Revisa esas conexiones incluso cuando el límite de ejecución funciona según lo previsto.

El modelo de seguridad del sandbox local de Docker explicita varias: montajes directos del directorio de trabajo, acceso a credenciales mediante proxy, acceso a firmas SSH y MCP servers externos. Advierte de que los cambios en el directorio de trabajo pueden alterar las rutas de ejecución del entorno de desarrollo y de que los MCP servers locales que usan stdio se ejecutan en el host. Son vías de integración que debes evaluar en esa configuración local, no pruebas de una fuga de la VM.

Responde a estas cuatro preguntas:

• Archivos: ¿ve el agente una copia desechable del código fuente o puede modificar la copia de trabajo que después compilarás y ejecutarás? Incluye los hooks, la configuración de compilación y las instrucciones al revisar los cambios devueltos.
• Red: ¿qué destinos, rutas y operaciones están permitidos? Un endpoint de inferencia autorizado recibe los datos que le envías. Una lista de destinos permitidos no basta para que esa divulgación sea aceptable.
• Credenciales: ¿qué puede hacer el agente con los permisos disponibles? Un intermediario puede ocultar la clave de API en bruto y, aun así, permitir llamadas autenticadas con amplias capacidades. Un socket de firma también requiere una decisión explícita.
• Herramientas: ¿dónde se ejecuta cada herramienta y qué identidad utiliza? Un proceso del host o una API remota necesita su propio límite de autorización.

Incluye el estado persistente en este inventario. Las cachés compartidas, las instantáneas guardadas y las instrucciones reutilizables para agentes pueden trasladar cambios a tareas posteriores. Decide quién se responsabiliza de cada elemento conservado y cómo vuelves a crear una ejecución limpia antes de suponer que una sesión nueva parte de un estado limpio.

Exige pruebas para cada límite

Aprueba una configuración específica mediante comprobaciones que puedas repetir. La tabla siguiente propone un registro de aceptación elaborado a partir de los límites de control anteriores. No recoge pruebas que hayamos realizado contra estos proveedores.

Utiliza secretos ficticios, entornos desechables y endpoints bajo tu control. No necesitas un exploit real ni exfiltrar datos reales para comprobar si se deniega el acceso prohibido por la política.

Adjunta a la aprobación la revisión de la política y los resultados de las comprobaciones. «Red restringida» aporta menos que un registro que muestre qué solicitud se bloqueó, qué solicitud autorizada funcionó y qué configuración produjo ambos resultados.

Superar las pruebas demuestra el funcionamiento de los controles comprobados en esa revisión. No demuestra que fallen todas las inyecciones de instrucciones, que todas las operaciones permitidas sean seguras ni que no exista ninguna vulnerabilidad de escape. Repite las comprobaciones afectadas cuando cambies un montaje, una herramienta, una política de tokens, el entorno de ejecución o una imagen persistente.

Ensaya una tarea de triaje de informes

Imagina un equipo hipotético que prepara un agente para leer un repositorio privado y un informe de vulnerabilidad recibido. El ejercicio de aceptación debe abarcar toda la tarea, incluido el resultado que devuelve.

1. Prepara datos de entrada desechables. Utiliza una copia del código fuente y un informe de muestra con tokens ficticios. Mantén desconectados las credenciales de producción y los informes reales.
2. Añade una instrucción de prueba inocua. Incluye en el informe de muestra instrucciones que pidan al agente contactar con un destino controlado por el equipo que la política prohíba. Documenta la denegación esperada antes de ejecutarlo.
3. Comprueba tanto la denegación como el trabajo útil. Mantén disponibles las rutas legítimas de inferencia y de envío de resultados del informe. Una ejecución que no puede contactar con nada no demuestra que el flujo previsto funcione.
4. Inspecciona lo que vuelve. Conserva el registro de la solicitud denegada, la configuración efectiva del entorno de ejecución y las referencias al informe, al commit y al pipeline. Comprueba que el servicio receptor rechace un resultado dirigido a otro informe y que rechace los campos adicionales no autorizados o impida su almacenamiento.
5. Define expresamente qué hacer si algo falla. Si la solicitud prohibida se completa, detente antes de conectar informes reales. Corrige la política y repite el ejercicio. Si un servicio autorizado recibe datos que no debería recibir, reconsidera los datos de entrada y limita las rutas o acciones permitidas de ese servicio cuando corresponda.

El registro de una solicitud intentada y de su denegación por la política demuestra el comportamiento de la vía comprobada. Si el agente simplemente ignora la instrucción maliciosa, eso no demuestra que los controles de red se apliquen. Ninguna de estas comprobaciones permite establecer que se contendrán todas las instrucciones maliciosas. Del mismo modo, un resultado con el formato correcto puede contener una conclusión errónea, por lo que la aceptación técnica debe dejar margen al criterio humano.

Si ya investigas un posible acceso indebido, la tarea ha cambiado. Utiliza un flujo de triaje de sondeos de agentes para conservar las pruebas y evaluar lo ocurrido antes de volver a las comprobaciones previas a la aprobación.

Mantén el resultado sujeto a revisión y dentro de su ámbito

La aplicación receptora necesita su propio límite incluso cuando la ejecución está bien aislada. Debe saber a qué recurso pertenece una ejecución, qué puede escribir y quién revisa sus conclusiones.

El triaje de Kit con acceso al código ilustra esta separación. Tú gestionas el entorno de ejecución y sus controles de tráfico saliente; Kit limita el intercambio del informe a su ámbito y recibe resultados de apoyo a la revisión. Kit pone en marcha el pipeline que has configurado. No aprovisiona una microVM ni configura y verifica de forma continua tu firewall.

La guía de aislamiento del agente de triaje describe un runner de GitLab autogestionado y operado por el cliente, con bloqueo de todo el tráfico saliente impuesto por el entorno y un proxy que valida tokens y solo permite rutas de inferencia y de Kit MCP. Trátala como una guía de implementación que debes configurar y probar. Un pipeline externo de CI no queda aislado de la red por el mero hecho de ejecutarse fuera de Kit, y las variables enmascaradas siguen siendo accesibles para el código que las recibe durante la ejecución.

En Kit, un token firmado identifica una ejecución de triaje concreta, su informe y su tenant. El token caduca al cabo de una hora y permite leer el informe, adjuntar pruebas y enviar resultados. Los campos de resultado aceptados están limitados, y la finalización bloquea las escrituras posteriores. Esa protección contra escrituras no significa que las lecturas del informe necesariamente cesen en cuanto finalice la ejecución; la caducidad del token es un límite independiente.

La evaluación devuelta sigue sirviendo de apoyo a la revisión humana. Utiliza la guía de configuración del agente de triaje para conectar el flujo y conserva después un registro de aprobación del entorno que aportas. El resultado práctico es una ejecución con límites definidos y pruebas conservadas, una condición clara para detenerla y una persona que decida qué ocurre a continuación.