Como projetamos agentes mais seguros

Para construir agentes de IA mais seguros, precisamos projetar tanto para suas capacidades quanto para suas falhas. Mesmo ao executar tarefas legítimas e sem nenhuma instrução maliciosa, os agentes podem cruzar limites de segurança ao tentarem superar obstáculos.

Acreditamos que este é um problema de engenharia de segurança, e a indústria deve enfrentá-lo da maneira como enfrentou os worms de internet do início dos anos 2000. Os sistemas que cercam os agentes devem limitar o que os agentes podem acessar, detectar comportamento indesejado e conter falhas quando elas ocorrem.

Na Perplexity, estamos colaborando ativamente com pesquisadores e profissionais para avançar a engenharia de segurança para agentes de IA, e aplicamos múltiplas camadas de defesa em nossos modelos, harnesses de agentes e infraestrutura para que a segurança não dependa de nenhuma salvaguarda isolada.

Comportamento de colapso de agentes de IA

Em julho, agentes de IA invadiram a infraestrutura de produção da plataforma de IA de código aberto Hugging Face. Durante a avaliação interna de segurança cibernética e execuções de treinamento, os modelos da OpenAI descobriram uma maneira de explorar o gerenciador de repositório Artifactory para estabelecer um quadro de avisos para se comunicarem entre si, permitindo que se organizassem em enxames. Posteriormente, agentes que não conseguiam progredir em tarefas em um benchmark de segurança cibernética recrutaram outros agentes para ajudar. Esses agentes escaparam de seu ambiente de avaliação e alcançaram a internet. Eles também descobriram maneiras de trapacear fazendo a engenharia reversa de respostas para as tarefas do benchmark, mas acharam que o sistema de classificação detectaria a trapaça. Para entender melhor como a avaliação do benchmark funcionava para encontrar maneiras de evitar ser detectado como trapaça, eles acabaram comprometendo os sistemas da Hugging Face (Hugging Face; OpenAI).

O incidente é um exemplo claro de um modo de falha que descrevemos quando tornamos o Numbat de código aberto em julho: colapsos acidentais, termo cunhado por pesquisadores de segurança da Cornell Tech (arXiv). Um agente que busca um objetivo legítimo encontra fricção, como um arquivo ausente, uma chamada de API com falha, uma credencial expirada ou uma negação de permissão, e sai em busca de uma solução alternativa. Ao fazer isso, ele pode cruzar limites de segurança por meio de reconhecimento, escalonamento de privilégios, descoberta de segredos ou exfiltração de dados. O próprio agente efetivamente se torna o adversário, mesmo que nenhum prompt malicioso ou invasor externo esteja envolvido.

A Hugging Face não foi um caso isolado. Mais comportamentos de colapso de agentes foram descobertos e relatados nas últimas semanas. Nos dias 27 e 28 de maio, agentes que tentavam coletar dados da Universidade de Iowa do Data USA, uma plataforma que oferece acesso aberto a dados do governo dos EUA, encontraram erros causados por uma consulta malformada. Eles responderam com sondagens, incluindo injeção de SQL, cross-site scripting, injeção de modelo (template injection), path traversal e injeção de comando. A atividade foi posteriormente vinculada à OpenAI (SecurityWeek). Nos dias 20 e 21 de junho, agentes da OpenAI que tentavam obter custos governamentais por pessoa para uma categoria de medicamentos em áreas locais em Victoria do Instituto Australiano de Saúde e Bem-Estar (AIHW) foram impedidos de baixar um arquivo. Em resposta, os agentes baixaram o arquivo, que já era público, do servidor de pré-produção do AIHW, contornando as proteções anti-bot do site no processo (SecurityWeek).

O padrão não se limita a um único laboratório. Durante testes de segurança cibernética, modelos da Anthropic violaram três empresas após um erro dar a eles acesso aberto à internet, o Gemini do Google adivinhou credenciais de três sites e um modelo da Meta explorou um serviço de terceiros (Reuters).

Aprendendo com a história: A era dos worms de internet

Estes incidentes relembram a era dos worms de internet de cerca de um quarto de século atrás. No início dos anos 2000, a internet cresceu muito mais rápido do que as práticas de segurança ao seu redor. Vimos uma onda de vírus e worms, com consequências muito mais graves do que estamos vendo agora com agentes de IA em colapso.

