Laboratorio de contención del tráfico saliente del ejecutor de agentes
Contén cada petición saliente del ejecutor de código de un agente de IA: decisión de salida, riesgo y control adecuado.
Abrir la herramienta →La herramienta interactiva se abre en inglés.
Un agente de IA ejecuta código generado por el modelo en un ejecutor, y ese ejecutor no para de conectarse hacia fuera: a la documentación, a un dominio desconocido, al endpoint de metadatos de la nube (169.254.169.254), a un servicio interno, a un registro de paquetes, a un sitio de pastes, a la API del proveedor del modelo y, durante una ejecución puntuada, al host de la rúbrica del benchmark. En cada petición eliges la DECISIÓN DE SALIDA (permitir, permitir a través de proxy con registro o denegar), el RIESGO (benigno, exfiltración de datos/C2, SSRF, contaminación de la evaluación, cadena de suministro o robo de credenciales mediante los metadatos de la nube) y el CONTROL que de verdad encaja. La motivación es real y atribuida: Harness² de Google Cloud AI Research (arXiv 2610.14224) informa de que el acceso a la red de su ejecutor es ILIMITADO y de que el ejecutor de Codex funciona con el SANDBOX DESACTIVADO, y advierte de que hay que restringir la red antes de evaluar para que los agentes no puedan llegar a las respuestas del benchmark ni a las rúbricas de evaluación. La habilidad que entrena: salida denegada por defecto con una lista de permitidos corta, rangos link-local, de metadatos de la nube e internos siempre denegados, el ejecutor en sandbox antes de ejecutar código generado por el modelo y los hosts de evaluación y rúbricas bloqueados durante la puntuación, sin bloquear de más la API del proveedor del modelo, la documentación ni un mirror verificado. Porque denegar por defecto no es denegarlo todo. Incluye un registro de salida en directo, un mapa de destino × riesgo, niveles de dificultad, bonificación por velocidad y una nota de S a D, sin CVE inventados. Es un laboratorio Pro: con una cuenta gratuita tienes 3 usos de herramientas Pro en total y después necesitas Pro.
- Lee cada petición saliente o comportamiento en tiempo de ejecución del ejecutor.
- Elige la decisión de salida: permitir, permitir a través de proxy con registro o denegar.
- Nombra el riesgo y elige el control que encaja.
- Revisa el registro de salida, el mapa de destino × riesgo y tu nota de S a D; no bloquees de más los destinos legítimos.
Preguntas frecuentes
¿Qué enseña el laboratorio de contención del tráfico saliente del ejecutor de agentes?
Enseña a contener la red y el tiempo de ejecución del entorno de ejecución de código de un agente de IA (el «ejecutor»). En cada petición saliente o comportamiento en tiempo de ejecución decides la salida (permitir, permitir a través de un proxy con registro o una lista de permitidos, o denegar), nombras el riesgo y eliges el control que encaja. El laboratorio hace explícita la distinción clave: una postura de salida denegada por defecto no es lo mismo que denegarlo todo; unos pocos destinos, como la API del proveedor del modelo, la documentación y un mirror de paquetes verificado, son legítimos y deben permitirse a través de un proxy, mientras que los POST desconocidos, las subidas a sitios de pastes, los canales salientes arbitrarios, los servicios internos y el endpoint de metadatos de la nube se deniegan.
¿El escenario del «ejecutor sin restricciones» se basa en algo real?
Sí. Se atribuye al artículo Harness² de Google Cloud AI Research (arXiv 2610.14224), que informa de que el acceso a la red de su ejecutor no tiene restricciones y de que el ejecutor de Codex funciona con el sandbox desactivado, y advierte expresamente a los operadores de que restrinjan el acceso a la red del ejecutor antes de evaluar para que los agentes no puedan llegar a las respuestas del benchmark ni a las rúbricas de evaluación. El laboratorio convierte esa advertencia en práctica: salida denegada por defecto, el ejecutor en sandbox y los hosts de evaluación y rúbricas bloqueados durante la puntuación, para que la medición refleje al agente y no respuestas recuperadas. El laboratorio no inventa CVE ni contiene detalles de exploits.
¿Por qué el endpoint de metadatos de la nube (169.254.169.254) siempre se deniega?
Porque el servicio de metadatos link-local entrega credenciales IAM temporales de la nube a cualquier cosa de la instancia que pueda alcanzarlo. Un entorno de ejecución de código que llega a 169.254.169.254 (o a un alias amigable como metadata.google.internal, que resuelve a la misma dirección link-local) es un robo de credenciales esperando a ocurrir. No hay ninguna razón legítima para que el ejecutor lo llame, así que el control es denegar de forma estricta los rangos link-local y de metadatos en el perímetro de red y dar a la carga de trabajo una identidad mínima y acotada en lugar de credenciales de todo el nodo. Es la defensa estándar contra SSRF y el abuso de los metadatos de la nube.
¿Es un proxy real o toca mi red?
No. Es un ejercicio de triaje educativo y sin conexión, con un conjunto sintético de peticiones. No se conecta a ninguna red, no la intermedia ni la toca, y no contiene detalles de exploits: solo la decisión del defensor sobre la salida, el riesgo y el control. Está pensado para desarrollar el criterio que usa un responsable de seguridad de plataforma o de infraestructura de ML al decidir a qué puede y a qué no puede llegar el ejecutor de un agente.
¿Es gratis?
No, es un laboratorio Pro. Con una cuenta gratuita tienes 3 usos de prueba de herramientas Pro en total; después necesitas Pro.