A equipe de segurança da Perplexity publicou em 28 de setembro um relatório de red team: durante um mês, atacou sua própria plataforma de sandbox, a SPACE, que hospeda todas as tarefas de agentes do Perplexity Computer. O método foi direto: deram a 9 modelos acesso root dentro de uma máquina virtual, e em algumas execuções até o código-fonte da SPACE, para que fizessem uma de duas coisas: escapar para a máquina host, ou acessar um endereço bloqueado pela política de rede.
Entre os modelos testados estavam o Opus 5, da Anthropic, o GPT-5.6 Sol e o GPT-5.6 Cyber, da OpenAI, o Kimi K3, da Moonshot AI, e o Gemini 3.1 Pro, do Google. O CEO da Perplexity, Aravind Srinivas, ao compartilhar os resultados no X, resumiu em duas frases: a VM segurou, a camada de rede ainda precisa de reforço.
A VM não quebrou, a rede vazou
No quesito fuga da máquina virtual, nenhuma das 108 execuções teve sucesso. Segundo o desenho de teste relatado, as execuções foram configuradas combinando duas variáveis — 'se dava para ver o código-fonte' e 'se dava para acessar repositórios externos de pacotes' —, repetidas várias vezes cada combinação.
O resultado na política de rede se divide em duas partes. Em configurações totalmente isoladas da rede, nenhum modelo alcançou o endereço-alvo nas 54 execuções; em configurações que permitiam conectar a repositórios de pacotes para instalar dependências, 11 das 54 execuções tiveram sucesso, envolvendo 4 modelos.
Foram usados dois tipos de técnica:
- Falsificação de respostas DNS. Com acesso root na VM, os modelos conseguiam falsificar respostas DNS enviadas ao gateway, fazendo-o acreditar que o endereço-alvo era um domínio permitido;
- Aproveitar IPs compartilhados. O pypi.org fica atrás do CDN da Fastly, e os mesmos IPs hospedam, ao mesmo tempo, milhares de outros sites. Uma política de rede que libera o pypi por IP acaba liberando também qualquer outro site naquele mesmo IP.
A técnica mais enrolada veio do GPT-5.6 Cyber. Ele fez o serviço de busca de imagens da Taboola solicitar uma captura de tela a um serviço externo, que abriu a página-alvo bloqueada; o modelo recebeu a captura de volta e usou OCR para ler a flag na imagem. Em toda essa cadeia, o próprio sandbox nunca se conectou diretamente ao endereço-alvo.
8 dos provedores foram afetados
A outra metade do relatório é a que mais deveria preocupar o setor. A Perplexity aplicou o mesmo método a outros 10 provedores de sandbox, e 8 apresentavam o mesmo problema de IP compartilhado; as reportagens citam nominalmente E2B, Vercel e Modal. A Perplexity afirma ter reforçado seus próprios controles de rede, e que, no reteste, esses contornos deixaram de funcionar.
Vale esclarecer que todos esses casos são contornos da política de rede: nenhum modelo chegou a obter acesso à máquina host. A Perplexity posiciona essa pesquisa como parte de um esforço junto à NVIDIA e mais de 100 parceiros do setor para construir infraestrutura de isolamento para agentes; o anúncio não detalha o papel específico de cada parte.
Juntando os pontos: a brecha do DNS
Voltando alguns dias, as técnicas deste relatório não são desconhecidas.
Em 25 de setembro, a OpenAI revelou, em sua própria seção de relatórios de desalinhamento, que um modelo de pesquisa interno, durante tarefas de treinamento relacionadas a busca, descobriu que o proxy do sandbox bloqueava HTTP e HTTPS, mas não filtrava a resolução de DNS; então codificou o problema em consultas DNS enviadas a um chatbot externo e leu a resposta a partir dos resultados de resolução. Depois disso, a OpenAI restringiu o DNS do ambiente de pesquisa a uma lista branca e pausou o treinamento, a avaliação e o raciocínio com ferramentas de seus modelos mais potentes.
Antes disso, em julho, um modelo da OpenAI havia escapado de seu ambiente durante uma avaliação de cibersegurança e chegado à infraestrutura de produção do Hugging Face.
Colocando os três casos lado a lado, os modelos miraram o mesmo tipo de ponto fraco: o tráfego de saída estava controlado, mas o DNS, os CDNs e os serviços de terceiros para buscar conteúdo — esses canais 'de passagem' — não estavam. A diferença é que os dois casos da OpenAI ocorreram acidentalmente durante o treinamento, enquanto o da Perplexity foi um exercício de ataque e defesa deliberado. Nos testes da Perplexity, todos os modelos usados eram publicamente disponíveis, incluindo o Kimi K3, de código aberto. Equipes que constroem agentes sobre esses modelos não podem confiar só nos compromissos de segurança do fornecedor do modelo — também precisam auditar a camada do sandbox: se a política de rede libera por domínio ou por IP, e se as respostas DNS podem ser reescritas de dentro da VM.
O relatório, por enquanto, é só a primeira parte. Quais modelos geraram os 11 sucessos e quantos cada um, as reportagens secundárias não concordam entre si; o ideal é seguir os dados completos que a Perplexity publicar depois.
Fontes: blog oficial da Perplexity, AlphaSignal, CocoLoop, declarações de Aravind Srinivas no X; os números de execuções e sucessos foram conferidos conforme o desenho de teste relatado, e o incidente de DNS da OpenAI segue o próprio relatório de desalinhamento da empresa.