Quando o validador de IA não é controle: o que um estudo sobre pipelines multiagente mostra sobre segregação de funções

Em um experimento com quatro agentes, o agente encarregado de aprovar o trabalho dos outros foi enganado em 100% das tentativas de envenenamento de memória. A ação insegura só deixou de acontecer quando a autorização saiu do julgamento do modelo e virou regra externa, verificada fora dele.

Um agente de inteligência artificial que revisa o trabalho de outro agente funciona como controle?

A resposta curta, segundo um estudo publicado em 15 de setembro de 2026 no arXiv por Tanzim Hossain Safin, Sharif Noor Zisad, Swakkhar Shatabda e Ragib Hasan, é: não sozinho. No cenário testado, o agente validador continuou sendo enganado em todas as tentativas mesmo quando o sistema estava protegido — e o que impediu a ação indevida foi uma camada de autorização independente, fora do modelo. O trabalho, segundo informação registrada na própria página do arXiv, foi aceito no IEEE Cyber Awareness & Research Symposium (CARS) de 2026.

O recorte é relevante porque descreve um padrão que já está em produção em muitas empresas: montar um pipeline em que um agente executa e outro agente aprova.

O que foi testado

Os pesquisadores montaram um pipeline de quatro agentes no LangGraph — biblioteca usada para orquestrar fluxos de agentes de IA — com os papéis de Supervisor, Pesquisador, Validador e Executor. Contra esse pipeline, aplicaram dois ataques.

O primeiro é o envenenamento de memória compartilhada: o atacante contamina o espaço de memória que os agentes usam para trocar informação entre si. O segundo é uma injeção indireta de prompt, em que uma aprovação forjada vem embutida em um documento recuperado pelo agente — o texto malicioso não é digitado por ninguém, ele chega junto com o material que o agente foi buscar.

A comparação central do estudo é entre dois tipos de defesa. De um lado, o julgamento do Validador, isto é, um modelo de linguagem avaliando se aquilo deve ou não ser executado. De outro, uma camada de autorização independente, feita de tokens assinados vinculados à tarefa específica e de um oráculo de política — um verificador de regras rodando separado, fora do modelo, que decide se aquela ação é permitida.

Para medir o estrago, os autores propõem a métrica Judgment Bypass Rate (JBR), que mede o comprometimento no agente atacado — a proporção de tentativas inseguras em que a revisão do Validador foi burlada — e não apenas na ação final. Ela é lida em conjunto com a Unsafe Action Rate (UAR), a proporção de tarefas inseguras que chegam à execução.

O ambiente: 60 tarefas rotuladas (36 seguras e 24 inseguras) distribuídas em 13 tipos de ação, três sementes aleatórias, totalizando 180 tentativas por condição. O modelo usado foi o gemma4:31b-cloud via Ollama, com temperatura zero.

O resultado que muda a conversa

Sem a camada de autorização, o envenenamento de memória chegou à execução em todas as tentativas: 100% de UAR e 100% de JBR, segundo a Tabela I do estudo.

Com a camada de autorização ativada, o JBR permaneceu em 100% e a UAR caiu para 0%.

Ou seja: o Validador continuou comprometido exatamente na mesma proporção. Ele seguiu aprovando o que não deveria. O que mudou foi que a aprovação dele deixou de ser suficiente para mover a ação adiante. Nas palavras dos autores, a autorização estrutural consegue conter o comportamento de um agente comprometido mesmo quando o julgamento do modelo a montante falha.

A ablação por componente refina o ponto. Segundo o estudo, a condição só com token assinado ficou indistinguível da condição sem defesa nenhuma, enquanto a condição só com o oráculo de política reproduziu o resultado do sistema completo. Contra um atacante que possui o segredo de assinatura, a contenção vem do oráculo de política, não da verificação de assinatura — porque, como os próprios autores resumem, uma assinatura autoriza procedência, não permissão. Vale a ressalva: essa ablação foi rodada com uma única semente, segundo as limitações declaradas no paper.

Traduzindo para o vocabulário que já existe no processo

Nada disso é novo para quem trabalha com controle interno. É o mesmo problema, com outro nome.

