A Detecção e Resposta em Endpoints passou duas décadas respondendo bem a uma pergunta: este processo está fazendo algo que um código malicioso faria? Ela verifica assinaturas, observa comportamentos anômalos e sinaliza escalonamentos de privilégio não autorizados. Um agente de IA com acesso a ferramentas quebra a premissa dessa pergunta, não por ser um código malicioso, mas por ser um programa confiável que pode ser convencido a usar mal o próprio acesso, inteiramente legítimo, que já possui.
A versão pré-IA desse problema já tem nome
Usar um programa legítimo e assinado para fazer algo malicioso não é novidade. A MITRE ATT&CK cataloga isso como System Binary Proxy Execution (T1218): "binários assinados com certificados digitais confiáveis normalmente conseguem ser executados em sistemas Windows protegidos por validação de assinatura digital", o que explica exatamente por que listas de permissão e verificações de assinatura têm dificuldade quando o próprio binário confiável é a coisa que está agindo. Um agente de IA estende a mesma fraqueza a um programa que nem precisa vir pré-carregado com código malicioso: ele pode ser redirecionado em tempo de execução, por um texto que lê.
Um agente sequestrado é um "confused deputy"
O termo aplicável aqui é o confused deputy problem: "um programa de computador que é enganado por outro programa (com menos privilégios ou menos direitos) para usar mal sua autoridade". Dê a um agente ferramentas reais, depois deixe-o ler conteúdo que você não verificou, e ele pode ser instruído por esse conteúdo. É exatamente o padrão descrito na entrada da OWASP sobre injeção de prompt, e isso já foi demonstrado, não apenas teorizado: o relatório da Invariant Labs de 26 de maio de 2025 mostrou um agente de codificação que, ao ler uma issue de aparência comum em um repositório público do GitHub, seguiu instruções ocultas nela para expor dados de um repositório privado, usando ferramentas que lhe haviam sido concedidas legitimamente. A conclusão dos próprios pesquisadores: "isso não é uma falha no código do servidor MCP do GitHub em si, mas sim uma questão arquitetural fundamental que precisa ser resolvida no nível do sistema do agente".
process: python3 agent_worker.py --tool-socket 8443
user: developer (normal UID, no privilege escalation)
network: HTTPS POST to a domain the process has contacted before
signature: none matched, no known-bad hash
behaviour: consistent with routine developer tooling
# The same log line is produced whether agent_worker.py just fetched
# documentation the developer asked for, or was redirected by injected
# instructions to read a private file and POST it out.Esse é o ponto cego real: não uma falha em um produto específico, mas o fato de que o registro de log para "o agente fez o trabalho normal dele" e "o agente foi sequestrado para usar mal o trabalho normal dele" pode ser idêntico no nível do processo. Nada no binário mudou. Nada no padrão de chamadas de sistema é novo. Só a intenção por trás do pedido mudou, e intenção não é um campo em um log de processo.
O que realmente reduz isso, e o que não reduz
Vale ser preciso sobre o que a pessoa que nomeou esse padrão de fato recomenda. Simon Willison, que descreveu a "trifecta letal" formada por acesso a dados privados, exposição a conteúdo não confiável e comunicação externa reunidos em um único agente, é explícito ao afirmar que evitar essa combinação é a correção real, não uma proteção adicional: "a única forma de ficar seguro nesse caso é evitar por completo essa combinação de trifecta letal". Ele é abertamente cético em relação a produtos que afirmam capturar de forma confiável instruções injetadas depois do fato, observando que "ainda não sabemos como evitar isso com 100 por cento de confiabilidade" e que uma taxa de captura de 95 por cento é "definitivamente uma nota reprovadora" para um controle de segurança.
- Design em primeiro lugar: dê ao agente as ferramentas e o acesso a dados mais estreitos que a tarefa exige, para que haja menos coisa para uma injeção bem-sucedida explorar (a correção arquitetural para a qual tanto Willison quanto a Invariant Labs apontam).
- Trate qualquer conteúdo que o agente leia e que você não tenha escrito ou verificado — issues, páginas obtidas, arquivos baixados — como entrada não confiável, por princípio, sempre.
- Onde design e revisão não bastam, o único passo que uma tentativa de exfiltração de dados não consegue pular é uma conexão de rede de saída. Observar ou restringir isso, por processo, não impede que um agente seja enganado, mas é uma camada real e independente que não depende de reconhecer a instrução injetada em primeiro lugar.
Onde FireAI e HisnLabs entram nessa história
No firewall makes a hijacked agent safe on its own, but the data it tries to send out still has to leave through a socket, and that is the one step FireAI watches regardless of which trusted binary the agent is running inside of.
O FireAI é o produto da HisnLabs: um firewall com IA que roda direto no seu Mac. Ele mostra, em linguagem simples, cada conexão que seus aplicativos fazem e deixa você decidir o que sai do seu Mac — a IA roda localmente, então seu tráfego nunca é enviado para nós nem para ninguém. A equipe de pesquisa em segurança da HisnLabs é quem mantém essas decisões confiáveis: cataloga quais domínios são telemetria comum e quais são um serviço de verdade, rastreia o país e a rede por trás de uma conexão e treina o modelo local (o recurso Autopilot) com padrões reais de tráfego, sem que nada disso saia do seu Mac.
Você pode ler as decisões técnicas por trás dele, ou testar o FireAI por 17 dias, em FireAI, da HisnLabs.