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

🛡️ Framework de Integridade Analítica (Metodologia)

Padrões e Dados Verificados: Toda alegação quantitativa deste artigo deriva de fonte nominal e verificável — benchmark InjecAgent (Findings of ACL 2024), OWASP LLM Top 10 2025 (LLM01, LLM06), caso Slack AI documentado por Johann Rehberger (embracethered.com, 20 ago. 2024), caso Google Antigravity documentado por Prompt Armor e discutido em Hacker News (item 46048996), e a Rule of Two conforme formulada pela Meta.

⚖️ Isenção e Termos de Responsabilidade Fiduciária (Disclaimer)

Este material utiliza abordagem técnica e analítica inteiramente concebida para fortalecer a macroestratégia fiduciária no cerne de Conselhos de Administração. O conteúdo estrutural não constitui, sob nenhuma premissa, emissão de parecer de arquitetura de software, auditoria cibernética ou consultoria jurídica especializada para infraestrutura de TI. A FIDUCIA ADVISORY e o seu idealizador tático principal, Walter Maier Neto, declinam absolutamente de responder patrimonialmente ou civilmente por incidentes de segurança, recusas securitárias ou perdas financeiras originadas na adoção operacional destas diretrizes arquiteturais. A obrigação material e a homologação da governança tecnológica restam consolidadas na função de diligência exclusiva da liderança empossada legalmente.

📚 Referências Bibliográficas

• Zhan, Q. et al. “InjecAgent: Benchmarking Indirect Prompt Injections in Tool-Integrated Large Language Model Agents.” Findings of the Association for Computational Linguistics (ACL), 2024.

• OWASP. “OWASP Top 10 for LLM Applications 2025” — LLM01 (Prompt Injection), LLM06 (Excessive Agency).

• Rehberger, J. “AI Injections: Direct and Indirect Prompt Injection Basics” e cobertura do incidente Slack AI. embracethered.com, 20 ago. 2024.

• Prompt Armor. Documentação de exfiltração via injeção indireta no Google Antigravity. 2025.

• Discussão pública, Hacker News, item 46048996 (768 pontos, 215 comentários) — inclui referência à Rule of Two (Meta).