A Deteção e Resposta de Endpoint (EDR) passou duas décadas a responder bem a uma pergunta: este processo está a fazer algo que código malicioso faria? Verifica assinaturas, vigia comportamentos anómalos e sinaliza escaladas de privilégio não autorizadas. Um agente de IA com acesso a ferramentas quebra a premissa dessa pergunta, não por ser código malicioso, mas por ser um programa de confiança que pode ser convencido a fazer mau uso do seu próprio acesso, inteiramente legítimo.
A versão pré-IA deste problema já tem um nome
Usar um programa legítimo e assinado para fazer algo malicioso não é novo. O MITRE ATT&CK cataloga-o como Execução por Procuração via Binário do Sistema (T1218): "binários assinados com certificados digitais de confiança podem tipicamente executar em sistemas Windows protegidos por validação de assinatura digital", que é exatamente a razão pela qual as listas de permissões e as verificações de assinatura têm dificuldade assim que o próprio binário de confiança é a coisa que age. Um agente de IA estende a mesma fragilidade a um programa que nem sequer precisa de vir pré-carregado com código malicioso: pode ser redirecionado em tempo de execução, por texto que lê.
Um agente sequestrado é um "delegado confuso"
O termo aplicável aqui é o problema do delegado confuso: "um programa de computador que é enganado por outro programa (com menos privilégios ou menos direitos) para fazer mau uso da sua autoridade". Dê a um agente ferramentas reais, deixe-o depois ler conteúdo que não verificou, e ele pode ser instruído por esse conteúdo. É exatamente o padrão que a entrada sobre injeção de comandos da OWASP descreve, e já foi demonstrado, não apenas teorizado: o relatório de 26 de maio de 2025 da Invariant Labs mostrou um agente de programação, ao ler um problema (issue) de aparência normal num repositório público do GitHub, a seguir instruções ocultas nele para expor dados de um repositório privado, usando ferramentas que lhe tinham sido legitimamente concedidas. A própria conclusão dos investigadores: "isto não é uma falha no código do servidor MCP do GitHub em si, mas antes uma questão arquitetural fundamental que tem de ser resolvida ao 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 verdadeiro ponto cego: não uma lacuna num produto específico, mas o facto de a entrada de registo para "o agente fez o seu trabalho normal" e para "o agente foi sequestrado para fazer mau uso do seu trabalho normal" poderem ser idênticas ao nível do processo. Nada mudou no binário. Nada no padrão de chamadas de sistema é novo. Só a intenção por trás do pedido mudou, e a intenção não é um campo num registo de processos.
O que realmente reduz isto, e o que não reduz
Vale a pena ser preciso sobre o que a pessoa que nomeou este padrão realmente recomenda. Simon Willison, que descreveu a "trifecta letal" do acesso a dados privados, da exposição a conteúdo não fiável e da comunicação externa reunidas num único agente, é explícito quanto a evitar essa combinação ser a verdadeira correção, e não uma proteção adicional: "a única forma de estar seguro aí é evitar essa combinação letal por completo." Mostra-se abertamente cético quanto a produtos que afirmam detetar de forma fiável instruções injetadas depois do facto, notando que "ainda não sabemos como impedir isto de acontecer com 100 por cento de fiabilidade" e que uma taxa de deteção de 95 por cento "é uma nota claramente reprovada" para um controlo de segurança.
- Pense primeiro no desenho: dê a um agente as ferramentas e o acesso a dados mais estreitos de que a sua tarefa precisa, para que haja menos coisa para uma injeção bem-sucedida explorar (a correção arquitetural que tanto Willison como a Invariant Labs apontam).
- Trate qualquer conteúdo que o agente leia e que não tenha escrito ou verificado, sejam problemas (issues), páginas obtidas ou ficheiros transferidos, como entrada não fiável, por princípio, sempre.
- Onde o desenho e a revisão não bastam, o único passo que uma tentativa de exfiltração de dados não pode saltar é uma ligação de rede para o exterior. Vigiar 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.
O papel do FireAI e da HisnLabs
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: uma firewall com IA que corre diretamente no seu Mac. Mostra, em linguagem clara, cada ligação que as suas aplicações fazem e deixa-o decidir o que sai do seu Mac — a IA funciona localmente, pelo que o seu tráfego nunca é enviado para nós nem para mais ninguém. A equipa de investigação em segurança da HisnLabs é quem mantém essas decisões fiáveis: cataloga que domínios são simples telemetria e quais são um serviço real, acompanha o país e a rede por detrás de uma ligação e treina o modelo local (a funcionalidade Autopilot) com padrões de tráfego reais, sem que nada disso saia do seu Mac.
Pode ler as decisões técnicas por detrás dele, ou experimentar o FireAI durante 17 dias, em FireAI, da HisnLabs.