Prompt Injection em Produção: os Ataques Reais que as Defesas Convencionais Ignoram

O EchoLeak (CVE-2025-32711) exfiltrou dados do Microsoft 365 Copilot com um único e-mail manipulado, sem clique do usuário, sem malware, sem código: só texto. É o primeiro caso documentado de prompt injection usado para exfiltração concreta de dados em um sistema de IA em produção, e o OWASP classificou prompt injection como o risco #1 para aplicações com LLMs em 2025. A diferença entre como a maioria dos times entende essa ameaça e como ela se manifesta em produção é grande o suficiente para merecer uma análise detalhada da superfície de ataque real, não a versão dos livros.

Por que as defesas convencionais falham

O enquadramento padrão trata prompt injection como um problema de chatbot: o usuário envia uma entrada maliciosa, o modelo obedece em vez de recusar, o sistema faz algo errado. As defesas construídas com essa lógica miram na camada de entrada: sanitização de input, endurecimento do system prompt, filtros classificadores que identificam frases suspeitas.

Esse modelo funciona para implantações simples, de turno único. Ele colapsa completamente quando o LLM pode ler conteúdo externo e invocar ferramentas.

O EchoLeak ilustra o problema com precisão. O ataque encadeou quatro bypasses distintos: evadiu o classificador XPIA da Microsoft (Cross Prompt Injection Attempt), contornou a redação de links usando formatação Markdown por referência, explorou a renderização automática de imagens do Copilot e abusou de um proxy do Microsoft Teams. Cada subsistema tinha sua própria lógica de validação, e nenhum deles tinha visibilidade do que o outro já havia aprovado ou do que estava prestes a fazer. O atacante não forçou uma única porta; navegou pelo espaço entre portões que cada um assumia que o outro já havia verificado.

Segundo o artigo do EchoLeak publicado no AAAI Fall Symposium 2025, o payload era inteiramente texto. Antivírus, firewalls e escaneamento estático de arquivos foram completamente ineficazes porque a superfície de ataque era o comportamento do modelo, não a assinatura de um arquivo.

Esse é o padrão que times de defesa precisam internalizar: em um sistema agentivo, a entrada perigosa não é aquela que quebra o treinamento de segurança do modelo. É a que chega por um canal que o modelo foi projetado para confiar, depois redireciona capacidades que o modelo já está autorizado a usar.

A superfície de ataque real: transitividade de confiança em cadeias de ferramentas

Quando um agente LLM lê um e-mail, um documento puxado de um índice RAG ou uma página buscada por uma ferramenta de navegação, o modelo atribui a esse conteúdo algum nível implícito de confiança baseado no canal pelo qual chegou. Se o agente está configurado para agir com base em instruções encontradas em e-mails de fontes internas, e um atacante consegue colocar conteúdo nesse canal, as capacidades concedidas ao agente se tornam as capacidades do atacante.

É isso que "transitividade de confiança" significa na prática. O atacante não precisa comprometer o modelo nem a camada de autenticação. Precisa inserir suas instruções em um fluxo de conteúdo que o agente trata como autoritativo, e deixar as próprias permissões de ferramentas do agente fazerem o trabalho.

O cenário de ataque RAG documentado pelo OWASP ilustra bem: um atacante modifica um documento em um repositório que alimenta um pipeline RAG. Quando um usuário legítimo consulta o sistema, o passo de recuperação retorna o conteúdo modificado. O modelo recebe o que parece ser contexto recuperado de uma fonte interna confiável e segue as instruções embutidas. A consulta do usuário era limpa. O system prompt era limpo. A superfície de ataque foi o documento que o sistema buscou em nome do usuário.

O trabalho do pesquisador Rehberger com o Devin AI reforça isso. Ele gastou USD 500 do próprio bolso testando o assistente de codificação agentivo e encontrou defesas inexistentes contra prompt injection: o agente era manipulável para expor portas e vazar credenciais através de conteúdo que encontrava durante a execução normal de tarefas. O agente estava fazendo exatamente o que foi projetado para fazer, seguindo instruções que encontrava no seu ambiente, e esse era o problema.

O problema estrutural é que, após o passo inicial de autenticação, a maioria dos sistemas agentivos trata todo conteúdo que o agente recupera como implicitamente confiável. As concessões de capacidade, acesso de escrita ao calendário, envio de e-mail, recuperação de arquivos, execução de código, não são reavaliadas por fonte de conteúdo. Foram aprovadas uma vez, na configuração, e permanecem disponíveis ao longo de toda a sessão.