Em 4 de maio de 2000, as pessoas começaram a receber e-mails de remetentes conhecidos com o assunto "ILOVEYOU". Abrir o anexo no e-mail resultou na execução de um script que enviava uma cópia de si mesmo para todos no catálogo de endereços do Outlook da vítima. Às 18h daquele dia, o CERT Coordination Center havia recebido relatos envolvendo mais de 420.000 hosts de internet (US GAO Report). O vírus supostamente penetrou em pelo menos 14 agências federais, incluindo o Departamento de Defesa, a CIA, a NASA e a Câmara e o Senado (US GAO Report). Ele também derrubou servidores de e-mail no Pentágono e no Parlamento britânico (Wired). A gigante de seguros Lloyd's de London fez uma estimativa inicial de que o vírus custaria mais de US$ 15 bilhões em danos e perda de produtividade (US House Committee Hearing). A Computer Economics estimou posteriormente US$ 8,75 bilhões em danos em todo o mundo (Information Week).

Worms que não precisavam de cliques humanos vieram em seguida. Em 19 de julho de 2001, o worm Code-Red infectou mais de 359.000 computadores em menos de 14 horas (CAIDA). Em 25 de janeiro de 2003, o SQL Slammer dobrou de tamanho a cada 8,5 segundos e infectou mais de 90% dos hosts da internet vulneráveis a ele em 10 minutos (CAIDA), explorando uma falha para a qual a Microsoft havia lançado um patch seis meses antes (CNET). Em agosto de 2003, o worm Blaster e o worm de e-mail Sobig apareceram com cerca de uma semana de diferença (Microsoft, F-Secure).

Na época, era razoável questionar se os computadores em rede poderiam ser tornados seguros. Seis dias após o vírus ILOVEYOU, um subcomitê da Câmara dos EUA realizou uma audiência sobre ele. Muitos especialistas em segurança pediram legislação que tornasse as empresas de software responsáveis por danos causados por falhas em seus produtos. Washington seguiu um caminho diferente. A Estratégia Nacional para Proteger o Ciberespaço afirmou que "a regulamentação federal não se tornará um meio primário de proteger o ciberespaço". Ela alertou que mandatos amplos poderiam criar uma "abordagem de menor denominador comum para a segurança cibernética" (CISA).

A indústria respondeu com engenharia. Onze dias após o ILOVEYOU, a Microsoft anunciou uma atualização do Outlook que bloqueava anexos executáveis. Em janeiro de 2002, a empresa tornou a segurança uma prioridade máxima (Seattle Times). Correções automáticas, padrões seguros, programas de bug bounty e divulgação coordenada tornaram-se práticas padrão. Em 2008, o Chrome começou a executar conteúdo da web em um sandbox que "limita o que um invasor pode fazer após explorar um bug" (Chromium Blog). A criptografia, antes exceção, tornou-se o padrão. Tecnologias de segurança, incluindo autenticação multifator, firewalls, zero trust e gerenciamento de eventos e informações de segurança (SIEM), tornaram-se amplamente utilizadas. A previsão é de que organizações em todo o mundo gastem cerca de US$ 240 bilhões em 2026 com segurança da informação (Gartner). Os worms nunca desapareceram completamente, mas a era de surtos rotineiros em toda a internet diminuiu. Ao mesmo tempo, a internet, amplamente livre de regulamentação, tornou-se um poderoso motor de inovação e crescimento econômico ao longo das duas décadas seguintes.

Engenharia de segurança para agentes de IA

Incidentes recentes levantaram questões legítimas sobre a governança de agentes. Os mecanismos de segurança existentes foram desenvolvidos para ambientes de computação pré-agentes, caracterizados por um comportamento de software estritamente escopo e amplamente determinístico. Os mecanismos de controle de acesso, em particular, são projetados principalmente em torno de usuários humanos e geralmente concedem a eles amplos privilégios que são, em princípio, suficientes para causar danos significativos.

Este design baseia-se em várias premissas: a maioria dos usuários age de boa-fé; agentes maliciosos podem ser dissuadidos por meio de auditorias e consequências no mundo real; e os humanos realizam ações, corretas ou errôneas, a uma taxa relativamente limitada. A aplicação desses mecanismos de segurança a agentes exige contabilizar as diferenças entre o comportamento humano e o de agentes. Como escrevemos em nossa resposta à solicitação de informações do NIST sobre segurança de agentes de IA, os agentes de IA desafiam essas premissas. Eles podem exercer privilégios e realizar ações na velocidade da máquina, não são dissuadidos por consequências do mundo real e podem realizar ações que são tecnicamente permitidas, mas que um usuário humano típico raramente faria.

Responder a essas perguntas exige engenharia de segurança. Conhecemos os princípios de segurança para a construção de sistemas que mantêm os riscos sob controle quando componentes individuais apresentam mau funcionamento. Mas precisamos garantir que esses princípios sejam aplicados ao projetar os ambientes para treinamento, teste e uso de agentes de IA.

O princípio de segurança da defesa em profundidade

