Cada Passo Era Permitido. A Sequência Era o Ataque.

“Cada passo é permitido. A sequência é o ataque.” Ben Hirschberg, CTO e cofundador da ARMO, escreveu essa frase em setembro de 2026 para descrever a injeção de prompt via saída de ferramenta, e é a formulação mais compacta do problema que já li. Imagine o formato, exemplo meu e não dele: um agente lê um ticket do Jira cujo corpo manda buscar um arquivo, resumir e publicar o resumo em uma URL. Ler o Jira é permitido. Buscar o arquivo é permitido. Publicar em uma URL é permitido. Cada chamada passa na sua verificação. A cadeia exfiltra dados.

Já cobrimos por que modelos seguem instruções encontradas em conteúdo (papéis são estilo, não estrutura), como um pacote envenenado leva uma instrução para dentro do loop (a arma da cadeia de suprimentos) e como um plugin consegue forjar a etapa de consentimento (o caso do plugin da Vercel). Este ensaio dá o passo seguinte: por que os dois controles mais comuns deixam essa classe passar, e qual controle tem o formato certo.

Duas triagens, dois momentos

Dois pontos de verificação sustentam a maioria dos desenhos de segurança de agentes que já revisei.

O primeiro é a triagem de entrada. Antes de o conteúdo chegar ao modelo, um classificador ou um conjunto de regras procura padrões de injeção: “ignore as instruções anteriores”, payloads codificados, URLs suspeitas. Essa triagem trata o resultado da ferramenta como texto e pergunta se o texto parece hostil.

O segundo é a triagem de ação. Antes de o agente executar uma chamada de ferramenta, um motor de política pergunta se este agente pode chamar esta ferramenta com estes argumentos. Allowlists, escopos, aprovação humana para as perigosas. Essa triagem trata a chamada como um pedido e pergunta se o pedido está autorizado.

Cada ponto de verificação observa um momento do loop. A triagem de entrada vê o momento em que o conteúdo chega. A triagem de ação vê o momento em que uma chamada sai. O ataque vive no espaço entre os dois, no elo causal entre “este conteúdo chegou” e “esta chamada saiu”. Nenhuma das triagens tem esse elo no campo de visão.

Passe o exemplo do Jira pelas duas. O corpo do ticket parece uma descrição plausível de tarefa; um classificador ajustado para pegar “ignore as instruções anteriores” fica sem nada para pegar. As três chamadas seguintes estão todas dentro do conjunto de ferramentas autorizado para o agente. Triagem de entrada: verde. Triagem de ação: verde, verde, verde. Os dados foram embora.

O ponto cego vem da posição dos controles, e ajuste fino não muda essa posição. Dá para deixar o classificador de entrada mais rígido, e a conta vem em falsos positivos sobre tickets legítimos que contêm instruções, porque tickets são instruções. Dá para apertar a política de ação, e você remove capacidades de que o agente precisa para trabalhar. Nenhum dos ajustes dá ao controle uma visão da sequência.

Quem escreveu este campo

Antes de qualquer controle novo, Hirschberg faz um argumento sobre inventário que considero a metade mais útil do texto dele.

Times classificam confiança no nível da ferramenta. O Jira é um sistema interno, então a saída dele é confiável. O banco de dados é nosso, então as linhas são confiáveis. O compartilhamento de arquivos está atrás de SSO, então o conteúdo é confiável. É assim que listas de ferramentas ganham rótulo, e a unidade está errada.

A frase dele: “A saída de ferramenta falha nesse teste com muito mais frequência do que a lista de ferramentas sugere. A ferramenta é o Jira, e o campo é o corpo de um ticket que um cliente digitou.” A ferramenta é interna. O campo, não. O corpo de um ticket é texto livre escrito por quem abriu o ticket, o que em um fluxo de suporte significa um cliente, e em um projeto público significa qualquer pessoa com conta. O nível de confiança do campo é o nível de confiança de quem o escreveu, e o nível de confiança da ferramenta nada diz sobre isso.

O artefato que ele propõe é uma tabela de rerrotulagem com quatro colunas: sistema, campo, quem escreve, nível de confiança. Preencha para cada campo de texto livre que um agente lê; números, enums e identificadores estruturados ficam fora do escopo na versão dele. O exercício é mecânico e é revelador, porque a terceira coluna é onde a premissa quebra. Título do ticket no Jira: escrito por quem reportou. Corpo do ticket: escrito por quem reportou. Comentários: escritos por qualquer pessoa com permissão de comentar. Status: escrito pelo motor de workflow. De repente uma “ferramenta interna confiável” se decompõe em campos com quatro autores diferentes e pelo menos dois níveis de confiança.

Faça o mesmo com o CRM, o sistema de tickets, a wiki, o drive compartilhado, a caixa de e-mail, as tabelas do banco que recebem dados de formulários web. Qualquer campo que uma pessoa fora da fronteira de segurança consegue escrever é entrada não confiável para o agente, seja qual for o sistema que o armazena.