Segregação de funções. Quem executa não aprova. Deixar o agente revisor decidir sozinho se a ação segue é o equivalente digital de permitir que a mesma pessoa que emite o pagamento também o aprove. Não é um controle mais fraco: é a ausência de um controle, porque as duas funções estão no mesmo lugar e caem juntas.

Alçada. O token vinculado à tarefa é uma ordem de serviço com escopo — vale para aquilo, não para qualquer coisa. Mas o resultado da ablação mostra que escopo sem regra externa não resolve: se o atacante consegue emitir tokens válidos, a assinatura só prova de onde veio, não o que pode ser feito. No vocabulário de processo, é a diferença entre reconhecer a firma e ter alçada para o valor.

Evidência. É onde entra a terceira camada testada no estudo, descrita adiante.

A distinção prática para quem desenha arquitetura de agentes é simples de enunciar e cara de ignorar: prompt não é controle, política verificada fora do modelo é.

O custo do controle aparece no outro ataque

O segundo ataque conta uma história diferente e útil para não exagerar a conclusão. No sequestro de agente por aprovação forjada, a UAR ficou em 0% e o JBR em 0% nas duas configurações — o ataque, nesse pipeline, não burlou o julgamento nem chegou à execução.

O problema ali foi o oposto: falso positivo. A taxa de falsos positivos ficou em 59,3% sem a camada de autorização e em 49,1% com ela, segundo a Tabela I. Em termos operacionais, isso significa um volume grande de conteúdo legítimo tratado como ataque — um controle que trava o trabalho honesto.

A resposta dos pesquisadores foi acrescentar uma camada Observer, de observação do fluxo. Com ela, a taxa de falsos positivos caiu de 49,1% para 7,4%, uma redução relativa de 85%, e o F1 subiu de 0,74 para 0,95, sem enfraquecer a segurança no nível da execução. Os próprios autores registram que essa taxa variou bastante entre as sementes testadas, com intervalo de 95% entre 28,1% e 70,0% — o que recomenda cautela ao tratar o 49,1% como número estável.

O trade-off, portanto, não está resolvido. Autorização rígida contém, mas reduz a autonomia que motiva usar agentes. Observação reduz o atrito, mas adiciona uma camada a mais para manter.

Os limites do que foi mostrado

O estudo não autoriza a conclusão de que toda arquitetura multiagente se comporta assim. Os autores listam as restrições: os resultados valem para uma arquitetura, um framework e um modelo, e o comportamento do Validador pode diferir entre modelos; foram 60 tarefas e 13 tipos de ação; a ablação de autorização usou uma única semente; a injeção testada é descrita como conspícua, potencialmente pouco representativa de um atacante adaptativo; e a política independente, ainda que escrita sem acesso aos rótulos, foi produzida pelo mesmo grupo de pesquisa.

Também não é um resultado sobre inviabilidade de agentes. É um resultado sobre onde colocar o controle.

O que isso muda para quem já tem agentes rodando

Para uma empresa cujos agentes apenas resumem texto ou redigem rascunhos, a discussão é teórica. Ela deixa de ser teórica no momento em que um agente ganha acesso a e-mail, ERP, CRM, sistema de pagamento ou execução de código — porque aí existe uma ação com consequência, e a pergunta "quem autoriza" passa a ter resposta contábil.

O que o estudo sugere é que essa resposta não deveria ser "o agente revisor". Deveria ser uma regra escrita fora do modelo, verificável de forma independente, com escopo por tarefa e registro do que foi permitido. É a mesma lógica que já rege alçada de compras e aprovação de pagamento — aplicada a um executor que trabalha rápido demais para ser conferido caso a caso.

---

Box — Quatro perguntas para quem já tem agentes em produção

1. Alguma ação com consequência real depende só do julgamento de um agente revisor para acontecer?

2. Existe uma regra de permissão escrita fora do modelo — em código, política ou serviço separado — que possa recusar a ação mesmo com o revisor aprovando?

3. O escopo da autorização é por tarefa, ou o agente carrega uma credencial ampla que serve para qualquer coisa?

4. Fica registro do que foi autorizado, por qual regra e com base em qual evidência — suficiente para reconstruir a decisão depois?

---