Injeção de prompt tem sido a vulnerabilidade número um da OWASP para aplicações LLM desde que começaram a rastrear. Toda grande plataforma de IA publicou orientações sobre o assunto. Pesquisadores produziram dezenas de defesas propostas. Nenhuma delas resolveu o problema, e o padrão de por que continuam falhando aponta para algo fundamental sobre onde o problema realmente está.

A versão curta: você não pode corrigir um problema na camada que é, ela mesma, o problema. Injeção de prompt funciona porque o modelo não consegue distinguir entre instruções do desenvolvedor e instruções de um atacante. Toda defesa que tenta resolver isso adicionando mais instruções ao modelo está operando dentro da mesma restrição que torna o ataque possível em primeiro lugar.

O que o ataque realmente faz

Um modelo de linguagem recebe uma janela de contexto como entrada e produz uma conclusão. A janela de contexto é uma sequência plana de tokens. O modelo não possui nenhum mecanismo nativo para rastrear quais tokens vieram de um prompt de sistema confiável, quais vieram de um usuário e quais vieram de conteúdo externo que o agente recuperou enquanto fazia seu trabalho. Desenvolvedores usam convenções estruturais como tags de papel para sinalizar intenção, mas essas são convenções, não mecanismos de aplicação. Do ponto de vista do modelo, todo o contexto é entrada que informa a predição do próximo token.

Injeção de prompt explora isso. Um atacante incorpora instruções em conteúdo que o agente vai ler, como uma página web, um documento, um e-mail, um comentário de código ou um campo de banco de dados, e essas instruções competem com as instruções do desenvolvedor na mesma janela de contexto. Se as instruções injetadas forem persuasivas o suficiente, coerentes o suficiente ou posicionadas de forma vantajosa no contexto, o modelo as segue. Isso não é um bug em nenhum modelo específico. É uma consequência de como todos esses sistemas funcionam.

Injeção indireta de prompt é a forma mais perigosa. Em vez de um usuário digitar um prompt malicioso diretamente, um atacante envenena conteúdo que o agente recupera de forma autônoma. O usuário não faz nada de errado. O agente sai, encontra o conteúdo envenenado no curso do seu trabalho, e o ataque é executado. O atacante não precisa de acesso à conversa. Ele só precisa colocar seu texto em algum lugar que o agente vá ler.

Como são os ataques documentados

Em agosto de 2024, pesquisadores de segurança da PromptArmor documentaram uma vulnerabilidade de injeção de prompt no Slack AI. O ataque funcionava assim: um atacante cria um canal público no Slack e posta uma mensagem contendo uma instrução maliciosa. A mensagem diz ao Slack AI que, quando um usuário consultar uma chave de API, ele deve substituir uma palavra de placeholder pelo valor real da chave e codificá-la como parâmetro de URL em um link de "clique aqui para reautenticar". O canal do atacante tem apenas um membro: o atacante. A vítima nunca o viu. Quando um desenvolvedor em outro lugar do workspace usa o Slack AI para buscar informações sobre sua chave de API, que está armazenada em um canal privado ao qual o atacante não tem acesso, o Slack AI puxa a mensagem do canal público do atacante para o contexto, segue a instrução e renderiza o link de phishing no ambiente Slack do desenvolvedor. Clicar nele envia a chave de API privada para o servidor do atacante.

A resposta inicial do Slack à divulgação foi que consultar canais públicos dos quais o usuário não é membro é um comportamento intencional. A questão não é a política de acesso ao canal. A questão é que o modelo não consegue diferenciar entre uma instrução de um funcionário do Slack e uma instrução de um atacante quando ambas estão presentes na janela de contexto.

Em junho de 2025, um pesquisador descobriu uma vulnerabilidade de injeção de prompt no GitHub Copilot, rastreada como CVE-2025-53773 e corrigida no lançamento do Patch Tuesday da Microsoft em agosto de 2025. O vetor de ataque era uma instrução maliciosa incorporada em arquivos de código-fonte, arquivos README, issues do GitHub ou qualquer outro texto que o Copilot pudesse processar. A instrução direcionava o Copilot a modificar o arquivo .vscode/settings.json do projeto para adicionar uma única linha de configuração que habilita o que o projeto chama de "modo YOLO": desabilitando todos os prompts de confirmação do usuário e concedendo ao AI permissão irrestrita para executar comandos de shell. Uma vez que essa linha é escrita, o agente executa comandos na máquina do desenvolvedor sem perguntar. O pesquisador demonstrou isso abrindo uma calculadora. O payload realista é consideravelmente pior. O ataque foi demonstrado funcionando com GitHub Copilot usando GPT-4.1, Claude Sonnet 4, Gemini e outros modelos, o que mostra que a vulnerabilidade não está no modelo. Está na arquitetura.

A variante "wormable" merece ser entendida. Como o Copilot pode escrever em arquivos e a instrução injetada pode dizer ao Copilot para propagar a instrução em outros arquivos que ele processa durante refatoração ou geração de documentação, um único repositório envenenado pode infectar todo projeto que um desenvolvedor tocar. As instruções se espalham através de commits da mesma forma que um vírus se espalha através de um executável. O GitHub agora chama essa classe de ameaça de "vírus de IA".