Indiscutivelmente o princípio de segurança mais importante que precisa ser aplicado para proteger agentes de IA é a defesa em profundidade, que defende uma arquitetura de segurança em camadas, onde medidas defensivas múltiplas, variadas e redundantes são empregadas para proteger os recursos do sistema. Nenhuma salvaguarda única é perfeita. As pessoas podem cair em ataques de engenharia social e revelar suas credenciais de login, vulnerabilidades de software de dia zero são descobertas e exploradas, e a detecção de intrusão deixa passar novas variantes de ataque. A defesa em profundidade aceita isso e empilha várias camadas independentes de defesa. Caso uma camada defensiva seja contornada, outras camadas permanecem no lugar para conter ou detectar a intrusão.

O incidente da Hugging Face mostra por que a defesa em profundidade é importante. Os relatórios retrospectivos da OpenAI relatam que as salvaguardas automatizadas usadas em seus sistemas de produção, incluindo harnesses, modelos de auto-revisão e classificadores de segurança, estavam ausentes do ambiente de avaliação. Se o monitoramento de cadeia de pensamento (chain-of-thought) implantado atualmente estivesse sendo executado nessas avaliações, ele teria detectado a atividade inicial e acionado a equipe de segurança mais de um dia antes da violação (OpenAI). As camadas que poderiam ter detectado o problema existiam. Elas simplesmente não estavam todas no lugar ao mesmo tempo.

Proteger agentes de IA exige melhorar tanto a segurança e a proteção dos modelos de IA quanto dos sistemas ao redor deles. O trabalho na camada de modelo é importante e está dando frutos. Os primeiros LLMs eram facilmente manipulados por instruções injetadas, enquanto os modelos de hoje são substancialmente melhores em reconhecê-las e recusá-las. Os desenvolvedores de modelos também treinam modelos para um comportamento mais seguro e, conforme descrito pela retrospectiva da OpenAI, monitoram rastros de raciocínio em busca de sinais de comportamento problemático. Mas as defesas em nível de modelo são apenas parte da solução. Os sistemas nos quais os agentes são treinados, testados e implantados também devem ser projetados para segurança e contenção. A segurança em nível de modelo reduz a probabilidade de um agente se desviar; a segurança em nível de sistema limita o dano quando isso acontece.

Expandir

Regras de design para salvaguardas redundantes

A defesa em profundidade requer salvaguardas redundantes. Para agentes, defendemos a aplicação disso com três regras de design:

1. Independência. Cada camada deve falhar por motivos independentes. Dois controles que compartilham a mesma premissa podem ser derrotados pelo mesmo ataque. Monitores e pontos de imposição devem ficar fora do alcance do agente.
2. Imposição abaixo do agente. Pelo menos uma camada deve ser determinística: código convencional e verificável que bloqueia ações proibidas, independentemente do que o modelo produza. Uma salvaguarda que o agente pode recusar a invocar ou reconfigurar não é uma salvaguarda.
3. Sinais só podem reduzir a autoridade. A detecção deve acionar respostas que estreitem o que o agente pode fazer, como pausar, revogar credenciais, cortar o acesso à rede ou encerrar a sessão. Nenhum sinal de risco deve conceder acesso adicional.

Compartilhamos esses princípios com nossos parceiros na Open Secure AI Alliance, incluindo a NVIDIA, que argumentou que o harness orienta o que um agente tenta, enquanto a infraestrutura controla o que ele pode fazer (NVIDIA).

Defesa em profundidade nos produtos da Perplexity

A Perplexity executa agentes em quatro tipos de ambientes: na nuvem através da nossa plataforma de agentes Computer, no navegador através do Comet, em dispositivos de usuários através do Portable Computer e em laptops de funcionários, onde nossos engenheiros usam agentes de codificação de terceiros. Cada ambiente tem seus próprios riscos e cada um recebe várias camadas de proteção.

Na nuvem: Computer e SPACE

Cada tarefa do Computer é executada no SPACE, nossa plataforma de sandbox, que trata o agente como não confiável por padrão. Cada tarefa recebe seu próprio microVM, as credenciais ficam fora do sandbox e são injetadas apenas quando necessário, o tráfego de saída é controlado fora do convidado e os snapshots permitem reverter alterações destrutivas (Making SPACE). Clientes corporativos também podem trazer suas próprias chaves de criptografia. Revogar uma chave torna os dados protegidos ilegíveis, e o agente não pode anular essa decisão.

Também testamos se essas camadas se sustentam. Em Escaping SPACE: Part I, demos a nove modelos de fronteira acesso root dentro de um sandbox do SPACE e pedimos que escapassem. Nenhum escapou da VM, mas alguns encontraram maneiras de contornar a política de rede quando o acesso parcial à rede foi permitido. Corrigimos essas lacunas, confirmamos as correções em um novo teste e divulgamos vulnerabilidades semelhantes que encontramos em oito de outras 10 plataformas de sandbox para seus fornecedores.