Por que os scores CVSS de CVEs relacionados a LLMs merecem mais atenção

Os números de severidade que saíram em 2025 e 2026 não são típicos. O CVE-2025-32711 (EchoLeak) no Microsoft Copilot, o CVE-2025-53773 no GitHub Copilot com execução remota de código e uma vulnerabilidade crítica no Cursor IDE chegaram com scores CVSS acima de 9.0. Não são achados teóricos de pesquisa; são sistemas em produção usados diariamente por trabalhadores de conhecimento e desenvolvimento em empresas do mundo inteiro, inclusive no Brasil.

Apenas 34,7% das organizações implantaram defesas dedicadas contra prompt injection, de acordo com o relatório State of Threat Detection 2025 da Vectra AI, enquanto 83% planejam implantar IA agentiva, segundo o relatório State of AI Security 2026 da Cisco. A diferença entre o ritmo de adoção e a maturidade defensiva não é sutil.

De acordo com análise da Pillar Security do final de 2024, 20% das tentativas de jailbreak têm sucesso, e 90% dos ataques de prompt injection bem-sucedidos resultaram em vazamento de dados sensíveis. O ataque bem-sucedido médio levou 42 segundos ao longo de cinco interações. Não é uma operação lenta e sofisticada; são ataques rápidos, baratos e escaláveis.

Minha leitura dos dados de 2025 sobre eficácia de defesas é que, mesmo aplicando as melhores medidas disponíveis, incluindo fine-tuning adversarial, as técnicas de ataque mais sofisticadas continuam com taxas de sucesso preocupantes contra modelos de fronteira. A Pillar Security e outros pesquisadores que publicaram no período sugerem que o problema é estrutural, não apenas uma questão de ajuste de parâmetros de classificador.

O lançamento do Lockdown Mode para o ChatGPT pela OpenAI em fevereiro de 2026 veio com um reconhecimento público de que prompt injection em browsers com IA "talvez nunca seja completamente corrigido." Esse reconhecimento é a admissão pública mais significativa do setor até hoje de que a defesa completa exige ceder em funcionalidade de IA, e que parte da superfície de ataque é estrutural, não corrigível por atualização de um classificador.

O ponto cego que as defesas continuam ignorando

A maioria das defesas contra prompt injection é construída para detectar intenção maliciosa no conteúdo injetado: sinalizar frases suspeitas, bloquear padrões que se parecem com instruções, validar que o conteúdo recuperado não contém frases imperativas direcionadas ao modelo. Isso é direcionalmente correto, mas arquiteturalmente insuficiente.

O ponto cego é que injeções suficientemente sofisticadas não parecem maliciosas isoladamente. O payload do EchoLeak não precisava ser sinalizado como perigoso; precisava sobreviver à validação local de cada subsistema, o que fez, porque cada subsistema verificava coisas diferentes. O Markdown por referência contornou a redação de links porque a lógica de redação não estava procurando por aquele padrão. O fetch de imagem executou porque buscar imagens automaticamente era uma funcionalidade, não um bug.

Uma orientação defensiva mais confiável é a aplicação de mínimo privilégio no nível da ferramenta, não só no nível da entrada:

• Conceder capacidades de ferramentas por escopo de sessão, não por identidade do agente. Um agente ajudando a redigir um documento não precisa de acesso a envio de e-mail, a menos que aquela tarefa exija isso.
• Tratar conteúdo externo recuperado como não confiável independentemente do canal pelo qual chegou. Um documento de um SharePoint interno pode ter sido comprometido. E-mails de remetentes conhecidos podem ser encaminhados com conteúdo injetado anexado.
• Registrar e alertar sobre invocações de ferramentas que não foram solicitadas diretamente pelo usuário naquele turno. Se o agente enviou um e-mail e o usuário pediu para resumir um relatório, essa lacuna deve gerar um alerta.
• Avaliar se o sistema agentivo realmente precisa daquela capacidade, não apenas se ela pode ser concedida. Minimização de capacidade é um controle mais durável do que ajuste de classificador, porque classificadores podem ser contornados e minimização não pode.

