Captura Semântica do Agente: Quando o Invasor Fala a Língua que o Sistema Obedece

I. O Agente Não Sabe Quem Está Falando

Um agente autônomo com acesso a ferramentas — navegador, terminal, base de conhecimento, API de terceiros — processa, em cada tarefa, uma mistura de instrução do operador e conteúdo externo que ele apenas deveria ler. A pesquisa em segurança agêntica mostra que essa distinção, evidente para um humano, não é garantida internamente ao modelo: se o conteúdo externo contiver uma instrução redigida em linguagem natural, o agente tende a segui-la com a mesma autoridade que seguiria o operador legítimo.

Sugerimos nomear esse mecanismo Captura Semântica do Agente: o atacante não precisa comprometer credencial, explorar vulnerabilidade de código ou romper controle de rede — precisa apenas colocar uma instrução no caminho de leitura do agente, na língua que o sistema já está programado para obedecer. A taxonomia OWASP classifica esse vetor como ASI01 (Sequestro de Objetivo do Agente) quando o objetivo original é substituído, e ASI02 (Uso Indevido de Ferramenta) quando o agente é induzido a usar uma capacidade legítima para um fim malicioso — as duas faces do mesmo mecanismo central.

O critério prático mais citado para conter esse risco vem, de forma pouco usual, de dentro da própria indústria: a Rule of Two, formulada pela Meta, estabelece que um agente não deve satisfazer simultaneamente mais de duas das três condições seguintes — processar entrada não confiável, ter acesso a dado privado sensível, e poder mudar de estado ou se comunicar externamente sem supervisão humana. Quando as três condições coexistem, a captura deixa de ser hipótese e passa a ser questão de tempo.

A Taxa de Base, em Benchmark Público: O InjecAgent (Findings of ACL 2024) testou 1.054 casos de ataque, cobrindo 17 ferramentas de usuário e 62 ferramentas de possível atacante distribuídas entre 30 agentes: o agente ReAct baseado em GPT-4 mostrou-se vulnerável à injeção indireta em 24% das tentativas. A OWASP LLM Top 10 2025 classifica Prompt Injection como LLM01 — o primeiro item da lista — e Agência Excessiva como LLM06, reconhecendo formalmente as duas dimensões do problema.

[Ponto de Inflexão Fiduciária]: Algum agente autônomo da nossa organização hoje satisfaz, simultaneamente, as três condições da Rule of Two — entrada não confiável, dado sensível e ação sem supervisão — sem que isso tenha sido formalmente identificado como risco?

II. Dois Casos Reais, em Dois Anos Diferentes

O primeiro caso público relevante de exfiltração por injeção indireta em produto corporativo de IA envolveu o Slack AI. Em 20 de agosto de 2024, a Prompt Armor demonstrou publicamente como uma instrução maliciosa, plantada dentro de uma mensagem em um canal público que o assistente processava como contexto, conseguia induzir o sistema a gerar um link malicioso que, uma vez clicado pela vítima, vazava informação de canais privados para o atacante — sem que nenhuma credencial tivesse sido comprometida.

Pouco mais de um ano depois, o mesmo mecanismo apareceu em uma ferramenta de desenvolvimento agêntico. Em novembro de 2025, a empresa de segurança Prompt Armor documentou exfiltração de credenciais e código-fonte no Google Antigravity através de injeção indireta em um subagente de navegação: o subagente, ao processar uma página web durante uma tarefa legítima, seguia uma instrução oculta que o levava a contornar a proteção do .gitignore do repositório — usando o comando cat para ler arquivos que deveriam estar excluídos — e a enviar o conteúdo para um domínio externo já presente em uma lista de permissão do próprio sistema.

A discussão pública que se seguiu ao caso Antigravity, registrada em um tópico do Hacker News com mais de 700 pontos e mais de 200 comentários, trouxe uma observação de um usuário identificado como simonw, desenvolvedor com histórico relevante na área: o problema descrito “não é exclusivo de uma ferramenta específica — é um problema na maior parte da safra atual de agentes de codificação”. A boa prática sugere tratar esse comentário não como opinião isolada, mas como leitura consistente com a taxa de base de 24% medida pelo InjecAgent mais de um ano antes: o mecanismo é estrutural, o produto específico é apenas onde ele aparece primeiro.

[Ponto de Inflexão Fiduciária]: Entre o caso Slack AI (2024) e o caso Google Antigravity (2025), o que mudou na forma como avaliamos a segurança de um agente antes de ampliar o escopo de ferramentas a que ele tem acesso?

III. O Subagente Que Confiava Demais na Página Que Estava Lendo