Essa tabela também é um inventário de proveniência de dados, um documento que a área de compliance vai pedir em algum momento com outro nome. Construa uma vez, use duas.

Precedente como sinal em tempo de execução

Agora o controle. O sinal que Hirschberg propõe é o que ele chama de lacuna de precedente: uma chamada de ferramenta, ou um argumento de uma chamada (um destino, um caminho, uma tabela), que este agente específico nunca usou antes. Julgado contra uma linha de base construída a partir do histórico de um único agente em um único cluster.

Veja o que isso observa e as duas triagens ignoram. A triagem de ação pergunta “esta chamada é permitida?”. A linha de base pergunta “este agente já fez esta chamada alguma vez?”. São perguntas diferentes com respostas diferentes. Um POST HTTP para uma URL externa pode ser permitido, porque o agente publica legitimamente em três webhooks internos. Um POST para uma quarta URL, que não aparece em nenhuma chamada anterior deste agente, é permitido e inédito ao mesmo tempo. A verificação de permissão passa. A verificação de precedente dispara.

O sinal tem o formato do ataque. Uma instrução injetada tipicamente leva o agente a um lugar onde ele normalmente não vai: um destino novo para exfiltração, um caminho novo para ler um segredo, uma tabela nova para uma escrita. O atacante escolhe o destino. O atacante não escolhe o histórico do agente. A linha de base é a única coisa no loop que o texto injetado não consegue reescrever. O próprio Hirschberg nomeia a exceção: um atacante que sabe que existe uma linha de base pode operar dentro dela, e ele chama isso de caso mais difícil.

A escolha do escopo importa, e Hirschberg é específico: um agente, um cluster, porque uma linha de base tão estreita não pode ser baixada, estudada offline ou ensaiada antes da tentativa. Minha leitura de por que isso também afia o sinal: uma linha de base construída sobre todos os agentes é permissiva demais, porque algum agente em algum lugar já chamou quase tudo. Uma linha de base construída sobre todos os clusters mistura comportamento de produção com o de staging. Quanto mais estreita a população, mais nítido o sinal.

Ele também propõe uma progressão de auditoria para enforcement, e essa é a parte a levar a sério para quem já tentou colocar um controle comportamental em produção. Em auditoria, os desvios são registrados contra a linha de base e nada é bloqueado; a regra dele é rodar em auditoria até a taxa de desvio se estabilizar, e então aplicar. O que eu acrescentaria: observe o que o agente faz que nunca fez antes, porque parte disso será crescimento legítimo, uma integração nova, o caminho de dados de um cliente novo, e esses casos precisam entrar na linha de base antes de o enforcement começar. Bloquear no primeiro dia contra uma linha de base não medida é como controles comportamentais acabam desligados.

A ressalva do fornecedor

A ARMO vende um produto nesse espaço, e o texto é conteúdo de fornecedor. Estou citando o enquadramento. Uma linha de base comportamental por agente é um controle que dá para construir com um pipeline de logs e uma consulta. O conceito se sustenta independentemente de quem o empacotou. Avalie qualquer produto pelas evidências dele.

Faça isso agora

Três passos, nesta ordem, nesta semana.

Construa a tabela de rerrotulagem. Para um agente em produção, liste cada campo de texto livre que ele lê. Quatro colunas: sistema, campo, quem escreve, nível de confiança. Rotule pelo autor. Qualquer campo que um cliente, um fornecedor, um usuário público ou um formulário sem autenticação consegue escrever é não confiável, e o agente precisa saber disso nas próprias instruções.

Puxe o histórico de chamadas do agente e procure as primeiras vezes. Pegue o último mês de chamadas de ferramenta de um agente. Para cada chamada, pergunte se a ferramenta e seus argumentos principais (destino, caminho, tabela) aparecem em algum ponto anterior do histórico desse agente. Cada primeira vez é uma mudança legítima que você consegue explicar ou um candidato a incidente. Se você não consegue produzir essa lista com o logging atual, esse é o primeiro achado.

Adicione precedente à dimensão de auditoria antes de adicioná-lo ao enforcement. Registre chamadas inéditas como uma classe distinta de evento. Revise até conseguir explicar cada uma. Depois decida o que vira alerta e, mais tarde, o que vira bloqueio.

As duas triagens que você já tem valem a pena manter. Elas pegam os ataques grosseiros. O que elas não conseguem ver é a forma desenhada por uma série de movimentos individualmente aceitáveis, e o histórico do próprio agente é a única referência contra a qual essa forma se destaca.

---

Fontes

• ARMO (Ben Hirschberg). “Prompt Injection Through Tool Output.” Setembro de 2026.

A Victorino ajuda times de engenharia a construir o inventário de proveniência e a linha de base por agente que transformam chamadas de ferramenta em uma sequência auditável: contato@victorino.com.br | www.victorino.com.br