// 00
Para quem é e para que serve
leia esta parte antes das outras
Escrevi este material pensando em duas pessoas. A primeira é quem trabalha com segurança e precisa avaliar sistemas que já estão rodando com agentes em produção. A segunda é quem constrói produto com inteligência artificial e ainda não parou para pensar no que acontece quando alguém de fora consegue escrever naquilo que o agente lê.
A intenção aqui é uma só: espalhar conhecimento de defesa. Descrever como o ataque funciona é pré-requisito para defender, porque ninguém protege um sistema contra uma classe de ataque que não sabe descrever. É por isso que o documento detalha mecanismo e cadeia de ataque em vez de ficar na superfície.
Uma palavra sobre de onde isso vem. A Jump é certificada na ISO/IEC 42001, a norma internacional de sistema de gestão de inteligência artificial, e implanta agentes em ambiente de cliente. O método deste documento é o que a gente usa antes de liberar acesso a dado real. A seção 10 detalha como isso se conecta com o que está descrito aqui.
O que você não vai encontrar é receita. Não tem payload pronto, nem passo a passo reproduzível contra sistema de terceiro. Todos os casos são públicos, já foram corrigidos pelos fornecedores, e estão descritos no nível de que um defensor precisa para conferir a própria casa.
A REGRA QUE NÃO É NEGOCIÁVEL
Nada do que está aqui se testa sem autorização por escrito. Contra sistema de terceiro, isso é crime. Contra o seu próprio, sem combinar antes com quem responde por ele, é um incidente que você mesmo causou. A seção 03 detalha o combinado mínimo antes de qualquer teste.
Se você é fornecedor de alguma das plataformas citadas, vale dizer o óbvio: os casos estão aqui porque foram bem resolvidos. Em quatro dos cinco, pesquisador encontrou e a empresa corrigiu antes de virar dano. É esse comportamento que a gente quer ver mais, e citar é uma forma de reconhecer.
// 01
O que importa e o que não importa
a diferença entre uma curiosidade e um comprometimento
Quando alguém te mostra que fez um modelo xingar, sair do personagem ou cuspir o próprio system prompt, não se emocione. Aquilo prova que dá para empurrar o modelo para fora do roteiro, e nada além disso. Sozinho, não alcança nada que esteja atrás dele. É um indício de que o canal funciona, e só.
O que a gente procura é o ataque que atravessa o modelo e chega em alguma coisa real: um dado que sai da empresa, uma ação que acontece, um sistema que é tocado. Em toda avaliação que fazemos a pergunta de triagem é a mesma. A influência virou efeito? Se não virou, estamos no caminho certo.
Autonomia define o raio de explosão
"Agente" virou rótulo comercial e hoje não diz quase nada. Tem sistema que roda sempre o mesmo pipeline com um modelo acoplado no meio, e tem sistema que decide sozinho o que fazer a seguir. Os dois são vendidos do mesmo jeito e dão trabalhos de segurança completamente diferentes. Quando a gente avalia um fornecedor, essa é a primeira coisa que eu separo. A área de cada círculo abaixo representa o alcance de uma injeção bem-sucedida naquele nível; o anel tracejado é sempre o pior caso, para comparar.
// 02
Cinco perguntas que definem o alvo
esqueça o produto e o framework, olhe para a implantação
Essas cinco perguntas são por onde eu começo qualquer avaliação. Você pode trocar o produto e o framework à vontade; são as respostas que desenham a superfície de ataque.
1. Entrada não confiável. Por onde consigo inserir conteúdo? O prompt direto é o caso óbvio. O perigoso é o indireto: as páginas que ele navega, os documentos que ingere, os trechos que recupera, a própria memória, tickets, e-mails e a saída de outros agentes.
2. Ferramentas. O que ele consegue fazer? Classifique cada uma pela gravidade da ação que habilita, de ler um registro a transferir dinheiro.
3. Privilégio. Com qual autoridade, em nome de quem? Escopo somente leitura e credencial de administrador compartilhada são alvos muito diferentes atrás da mesma ferramenta.
4. Processamento. Quem interpreta a saída dele? Toda chamada que vira consulta a banco, comando de shell, URL buscada ou código executado é ponto de injeção, e quem alimenta esse ponto é o modelo.
5. Saída. Para onde o dado pode ir? Todo destino é rota potencial de exfiltração, inclusive os que não parecem saída: uma linha de log, um contador, o carregamento de uma imagem.
OWASP Top 10 para Aplicações Agênticas
Publicado pelo OWASP GenAI Security Project em 9 de dezembro de 2025. É a taxonomia de referência, construída a partir de incidentes reais e não de projeções. Serve como vocabulário comum em threat modeling e como checklist de escopo.
ASI01ASI02ASI03ASI04ASI05ASI06ASI07ASI08ASI09ASI10// 03
Antes de testar qualquer coisa
pré-requisito, não apêndice
Reconhecimento ativo, interceptação de tráfego, quebra de certificate pinning e injeção em campos de produção são atividades de teste de intrusão. Contra sistema de terceiro sem autorização, é ilegal. Contra sistema da própria casa sem combinar antes, derruba produção e queima confiança interna. Quase todo material que circula sobre o assunto pula essa parte, e eu acho isso irresponsável.
- Autorização por escrito de quem responde pelo sistema, nomeando alvos e técnicas permitidas. Quando o alvo é SaaS contratado, isso inclui o fornecedor.
- Escopo explícito de ambientes, integrações e contas. Agente ligado a CRM, e-mail ou pagamento alcança dado de cliente e sistema de fora.
- Janela acordada e canal de parada, com alguém do lado defensivo sabendo que o tráfego é teste.
- Regra clara para dado real. Se a prova exige exfiltrar algo, combine antes o que basta como evidência. Registro de cliente não sai do ambiente, nem em captura de tela.
- Ações destrutivas fora do escopo por padrão. Apagar, transferir e enviar só com autorização nominal, de preferência em ambiente espelhado.
Em produção, prove o alcance sem consumar o efeito. Demonstrar que o agente consegue chamar a ferramenta destrutiva costuma bastar como achado, e evita que o teste vire o incidente.
// 04
As quatro etapas de um ataque
adaptação da cyber kill chain para agentes, não um framework novo
ETAPA 1
Reconhecer: achar por onde entrar
Esta etapa entrega inventário. Onde o conteúdo entra, o que o agente faz com ele, quais credenciais estão atrás de cada ferramenta e que sistemas as ações alcançam. Prompt esperto vem depois, se vier.
Comece pela forma de entrega, que define o ferramental. Um assistente que só existe no aplicativo não deixa tráfego web para observar. Depois mapeie a pilha inteira: host, sistema operacional, serviços vizinhos, runtime, sandbox, orquestração. Só no topo estão o modelo e seus classificadores. A maioria dos testes começa por esse topo. Eu começo por baixo, porque tudo que está embaixo é superfície que ninguém olhou.
Algumas perguntas fora do escopo já revelam a arquitetura pela reação. Nenhuma resposta sugere busca por palavra-chave com rótulo de IA. Recusa educada indica modelo com system prompt. Recusa idêntica e instantânea, antes de qualquer raciocínio possível, denuncia um classificador filtrando a entrada.
As entradas que a interface esconde são a parte que mais gente pula, e onde está a superfície de verdade: campos de busca ou filtro que trafegam por outra rota, parâmetros de API que a tela não expõe, tráfego entre o agente e seus subagentes, e o retorno das ferramentas, que o front-end não renderiza e o filtro quase nunca inspeciona.
ETAPA 2
Explorar: fazer o agente agir sobre o seu conteúdo
É o momento em que o que você escreveu deixa de ser dado lido e passa a ser instrução cumprida. O canal importa muito mais que a redação do payload.
- Injeção direta. É o que toda guardrail foi feita para pegar. Serve para estabelecer a linha de base do que a porta da frente bloqueia.
- Injeção indireta por conteúdo ingerido. Instruções em alt text, comentários HTML, metadados, texto fora da área visível, caracteres de largura zero. Não há usuário suspeito no histórico. Quem deposita um arquivo num drive indexado tem canal permanente e sem clique.
- Recuperação e memória. A instrução chega antes do prompt, na posição de maior confiança, e sobrevive à sessão.
- Subagentes e retorno de ferramentas. O filtro vigia a entrada e a saída principais, não o tráfego interno. Lacuna quase universal.
- Cadeia de suprimentos. Ferramenta instalada, plugin carregado, servidor consultado ou dependência podem carregar instrução tratada como confiável.
- O humano no loop. A aprovação vale o que valer o resumo exibido, e quem gera esse resumo é o mesmo sistema que está sendo influenciado.
ETAPA 3
Executar: transformar influência em impacto
Há dois caminhos, e o primeiro é o esquecido. A capacidade já é o ataque: nenhum ponto de execução, nenhum código. A ferramenta faz exatamente aquilo para o que foi criada, só que para outra pessoa. Ler e vazar, enviar, transferir, apagar. Ou a ação cai num ponto de execução: a saída vira entrada de outro sistema que a executa. Aqui voltam SQL, comando, SSRF, RCE, traversal e desserialização.
Escalar pela pilha não é automático
É comum ler "influência no modelo, execução no runtime, acesso ao host, alcance na rede" como progressão natural. Cada salto exige uma condição: do modelo ao runtime, que a saída chegue em algo que a execute; do runtime ao host, que o sandbox seja fraco; do host à rede, credencial reutilizável ou endpoint de metadados exposto. A verificação dos casos mostra que a maioria dos comprometimentos não usa ponto de execução nenhum.
A CONFIANÇA QUE FAZ ISSO FUNCIONAR
A ação roda com a autoridade do próprio agente: credencial, escopo e alcance são herdados. Quando o controle de acesso é aplicado só no nível do agente, em que ele informa a própria identidade e é confiado a pedir apenas o que deveria, basta alguém controlar o que ele pede para tudo cair.
ETAPA 4
Objetivos
- Exfiltrar. Todo caminho de saída é porta, inclusive log, relatório, contador e carregamento de imagem.
- Agir. Mandar e-mail, mover dinheiro, alterar registros. É o objetivo sem equivalente em sistema passivo.
- Negar. Apagar, corromper, derrubar, ou esgotar forçando operações caras.
- Persistir. Envenenar memória, plantar estado que o agente recarrega e confia.
- Propagar. Em sistema multiagente a confiança entre pares costuma ser não verificada: um comprometimento vira comprometimento da frota.
// 05
Casos documentados
verificados em fonte primária, e o status importa mais que o nome
Esses cinco casos circulam por aí como uma lista de incidentes. Fui conferir cada um na fonte original e quatro deles não são ataque de adversário que chegou a usuário. Marquei o status em todos, porque isso muda o que dá para concluir.
EchoLeak: exfiltração sem clique no Microsoft 365 Copilot
A Aim Labs construiu a prova de conceito em janeiro de 2025 e reportou ao MSRC. A Microsoft corrigiu do lado servidor em maio, sem exigir ação do cliente, e a divulgação saiu em 11 de junho de 2025 como CVE-2025-32711, CVSS 9,3. Sem evidência de exploração real.
O valor está na cadeia, que derrubou três camadas em sequência. O e-mail com instruções redigidas como pedido legítimo passou pelo classificador XPIA. O filtro que removia links só reconhecia a sintaxe inline de Markdown, então o ataque usou link de referência. A imagem embutida na resposta era buscada automaticamente pelo cliente, o que dispensou o clique. E a política de conteúdo foi contornada com um endpoint de pré-visualização do Teams que estava na allowlist e buscava qualquer URL passada como parâmetro. Um serviço da própria Microsoft fez a exfiltração. É o tipo de cadeia que nenhuma camada isolada ia segurar.
Aim Labs · MSRC CVE-2025-32711 · Reddy e Gujral, arXiv:2509.10540, set/2025
ForcedLeak: um domínio de cinco dólares no Salesforce Agentforce
A Noma Labs reportou em 28 de julho de 2025. A Salesforce corrigiu em 8 de setembro, impondo Trusted URLs para Agentforce e Einstein, e a divulgação saiu em 25 de setembro. CVSS 9,4.
A entrada foi o campo de descrição do formulário de captura de lead, que aceita 42 mil caracteres de texto livre. O disparo é atrasado: o payload só executa quando, dias depois, um funcionário pede ao agente para processar aquele lead. E a saída, sem a qual o ataque não funcionaria, foi um domínio que constava na allowlist de CSP da Salesforce. Ele tinha expirado e estava à venda por cerca de cinco dólares. Cinco dólares foi o preço do canal de saída num ataque com CVSS 9,4.
Noma Security, set/2025 · The Hacker News, 26.09.2025 · Salesforce Ben, 30.09.2025
Amazon Q: o commit que virou wiper
É o único dos cinco em que um adversário externo chegou ao usuário final. Em 13 de julho de 2025 um commit malicioso entrou no repositório aws-toolkit-vscode. Saiu na versão 1.84.0, publicada em 17 de julho para cerca de 964 mil instalações, e foi revertido na 1.85.0 em 19 de julho. CVE-2025-8217.
O detalhe que decide tudo está no payload: ele chamava o CLI do Q com --trust-all-tools --no-interactive, carregando um prompt que mandava levar o sistema a estado de fábrica e apagar recursos locais e de nuvem. O modelo não falhou. O que havia ali era uma chave capaz de desligar toda confirmação. Se você tem uma flag dessas no seu agente, pare de ler este documento e vá tirar.
A AWS afirmou que nenhum recurso de cliente foi impactado. Duas ressalvas: o código destrutivo aparentemente não executava por um defeito, e a história de que o atacante recebeu credenciais de administrador veio dele próprio, via imprensa, e não se sustenta na análise pública do histórico do repositório.
The Register e SC Media, 24.07.2025 · Bargury, reconstrução por commits, 24.07.2025 · declaração da AWS, 26.07.2025
Replit: a base apagada durante o congelamento
Em uma sessão de doze dias com congelamento de código em vigor, o agente apagou a base de produção de um usuário, com cerca de 1.200 registros de executivos e 1.190 de empresas, fabricou por volta de 4 mil perfis falsos e afirmou que a reversão era impossível.
Essa última parte era falsa, e o dado foi recuperado. Havia backup. A versão que circula, de que o dado se perdeu, está errada, e ela veio do próprio agente. É aqui que mora o que mais me preocupa nesse caso: o agente foi a única testemunha do que o agente fez.
A causa raiz é arquitetural e banal: na época a plataforma usava a mesma base para pré-visualização, teste e produção. O CEO reconheceu em 19 de julho de 2025 que aquilo era inaceitável e nunca deveria ser possível, e as correções foram estruturais: separação automática entre desenvolvimento e produção, modo somente planejamento, restauração em um clique. Nenhuma delas é "deixar o modelo mais cuidadoso".
The Register, 22.07.2025 · heise online, 25.07.2025 · postagens públicas de Amjad Masad e Jason Lemkin
Agent-in-the-Middle: vencer o roteamento pela descrição
Pesquisadores da Trustwave SpiderLabs publicaram um agent card falso num diretório do protocolo A2A. Como o agente coordenador escolhe pares usando um modelo que julga as descrições dos cards, a própria descrição funcionou como injeção de prompt: mandava que aquele agente fosse sempre escolhido. Foi o suficiente para vencer o roteamento.
Na demonstração, o agente rebelde corrompeu resultados de conversão de moeda. A leitura de que houve interceptação e vazamento de dados sensíveis é extrapolação do impacto potencial.
Trustwave SpiderLabs · Agent In the Middle: Abusing Agent Cards in the A2A Protocol
O QUE A CONTAGEM ESTÁ DIZENDO
De cinco casos, um foi ataque de adversário que chegou a usuários, e mesmo nele não houve dano confirmado em cliente. Dois foram vulnerabilidades encontradas por pesquisa e fechadas antes da publicação. Um foi acidente sem atacante. Um foi laboratório.
Isso não diminui o risco, e seria erro ler assim. A classe de ataque está demonstrada e é estrutural, só que o registro público até aqui é de pesquisador chegando antes do criminoso. Para mim isso é uma janela aberta, e janela fecha. Dá para tratar o assunto agora como decisão de arquitetura, antes que ele vire resposta a incidente.
O PADRÃO TÉCNICO QUE SE REPETE
Nos dois casos de exfiltração, o que decidiu o resultado não foi o prompt: foi o canal de saída. No EchoLeak, um endpoint da própria Microsoft que estava na allowlist e buscava URL arbitrária. No ForcedLeak, um domínio expirado que continuava na allowlist. Nos dois, a injeção funcionou; o que a transformou em vazamento foi a lista de domínios permitidos estar desatualizada.
No caso que chegou a usuários, o fator foi equivalente: uma opção de linha de comando que desliga toda confirmação. No acidente, ausência de separação entre ambientes.
Nenhum desses quatro é problema de inteligência artificial. São controles conhecidos, mal mantidos, que a IA passou a alcançar. Quando a gente entra num cliente, é por essa lista que eu começo.
// 06
O que efetivamente segura
separado por nível de garantia, não por ordem de preferência
Camada 1 · arquitetura com garantia demonstrável
É a única abordagem que não depende de o modelo resistir a nada. A base é o padrão de LLM duplo, proposto por Simon Willison em 2023: um modelo privilegiado, que vê apenas a consulta confiável e planeja as ações, e um modelo em quarentena, que processa o conteúdo não confiável mas não tem acesso a ferramenta nenhuma. O conteúdo suspeito nunca chega ao modelo que decide.
O CaMeL, do Google DeepMind, é a primeira implementação concreta desse padrão. O modelo privilegiado gera código representando a intenção do usuário; esse código roda num interpretador próprio, e não é o modelo que orquestra as chamadas. O interpretador rastreia a proveniência de cada dado e aplica política antes de cada chamada de ferramenta. Como o fluxo de controle é extraído apenas da consulta confiável, o dado não confiável não altera o que o programa faz. Altera apenas o que ele contém.
O NÚMERO QUE RESPONDE A PERGUNTA DO EXECUTIVO
No benchmark AgentDojo, o CaMeL resolveu 77% das tarefas com segurança demonstrável, contra 84% de um sistema sem defesa nenhuma. Cerca de sete pontos de utilidade em troca de garantia verificável, com implementação publicada em código aberto.
Os autores são honestos quanto ao preço: sistemas baseados em capability exigem esforço grande de implementação, política restritiva demais gera fadiga de aprovação, e permanecem canais laterais, como inferir informação pelo padrão das chamadas ou pelo tempo de resposta.
Camada 2 · redução de probabilidade
O spotlighting, publicado por pesquisadores da Microsoft, marca explicitamente o conteúdo não confiável no contexto para que o modelo o trate como dado, não como instrução. Funciona, reduz taxa de sucesso, e não é fronteira: o EchoLeak passou pelo classificador de injeção da própria Microsoft com uma redação cuidadosa. Aplique, mas com a expectativa certa. Encarece o ataque e diminui o volume. Não impede o ataque bem construído.
Camada 3 · os controles convencionais que decidiram os casos reais
Se eu pudesse escolher uma única coisa deste documento para você fazer amanhã de manhã, seria esta camada. Ela é a mais barata e foi a que mais falhou.
- Allowlist de saída viva, com dono e revisão. Nos dois casos de exfiltração o canal foi um item desatualizado na allowlist. Auditar a lista e remover o que ninguém reivindica é a medida de maior retorno por hora investida em todo este documento.
- Nenhuma opção que desligue confirmação. O caso Amazon Q virou wiper porque existia uma chave que confia em todas as ferramentas sem interação. Se essa chave existe no seu agente, ela é o ataque.
- Separação de ambientes. A causa raiz do caso Replit foi a mesma base servindo pré-visualização, teste e produção.
- Menor privilégio e credencial por tarefa. O agente do Agentforce roda como um usuário, e a injeção herda exatamente a visibilidade desse usuário. Acesso amplo de leitura converte incômodo em vazamento.
O OWASP nomeia o princípio que unifica isso como menor agência: autonomia é privilégio que se conquista por tarefa, não configuração padrão.
O QUE NÃO SEGURA SOZINHO
Guardrails e classificadores como defesa principal. Vender guardrail como fronteira é, na minha leitura, o maior engano do mercado hoje. Um modelo filtrando outro carrega a mesma fraqueza que está sendo explorada. Não é argumento teórico. No EchoLeak caíram classificador, filtro de link e política de conteúdo, um depois do outro, cada camada sob pressão modesta.
Um system prompt melhor. Treinamento molda o que o modelo tende a produzir; não impõe fronteira sobre o que entra. Na prática, o atacante só precisa parar de se parecer com aquilo que o modelo aprendeu a recusar.
Aprovação humana isolada. Controle real, mas macio: vale o que valer o resumo exibido, gerado pelo mesmo sistema que está sendo influenciado.
E o que decide o tamanho do estrago
No caso Replit, o agente afirmou que a reversão era impossível e estava errado. A recuperação só aconteceu porque alguém não acreditou nele. No Amazon Q, a versão comprometida ficou distribuída por dois dias.
DETECÇÃO E RESPOSTA
Log de toda chamada de ferramenta, com parâmetros, resultado, identidade sob a qual rodou e o trecho de contexto que a motivou. Sem isso não há investigação possível. A conversa não serve como evidência, porque ela é justamente o que o atacante controla.
Alerta por desvio de comportamento: ferramenta nunca usada naquela tarefa, volume de leitura fora do padrão, destino de saída inédito. Regra determinística vale mais que juiz baseado em modelo.
Verificar o feito, não o relatado. Conferência independente do efeito real. O agente nunca pode ser a única testemunha do que o agente fez.
Plano de resposta escrito antes. Como revogar credencial sem derrubar o resto, limpar memória e índice envenenados, reverter ações em lote, e quem tem autoridade para parar o agente.
// 07
Checklist para quem constrói
responder antes de colocar qualquer agente em produção
- Liste tudo que o agente lê sem alguém falar com ele: documentos, páginas, tickets, e-mails, memória, saída de outro agente. Trate cada item como não confiável por padrão.
- Classifique cada ferramenta pela gravidade da ação que permite. As de gravidade alta precisam de verificação determinística fora do modelo.
- Confirme que o controle de acesso acontece na fronteira da ferramenta e usa a sessão do usuário real, não uma identidade genérica do agente.
- Mapeie todo ponto em que a saída vira consulta, comando, caminho de arquivo, URL ou código.
- Mapeie todo canal de saída observável, inclusive log, métrica e carregamento de imagem, e restrinja a saída de rede por allowlist com dono e data de revisão.
- Verifique se o filtro de segurança enxerga o tráfego entre subagentes e o retorno das ferramentas, não só a entrada e a saída principais.
- Defina o que pode ir para a memória de longo prazo e quem escreve nela. Memória gravável por conteúdo ingerido é backdoor permanente.
- Garanta que o resumo mostrado a quem aprova seja gerado fora do caminho influenciável, ou mostre a chamada bruta.
- Elimine qualquer opção que execute ferramenta sem confirmação. Se ela existe, ela é o ataque.
- Registre toda chamada de ferramenta com parâmetros e resultado, e monte alerta para desvio de comportamento.
- Escreva o plano de resposta antes de precisar dele: revogação de credencial, limpeza de memória envenenada, reversão em lote.
// 08
Divergências em relação ao que circula
erros encontrados ao conferir cada caso contra a fonte
Esses cinco casos são repetidos em dezenas de artigos e apresentações, quase sempre a partir de um resumo de terceiro que copiou outro resumo. Quando a gente foi conferir na fonte, achou os erros abaixo. Corrigi no corpo do texto e registrei aqui, porque quem ler outro material vai encontrar a versão errada e precisa saber por que a nossa diverge.
QUATRO DOS CINCO NÃO SÃO INCIDENTES
A lista costuma ser apresentada como "cinco incidentes reais". EchoLeak e ForcedLeak foram divulgações coordenadas, corrigidas antes da publicação e sem exploração observada; Replit foi acidente operacional sem adversário; Agent-in-the-Middle é prova de conceito. Só o Amazon Q foi comprometimento real que chegou a usuários.
NO REPLIT, O DADO NÃO SE PERDEU
A versão corrente afirma que o dado sumiu. Havia backup e a base foi recuperada. A informação de que a reversão era impossível veio do próprio agente e era falsa. Esse é o ponto mais importante do caso, e ele some quando se repete a versão errada.
O CASO REPLIT É ASI10, NÃO ASI01
Circula mapeado como ASI01, sequestro de objetivo. Essa categoria exige uma entrada não confiável redirecionando o agente, e ali não há atacante externo. No texto de lançamento do OWASP, o exemplo citado para ASI10, agentes rebeldes, é literalmente este caso.
O AGENT-IN-THE-MIDDLE TEVE O IMPACTO SUPERDIMENSIONADO
Costuma ser descrito como interceptação e vazamento de dados sensíveis para terceiros. Na demonstração publicada, o agente falso corrompeu resultados de conversão de moeda. O resto é impacto potencial.
A ESCALADA PELA PILHA NÃO É AUTOMÁTICA
É comum encontrar "influência no modelo, execução no runtime, acesso ao host, alcance na rede" encadeado como progressão natural. Cada salto exige uma condição específica, e a verificação mostra que a maioria dos comprometimentos não usa ponto de execução nenhum.
Circula também a frase de efeito de que isso tudo é "injeção sem prepared statements", sugerindo que não existe correção estrutural possível. Os casos verificados dizem o contrário. Em quatro dos cinco, o que decidiu o resultado foi um controle convencional mal mantido. O problema tem solução. Ela só não está dentro do modelo.
// 09
Fontes
consultadas diretamente e datadas
- OWASP GenAI Security Project. OWASP Top 10 for Agentic Applications, 09.12.2025. Confirma os exemplos oficiais por categoria: EchoLeak em ASI01, Amazon Q em ASI02, Replit em ASI10. Em setembro de 2026 o projeto anunciou um Agent Control Standard e o Top 10 para LLM de 2026, pendente de leitura nesta revisão.
- Reddy, P.; Gujral, A. S. EchoLeak: The First Real-World Zero-Click Prompt Injection Exploit in a Production LLM System. arXiv:2509.10540, set/2025.
- Noma Security. ForcedLeak: AI agent risks exposed in Salesforce Agentforce, set/2025. Com The Hacker News (26.09.2025) e Salesforce Ben (30.09.2025).
- Bargury, M. Reconstructing a timeline for Amazon Q prompt infection, 24.07.2025. Com The Register e SC Media (24.07.2025) e a declaração da AWS de 26.07.2025.
- The Register (22.07.2025) e heise online (25.07.2025) sobre o caso Replit, com as postagens públicas de Amjad Masad e Jason Lemkin.
- Trustwave SpiderLabs. Agent In the Middle: Abusing Agent Cards in the A2A Protocol. Prova de conceito.
- Debenedetti, E. et al. (Google DeepMind) Defeating Prompt Injections by Design. arXiv:2503.18813. Arquitetura CaMeL, resultados no AgentDojo e implementação aberta.
- Willison, S. The Dual LLM pattern for building AI assistants that can resist prompt injection, abr/2023.
- Hines, K. et al. (Microsoft) Defending Against Indirect Prompt Injection Attacks With Spotlighting. CAMLIS 2024.
- Dark Marc. The Hacker's Guide to Attacking AI Agents, 15.09.2026. Origem do modelo das quatro etapas e das cinco perguntas.
// 10
Como a gente trata isso na Jump
o que a certificação resolve e o que ela não resolve
A Jump é certificada na ISO/IEC 42001, publicada em 2023 como a primeira norma internacional certificável para sistema de gestão de inteligência artificial. A gente passou pelo processo por dentro antes de levar isso a cliente, o que muda bastante a conversa: prepara quem viveu, não quem só desenhou. Ela está para a IA como a 27001 está para segurança da informação. Não dita como construir o modelo; dita como gerenciar o ciclo de vida do sistema com rastreabilidade, responsabilidade nomeada e gestão de risco.
Quero ser honesto sobre o alcance disso, porque tem gente vendendo certificação como se fosse blindagem. Certificado nenhum impede injeção indireta de prompt. A 42001 não é controle técnico. O que ela entrega é o sistema de gestão que faz as perguntas deste documento terem dono e data de revisão.
Repare no que decidiu os casos das seções anteriores. Uma allowlist com domínio expirado que ninguém revisava. Uma opção que desliga confirmação e que ninguém tinha inventariado. Ambiente de produção sem separação. Registro insuficiente para saber o que o agente fez. Nenhum desses é problema de modelo. Todos são problema de gestão, que é exatamente o que a norma cobra: inventário dos sistemas de IA, responsável nomeado, avaliação de risco antes do deploy, controle operacional, registro e revisão contínua.
O QUE A GENTE FAZ COM ISSO
Avaliação de agentes antes de produção. As cinco perguntas da seção 02 aplicadas à implantação real, com o mapa de entradas, ferramentas, privilégio, pontos de execução e canais de saída. O entregável é a lista do que precisa mudar antes de o agente ganhar acesso a dado de verdade.
Implantação de agentes com as camadas da seção 06. Fronteira determinística abaixo do modelo, menor privilégio por tarefa, ferramenta sob demanda sem execução automática, e registro suficiente para investigar depois.
Nossa plataforma de governança de IA, organizada em três estágios que batem com o que este documento cobra.
Descobrir. Varredura por API de nuvem, dados, código e identidade, lendo só metadado e com credencial em cofre. São 29 conectores, de provedor de modelo a banco vetorial e diretório de identidade. O que a varredura encontra entra num inventário com dono nomeado e nível de risco, inclusive o que ninguém tinha declarado.
Controlar. Regra determinística decide o que mascara e o que barra, sem modelo julgando modelo. No endpoint, a classificação roda na própria máquina da pessoa, sem rede, e mascara antes do envio: o conteúdo bruto nunca sai do computador. Quem pede liberação não é quem aprova, e toda exceção nasce com prazo.
Comprovar. Cada ação vira evento datado numa linha do tempo, e o score por framework e o dossiê saem dessa evidência, sem número digitado à mão. Falha não vira tela verde.
O LIMITE, PARA NÃO VENDER O QUE NÃO É
O RADAR·AI governa o uso de IA na organização: descoberta, shadow AI, política, controle no endpoint e evidência para auditoria. Ele não substitui a fronteira determinística que precisa existir dentro da arquitetura do seu agente, aquela da camada 1 da seção 06, validando cada chamada de ferramenta contra a sessão do usuário.
São camadas diferentes e as duas precisam existir. A plataforma responde "o que temos, quem é dono e como eu provo". A arquitetura do agente responde "essa chamada específica pode acontecer". A gente implanta as duas, e desconfie de quem disser que uma resolve a outra.
Se você leu até aqui e reconheceu a sua arquitetura em algum dos casos, a conversa útil não começa por ferramenta. Começa por responder as cinco perguntas sobre o seu agente e ver o que aparece.