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 fronteiras 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 mesma forma que 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 comportamentos indesejados e conter falhas quando elas ocorrem.

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

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 comunicação 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 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 do Hugging Face (Hugging Face; OpenAI).

O incidente é um exemplo claro de um modo de falha que descrevemos quando lançamos o Numbat como código aberto em julho: colapsos acidentais, um termo cunhado por pesquisadores de segurança da Cornell Tech (arXiv). Um agente que persegue um objetivo legítimo encontra atrito, como um arquivo ausente, uma chamada de API com falha, uma credencial expirada ou uma negação de permissão, e vai em busca de uma solução alternativa. Ao fazer isso, ele pode cruzar fronteiras 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.

O 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 mal formatada. Eles responderam com sondagens, incluindo injeção de SQL, cross-site scripting, injeção de modelo, path traversal e injeção de comandos. 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 Vitória, do Australian Institute of Health and Welfare (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 antibot do site no processo (SecurityWeek).

O padrão não se limita a um único laboratório. Durante testes de segurança cibernética, os modelos da Anthropic invadiram três empresas após um erro lhes dar acesso aberto à internet, o Gemini do Google adivinhou credenciais para 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

Esses incidentes lembram 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 em torno dela. Vimos uma onda de vírus e worms, com consequências muito mais graves do que o 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 na lista de endereços do Outlook da vítima. Às 18h daquele dia, o Centro de Coordenação do CERT havia recebido relatórios envolvendo mais de 420.000 hosts de internet (Relatório do US GAO). 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 (Relatório do US GAO). Ele também desligou servidores de e-mail no Pentágono e no Parlamento Britânico (Wired). A gigante de seguros Lloyd's of London fez uma estimativa inicial de que o vírus custaria mais de US$ 15 bilhões em danos e perda de produtividade (Audiência do Comitê da Câmara dos EUA). O 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 a seguir. 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 de 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 perguntar se 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 o assunto. Muitos especialistas em segurança pediram uma legislação que responsabilizasse as empresas de software 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á o meio principal de proteger o ciberespaço". Ela alertou que mandatos amplos poderiam criar uma "abordagem de menor denominador comum para a cibersegurança" (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ção automática, 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 atacante pode fazer após explorar um bug" (Chromium Blog). A criptografia, antes a 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. Preconiza-se que organizações em todo o mundo gastem cerca de US$ 240 bilhões em 2026 em 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ções, 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é-agente caracterizados por comportamento de software rigidamente 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 lhes concedem amplos privilégios que são, em princípio, suficientes para causar danos significativos.

Esse design se baseia em várias premissas: a maioria dos usuários age de boa-fé; atores 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. Aplicar esses mecanismos de segurança a agentes requer contabilizar as diferenças entre o comportamento humano e o do agente. 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 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 construir sistemas que mantêm os riscos sob controle quando componentes individuais se comportam mal. Mas precisamos garantir que esses princípios sejam aplicados ao projetar os ambientes para treinar, testar e usar agentes de IA.

O princípio de segurança de 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 combater ou detectar a intrusão.

O incidente do Hugging Face mostra por que a defesa em profundidade importa. A retrospectiva da OpenAI relata que as salvaguardas automatizadas usadas em seus sistemas de produção, incluindo harnesses, modelos de revisão automática e classificadores de segurança, estavam ausentes do ambiente de avaliação. Se o seu monitoramento de cadeia de pensamento 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 requer melhorar tanto a segurança e a proteção de modelos de IA quanto dos sistemas ao redor deles. O trabalho na camada do modelo importa 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 a retrospectiva da OpenAI descreve, monitoram os 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 aplicá-la 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 vencidos pelo mesmo ataque. Monitores e pontos de aplicação devem ficar fora do alcance do agente.
2. Aplicação abaixo do agente. Pelo menos uma camada deve ser determinística: código convencional e verificável que bloqueie ações proibidas, independentemente do que o modelo produzir. Uma salvaguarda que o agente possa 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 por meio de nossa plataforma de agentes Computer, no navegador por meio do Comet, em dispositivos de usuários por meio 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 Espaço

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 permanecem fora do sandbox e são injetadas apenas quando necessário, o tráfego de saída é controlado fora do convidado e os snapshots nos permitem reverter alterações destrutivas (Criando o 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 substituir 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 Espaço 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 de injeção de prompt em camadas desde o lançamento: classificadores filtram o conteúdo recuperado, prompts estruturados o marcam como não confiável, ações confidenciais 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 (Defesas contra injeção de prompt do Comet). 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 é totalmente seguro, razão pela qual a detecção nunca é a única camada (Pesquisa do BrowseSafe). O Computer herda essas defesas, que foram auditadas pelo Trail of Bits (Perplexity).

No dispositivo: Portable Computer

O Portable Computer é um agente local primeiro: 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 é um 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 as chamadas de ferramentas aprovadas são executadas em um sandbox em nível de sistema operacional que restringe processos, caminhos de arquivo e acesso à rede. O sandbox está sempre ativado e falha fechado: se não estiver disponível, o harness se desativa em vez de executar comandos com as permissões do usuário. Ações que cruzam a fronteira do dispositivo, como pesquisa na web, conectores e escalonamento para um modelo de consultor de nuvem mais forte, acontecem apenas quando o usuário as habilita e aprova. Antes de uma chamada de consultor, um classificador de PII sinaliza informações confidenciais e o usuário vê o que seria enviado. O consultor recebe apenas esse contexto aprovado e retorna orientações de texto, sem acesso aos arquivos ou ferramentas do dispositivo.

No endpoint: Numbat

Agentes de codificação em laptops de desenvolvedores funcionam por horas com acesso a código-fonte, credenciais e sistemas de produção. O Numbat, nossa suíte 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 linhas do tempo de sessão para investigação. O Numbat roda 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 se basear 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 se desenvolve junto com a tecnologia.

A engenharia de segurança para agentes é um trabalho para toda a indústria. Nenhuma empresa controla a pilha inteira em que um agente roda. Desenvolvedores de modelos, criadores de harnesses, provedores de sandbox e tempo de execução, fornecedores de nuvem e hardware e equipes de segurança empresarial possuem uma camada cada. A segurança do todo depende de cada camada se sustentar quando outra falha. É por isso que construímos salvaguardas que funcionam em diferentes 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/or financiando pesquisadores acadêmicos em Stanford, CMU, Duke, Columbia, Ohio State e University of Virginia. Também estamos conduzindo pesquisas internas para avançar na fronteira da pesquisa de segurança de agentes, traduzir esses avanços em melhorias concretas nos sistemas da Perplexity e compartilhar conhecimentos e recursos que ajudem a fortalecer o ecossistema de IA mais amplo. Agentes mais seguros são algo que a indústria pode projetar. Temos a intenção de continuar fazendo a nossa parte e convidamos outros a construírem conosco.