Esse cenário, embora hipotético, reproduz a estrutura exata do caso Google Antigravity documentado na Seção II: a falha não está em uma credencial roubada, mas em uma cadeia de confiança implícita entre agente principal e subagente, e entre subagente e conteúdo externo. Importante que Comitês de Risco compreendam que a superfície de ataque, neste mecanismo, não é o agente isolado — é toda a cadeia de delegação entre agentes.

Vale considerar que a exfiltração, no caso real documentado, ocorreu através de um domínio que já constava em uma lista de permissão do próprio sistema — evidência de que listas de permissão configuradas para conveniência operacional podem, sem intenção, ampliar a superfície de exfiltração em vez de reduzi-la.

A discussão pública que acompanhou o caso trouxe ainda uma segunda observação relevante para Comitês de Risco: o pesquisador que originalmente relatou a falha ao Google já havia feito a divulgação responsável na semana anterior à repercussão pública, e a exfiltração por essa via específica constava, até então, como “problema conhecido” fora do escopo formal do programa de recompensa por vulnerabilidade da empresa — um lembrete de que nem toda exposição relevante está necessariamente coberta pelo processo padrão de bug bounty de um fornecedor.

[Ponto de Inflexão Fiduciária]: A nossa organização mapeou, para cada agente com subagentes ou ferramentas delegadas, a cadeia completa de confiança implícita entre eles — ou avalia apenas o agente principal isoladamente?

IV. A Contenção Nomeada: Rule of Two e Guarda-Corpos Semânticos

A resposta mais operacionalizável a esse mecanismo, hoje, não depende de tornar o modelo subjacente mais robusto — depende de desenhar a arquitetura ao redor dele para que a captura, quando ocorrer, não se converta em dano. A Rule of Two oferece um critério de decisão simples, aplicável no momento de configurar qualquer novo agente: se as três condições de risco coexistem, a resposta arquitetural não é confiar mais no modelo, é remover uma das três condições — tipicamente, inserir supervisão humana antes de qualquer ação irreversível.

Complementarmente, guarda-corpos semânticos — validação determinística e externa ao modelo, aplicada à saída do agente antes da execução — reduzem a chance de que uma instrução capturada se traduza em ação concreta, mesmo quando as três condições da Rule of Two não puderam ser totalmente evitadas por necessidade de negócio.

A boa prática recomenda tratar a lista de permissão de domínio de qualquer agente com acesso a navegação como ativo de segurança revisável, não como configuração estática definida uma única vez na implantação — o caso Google Antigravity mostra que um domínio incluído por conveniência operacional pode, meses depois, se tornar exatamente o canal de saída que o atacante precisava.

Um Convite à Reflexão do Conselho:

☐ A aplicação da Rule of Two como critério de avaliação obrigatório antes de conceder a qualquer agente acesso simultâneo a entrada não confiável, dado sensível e ação autônoma pode reduzir de forma mensurável a superfície de captura semântica.

☐ O mapeamento da cadeia completa de confiança entre agente principal e subagentes delegados, incluindo listas de permissão de domínio já configuradas, tende a revelar exposições que a avaliação isolada do agente principal não capturaria.

☐ A boa prática sugere considerar HITL (supervisão humana) como barreira obrigatória para qualquer ação irreversível originada de um subagente que processa conteúdo externo não totalmente controlado.

V. O Teste do Ácido

Se um subagente da nossa organização processasse amanhã uma página web comprometida contendo uma instrução oculta, a nossa arquitetura impediria a exfiltração antes que ela ocorresse — ou descobriríamos, como no caso Google Antigravity, que a permissão que tornou o vazamento possível já estava configurada por conveniência?

🏛️ Biblioteca: Metodologia Prática

Protocolo de Avaliação da Superfície de Injeção (PASI)

Este protocolo estabelece o roteiro mínimo para avaliar a exposição de um agente autônomo, e de seus subagentes, à Captura Semântica.

01. Checklist de Avaliação Rule of Two

Sugerimos que a equipe de segurança responda, para cada agente e subagente em produção, às três condições da Rule of Two:

1. Entrada Não Confiável: O agente processa conteúdo de origem externa não totalmente controlada (web, e-mail, documento de terceiro)?
2. Dado Sensível: O agente tem acesso a credencial, dado privado ou informação proprietária durante a execução?
3. Ação Autônoma: O agente pode mudar de estado ou se comunicar externamente sem confirmação humana prévia?

Importante que essa avaliação seja repetida a cada mudança relevante de escopo do agente — a adição de uma nova ferramenta, um novo domínio de navegação permitido, ou uma nova fonte de dado — e não apenas na implantação inicial, já que o caso Google Antigravity mostra que a exposição pode nascer meses depois da configuração original, sem qualquer alteração visível no comportamento cotidiano do agente.

02. Matriz de Risco por Combinação