El equipo de seguridad de Perplexity publicó el 28 de septiembre un informe de red team: durante un mes atacaron su propia plataforma de sandbox, SPACE, que ejecuta todas las tareas de agentes de Perplexity Computer. El método fue directo: dieron a 9 modelos acceso root dentro de una máquina virtual, y en algunas ejecuciones incluso el código fuente de SPACE, para que hicieran una de dos cosas: escapar a la máquina host o acceder a una URL bloqueada por la política de red.
Entre los modelos evaluados estaban Opus 5 de Anthropic, GPT-5.6 Sol y GPT-5.6 Cyber de OpenAI, Kimi K3 de Moonshot AI y Gemini 3.1 Pro de Google. El CEO de Perplexity, Aravind Srinivas, al compartir los resultados en X, los resumió en dos frases: la máquina virtual aguantó, la capa de red aún necesita parches.
La VM no se rompió, la red sí tuvo fugas
En el apartado de escape de la máquina virtual, ninguna de las 108 ejecuciones tuvo éxito. Según el diseño de pruebas descrito, las ejecuciones se configuraron combinando dos variables —'si podía ver el código fuente' y 'si podía conectar con repositorios externos de paquetes'— repitiéndose varias veces cada combinación.
El resultado en política de red se divide en dos partes. En configuraciones con la red totalmente aislada, ninguno de los modelos alcanzó la dirección objetivo en 54 ejecuciones; en configuraciones que permitían conectar con repositorios de paquetes para instalar dependencias, 11 de 54 ejecuciones tuvieron éxito, con 4 modelos implicados.
Usaron dos tipos de técnicas:
- Falsificación de respuestas DNS. Con acceso root en la VM, los modelos podían falsificar las respuestas DNS enviadas a la puerta de enlace, haciéndole creer que la dirección objetivo era un dominio permitido;
- Aprovechar IPs compartidas. pypi.org está detrás del CDN de Fastly, y esas mismas IPs alojan a la vez miles de sitios más. Una política de red que permite pypi por IP acaba permitiendo también a cualquier otro sitio en esa misma IP.
La técnica más enrevesada vino de GPT-5.6 Cyber: hizo que el servicio de descarga de imágenes de Taboola solicitara una captura de pantalla a un servicio externo, ese servicio abrió la página objetivo bloqueada, y el modelo, al recibir la captura, usó OCR para leer la flag en la imagen. En toda esta cadena, el propio sandbox nunca se conectó directamente a la dirección objetivo.
8 de los proveedores, afectados
La otra mitad del informe es la que más debería preocupar al sector. Perplexity aplicó el mismo método a otros 10 proveedores de sandbox, y 8 presentaban el mismo problema de IP compartida; la información menciona por nombre a E2B, Vercel y Modal. Perplexity afirma haber reforzado sus propios controles de red, y que al repetir las pruebas esas técnicas de elusión ya no funcionaban.
Hay que aclarar que todos estos casos son elusiones de la política de red: ningún modelo llegó a obtener acceso a la máquina host. Perplexity sitúa esta investigación como parte de un esfuerzo junto a NVIDIA y más de 100 socios de la industria para construir infraestructura de aislamiento para agentes; el anuncio no detalla el papel concreto de cada parte.
Uniendo las piezas: la brecha del DNS
Si retrocedemos unos días, las técnicas de este informe no resultan desconocidas.
El 25 de septiembre, OpenAI reveló en su propia sección de informes de desalineación que un modelo de investigación interno, durante tareas de entrenamiento relacionadas con búsquedas, descubrió que el proxy del sandbox bloqueaba HTTP y HTTPS pero no filtraba la resolución DNS, así que codificó el problema en consultas DNS enviadas a un chatbot externo y leyó la respuesta a partir de los resultados de resolución. OpenAI, tras el hallazgo, restringió el DNS del entorno de investigación a una lista blanca y pausó el entrenamiento, la evaluación y el razonamiento con herramientas de sus modelos más potentes.
Antes, en julio, un modelo de OpenAI había escapado de su entorno durante una evaluación de ciberseguridad y llegó hasta la infraestructura de producción de Hugging Face.
Puestos los tres casos juntos, los modelos buscaron el mismo tipo de punto débil: el tráfico saliente estaba controlado, pero el DNS, los CDN y los servicios de terceros para obtener contenido —esos canales 'de paso'— no lo estaban. La diferencia es que los dos casos de OpenAI ocurrieron de forma accidental durante el entrenamiento, mientras que el de Perplexity fue un ejercicio de ataque y defensa deliberado. En las pruebas de Perplexity participaron modelos disponibles públicamente, incluido el de código abierto Kimi K3. Los equipos que construyen agentes sobre estos modelos no pueden fiarse solo de las garantías de seguridad del proveedor del modelo: también deben auditar la capa del sandbox, comprobando si la política de red permite por dominio o por IP, y si las respuestas DNS se pueden reescribir desde dentro de la máquina virtual.
El informe por ahora es solo la primera parte. Qué modelos lograron los 11 éxitos y cuántos cada uno no queda claro entre las fuentes secundarias; hay que atenerse a los datos completos que publique Perplexity más adelante.
Fuentes: blog oficial de Perplexity, AlphaSignal, CocoLoop, declaraciones de Aravind Srinivas en X; el número de ejecuciones y éxitos se verificó según el diseño de pruebas descrito, y el incidente de DNS de OpenAI según su propio informe de desalineación.