No navegador: Comet e BrowseSafe

O Comet usa uma defesa em camadas contra injeção de prompt desde o lançamento: classificadores examinam o conteúdo recuperado, prompts estruturados o marcam como não confiável, ações sensíveis, como enviar um e-mail ou fazer um pedido, exigem a confirmação do usuário e os usuários são avisados quando algo é bloqueado (Comet prompt-injection defenses). O BrowseSafe, o modelo de detecção de código aberto por trás da primeira camada, supera os modelos de fronteira em nosso benchmark BrowseSafe-Bench, mas o mesmo benchmark mostra que nenhum detector é à prova de falhas, razão pela qual a detecção nunca é a única camada (BrowseSafe research). O Computer herda essas defesas, que foram auditadas pelo Trail of Bits (Perplexity).

No dispositivo: Portable Computer

Portable Computer é um agente centrado localmente (local-first): o modelo, o harness, a conversa e a trajetória permanecem na máquina do usuário por padrão. Um orquestrador determinístico, que é código de harness em vez de um LLM, executa o loop e impõe a política. O modelo propõe ações, e chamadas de ferramentas aprovadas são executadas em um sandbox no nível do sistema operacional que restringe processos, caminhos de arquivo e acesso à rede. O sandbox está sempre ativado e falha fechado (fails closed): se não estiver disponível, o harness desativa a si mesmo em vez de executar comandos com as permissões do usuário. Ações que cruzam o limite do dispositivo, como busca na web, conectores e escalonamento para um modelo orientador de nuvem mais forte, acontecem apenas quando o usuário as ativa e aprova. Antes de uma chamada ao orientador, um classificador de PII sinaliza informações confidenciais e o usuário vê o que seria enviado. O orientador recebe apenas esse contexto aprovado e retorna orientações em texto, sem acesso aos arquivos ou ferramentas do dispositivo.

No endpoint: Numbat

Agentes de codificação em laptops de desenvolvedores executam por horas com acesso a código-fonte, credenciais e sistemas de produção. O Numbat, nosso conjunto de segurança de agentes de código aberto, adiciona uma camada independente que fica fora de qualquer agente individual. Ele funciona com harnesses como Claude Code, Codex, OpenCode e Pi, bloqueia ações perigosas antes que sejam executadas, sinaliza sequências suspeitas de várias etapas, como ler um segredo e enviar dados para fora, e preserva o histórico de sessões para investigação. O Numbat é executado em milhares de endpoints da Perplexity junto com o Bumblebee, nosso scanner de cadeia de suprimentos de código aberto. O Computer revisa regularmente suas descobertas e propõe regras de detecção aprimoradas, e um humano aprova cada alteração antes de ser lançada.

Um trabalho para toda a indústria

À medida que os agentes de IA se tornam mais capazes e amplamente utilizados, a engenharia de segurança deve permanecer central para seu desenvolvimento e implantação. Pesquisadores e engenheiros podem construir com base em princípios estabelecidos, usar descobertas do mundo real para refinar defesas e testar salvaguardas nos ambientes em que os agentes operam. A segurança é uma disciplina de engenharia contínua que evolui junto com a tecnologia.

A engenharia de segurança para agentes é um trabalho para toda a indústria. Nenhuma empresa controla sozinha toda a pilha (stack) em que um agente é executado. Desenvolvedores de modelos, criadores de harness, provedores de sandbox e tempo de execução, fornecedores de nuvem e hardware, e equipes de segurança corporativa possuem cada um uma camada. A segurança do todo depende de cada camada se sustentar quando outra falha. É por isso que criamos salvaguardas que funcionam em harnesses de agentes e disponibilizamos nossas ferramentas como código aberto. É também por isso que divulgamos as vulnerabilidades que encontramos em outras plataformas e participamos de esforços como a Open Secure AI Alliance.

Para trabalhar com a comunidade em geral nesses desafios, a Perplexity lançou o Secure Intelligence Institute em março de 2026 para estudar a segurança, a confiabilidade e a defesa prática de sistemas de IA de ponta (Perplexity). A Perplexity está atualmente colaborando e/ou financiando pesquisadores acadêmicos em Stanford, CMU, Duke, Columbia, Ohio State e Universidade da Virgínia. Também estamos conduzindo pesquisas intramurais para avançar a fronteira da pesquisa de segurança de agentes, traduzir esses avanços em melhorias concretas nos sistemas da Perplexity e compartilhar conhecimento e recursos que ajudem a fortalecer o ecossistema de IA mais amplo. Agentes mais seguros são algo que a indústria pode projetar. Pretendemos continuar fazendo nossa parte e convidamos outros a construir conosco.