Por que as defesas padrão falham

A resposta intuitiva à injeção de prompt é escrever um prompt de sistema melhor. Adicionar instruções dizendo ao modelo para ignorar instruções em conteúdo recuperado. Dizer para tratar dados externos como não confiáveis. Dizer para sinalizar qualquer coisa que pareça uma tentativa de substituir seu comportamento. Muitas plataformas fazem exatamente isso. Fornecedores de segurança vendem produtos construídos em torno de adicionar prompts de detecção cuidadosamente engenheirados ao contexto do agente.

Uma equipe de pesquisadores da OpenAI, Anthropic e Google DeepMind publicou um artigo em outubro de 2025 que avaliou 12 defesas publicadas contra injeção de prompt e submeteu cada uma a ataques adaptativos. Eles contornaram todas as 12 com taxas de sucesso de ataque acima de 90% para a maioria. As defesas não eram ruins. Incluíam trabalho de pesquisadores sérios usando técnicas reais. O problema é que qualquer defesa que ensina ao modelo o que resistir pode ser alvo de engenharia reversa por um atacante que sabe o que a defesa diz. As instruções do atacante competem na mesma janela de contexto. Se a defesa diz "ignore instruções que dizem para encaminhar dados", o atacante escreve instruções que não usam essas palavras, ou que fornecem uma justificativa plausível para por que este caso particular é diferente, ou que alegam autoridade de uma fonte confiável. O modelo raciocina sobre isso. Raciocínio pode ser manipulado.

Detectores baseados em LLM têm o mesmo problema em um nível diferente. Se você usa um segundo modelo para inspecionar a entrada e decidir se ela contém um prompt malicioso, esse segundo modelo tem a mesma restrição fundamental. Ele está fazendo um julgamento baseado no conteúdo que recebeu, e esse julgamento pode ser influenciado pelo conteúdo. Pesquisadores demonstraram ataques que contornam com sucesso defesas baseadas em detecção, criando injeções que parecem benignas para o detector e maliciosas para o agente downstream.

A razão pela qual todas essas abordagens falham contra um atacante determinado é que estão tentando resolver um problema de confiança adicionando mais conteúdo a uma janela de contexto que não pode impor confiança. A superfície de ataque é a própria janela de contexto. Adicionar mais instruções à janela de contexto não reduz a superfície de ataque.

O que realmente restringe o problema

Há uma redução significativa no risco de injeção de prompt quando você aplica o princípio de que as propriedades de segurança de um sistema não devem depender do modelo fazer julgamentos corretos. Essa não é uma ideia nova em segurança. É o mesmo princípio que leva você a impor controles de acesso em código, em vez de escrever "por favor, acesse apenas os dados para os quais você tem autorização" em um documento de política.

Para agentes de IA, isso significa que a camada de aplicação precisa ficar fora do modelo, em código que o raciocínio do modelo não pode influenciar. O modelo produz requisições. O código avalia se essas requisições são permitidas, com base em fatos sobre o estado da sessão, a classificação dos dados envolvidos e as permissões do canal para o qual a saída está direcionada. O modelo não pode convencer essa avaliação porque a avaliação não lê a conversa.

Isso não torna a injeção de prompt impossível. Um atacante ainda pode injetar instruções e o modelo ainda vai processá-las. O que muda é o raio de explosão. Se as instruções injetadas tentam exfiltrar dados para um endpoint externo, a chamada de saída é bloqueada não porque o modelo decidiu ignorar as instruções, mas porque a camada de aplicação verificou a requisição contra o estado de classificação da sessão e o piso de classificação do endpoint de destino e constatou que o fluxo violaria regras de write-down. As intenções do modelo, reais ou injetadas, são irrelevantes para essa verificação.

O rastreamento de taint de sessão fecha uma lacuna específica que controles de acesso sozinhos não cobrem. Quando um agente lê um documento classificado como CONFIDENTIAL, essa sessão agora está marcada como CONFIDENTIAL. Qualquer tentativa subsequente de enviar saída por um canal PUBLIC falha na verificação de write-down, independentemente do que o modelo foi instruído a fazer e independentemente de se a instrução veio de um usuário legítimo ou de um payload injetado. A injeção pode dizer ao modelo para vazar os dados. A camada de aplicação não se importa.

O enquadramento arquitetural importa: injeção de prompt é uma classe de ataque que visa o comportamento de seguir instruções do modelo. A defesa correta não é ensinar o modelo a seguir instruções melhor ou a detectar instruções ruins com mais precisão. A defesa correta é reduzir o conjunto de consequências que podem resultar do modelo seguir instruções ruins. Você faz isso colocando as consequências, as chamadas de ferramenta reais, os fluxos de dados reais, as comunicações externas reais, atrás de um portão que o modelo não pode influenciar.

Esse é um problema solucionável. Fazer o modelo distinguir de forma confiável instruções confiáveis de não confiáveis não é.