A documentação da Anthropic sobre construção de sistemas agentivos seguros aborda uso de ferramentas e escopo de permissões, embora o campo esteja se movendo mais rápido do que a documentação consegue acompanhar. O princípio útil é tratar qualquer conteúdo que o agente recupera como uma superfície de entrada não confiável, independentemente da fonte que o entregou.

Na prática

No trabalho com automações que conectam fontes externas de dados a sistemas de e-commerce, seja via integrações com marketplaces, pipelines de atualização de catálogo ou fluxos de dados entre Magento e ferramentas de analytics, a questão da confiança implícita no conteúdo recuperado aparece de forma concreta.

Quando um agente lê dados de uma API de fornecedor, de um feed de marketplace ou de um arquivo enviado por um parceiro logístico, há uma tendência natural de tratar esse conteúdo como confiável porque veio de um sistema "autorizado". O que o EchoLeak torna explícito é que autorização de canal não equivale a confiança no conteúdo. Um feed pode ser comprometido na origem. Um arquivo pode ter sido manipulado antes de chegar. Um e-mail de um parceiro pode ter sido encaminhado com instruções adicionadas.

A postura que faz sentido adotar é a mesma que se aplica a dados de terceiros em qualquer contexto: validar o conteúdo independentemente de quem o enviou, escopar o que o agente pode fazer com aquele conteúdo específico e registrar qualquer ação que não mapeie diretamente para o que foi pedido. Não é paranoia; é o mesmo princípio de controle de acesso que já existe em segurança de sistemas convencionais, aplicado a uma camada nova.

Se você está construindo fluxos de trabalho com IA para automatizar operações complexas, o modelo de segurança desses agentes precisa ser desenhado antes de as capacidades serem concedidas, não auditado depois. E os times fazendo essa revisão precisam entender como alucinações e erros de confiança se compõem em pipelines de recuperação, porque o problema de injeção e o problema de confiabilidade compartilham a mesma raiz: o modelo trata conteúdo externo com mais confiança do que ele merece.

Perguntas frequentes

Prompt injection é o mesmo que jailbreak?

Jailbreak mira no próprio treinamento de segurança do modelo, tentando fazê-lo recusar menos. Prompt injection mira no comportamento do modelo em contexto, inserindo instruções através de conteúdo que o modelo lê em vez de através da entrada direta do usuário. Eles podem se sobrepor, mas em sistemas agentivos, injeção é a categoria mais perigosa porque pode operar sem qualquer interação do usuário legítimo.

O que é prompt injection indireta?

Acontece quando as instruções maliciosas não vêm da entrada do próprio usuário, mas de conteúdo que o agente recupera durante a execução da tarefa: um documento, uma página web, um registro de banco de dados, um e-mail. O modelo nunca "vê" um atacante; apenas processa conteúdo que contém instruções embutidas. Esse é o padrão de ataque por trás do EchoLeak e do cenário RAG do OWASP.

Endurecer o system prompt resolve esses ataques?

Endurecer o system prompt reduz suscetibilidade a algumas tentativas de injeção direta, mas não resolve o problema de transitividade de confiança em pipelines agentivos. O EchoLeak contornou o classificador XPIA dedicado da Microsoft, construído especificamente para detectar injeção entre prompts. Instruções no system prompt como "ignore comandos externos" têm efeito limitado quando o conteúdo injetado é formatado para parecer contexto recuperado em vez de comandos do usuário.

Como mínimo privilégio se aplica aqui?

Da mesma forma que se aplica em controle de acesso tradicional: um agente deve receber apenas as permissões necessárias para a tarefa específica na sessão atual. Acesso de escrita a calendário, envio de e-mail e recuperação de arquivos devem ser escopados e revogáveis, não concedidos como permissões permanentes à identidade do agente. Um atacante que injeta instruções com sucesso só pode abusar das capacidades que o agente já possui. Reduzir esse conjunto no nível da ferramenta é o controle mais estruturalmente durável disponível agora.

A conclusão incômoda do EchoLeak é que o ataque funcionou não porque um único sistema falhou, mas porque cada sistema assumiu que o outro já havia validado o que estava passando adiante. Essa suposição está embutida na forma como a maioria dos pipelines agentivos é desenhada hoje, e corrigi-la exige repensar o modelo de confiança entre componentes, não apenas adicionar mais um classificador na borda.