A OWASP mantém prompt injection como LLM01 no Top 10 for LLM Applications desde 2023, e em 2025 reafirmou essa posição com um agravante: a superfície de ataque cresceu à medida em que aplicações passaram a integrar LLMs com ferramentas externas, bases de dados e pipelines de agentes autônomos. O Wiz Research, grupo de pesquisa da Wiz, reportou um aumento de 340% nas tentativas de prompt injection no quarto trimestre de 2025, com ataques bem-sucedidos subindo 190%. O International AI Safety Report 2026, liderado por Yoshua Bengio com a contribuição de mais de 100 pesquisadores, concluiu que atacantes sofisticados conseguem contornar defesas dos modelos mais protegidos em proporção significativa de tentativas, com taxas que variam por cenário e modelo. Esses dados me levam a questionar por que a infraestrutura de monitoramento existente é estruturalmente incapaz de detectar esse vetor.
O mecanismo que torna prompt injection um problema fundamentalmente diferente das vulnerabilidades tradicionais está na arquitetura dos LLMs. Em aplicações convencionais, instruções e dados ocupam canais separados com sintaxe distinta: uma query SQL tem estrutura formal, uma entrada de formulário tem tipo definido, e a fronteira entre código e dados é demarcada por parsing determinístico. Em LLMs, instruções e dados são processados no mesmo canal como linguagem natural, sem separação formal entre instrução do sistema e input do usuário. O modelo interpreta tudo como sequência de tokens, o que significa que um input suficientemente competente pode alterar o comportamento do sistema da mesma forma que uma instrução legítima. Não existe fronteira pra violar. Essa ambiguidade é uma propriedade constitutiva da arquitetura, e nenhuma camada de sanitização pode eliminá-la com a mesma eficácia que prepared statements eliminam SQL injection.
A taxonomia prática dos ataques se divide em duas categorias com implicações operacionais distintas. Prompt injection direta ocorre quando o atacante insere instruções no input que o modelo processa, como pedir a um chatbot de atendimento que ignore suas instruções anteriores e exiba o system prompt. Prompt injection indireta ocorre quando o conteúdo malicioso está em fontes externas que o modelo consome durante a execução: documentos numa base RAG, páginas web indexadas, emails processados por um assistente, issues num repositório Git. A Anthropic, no system card de fevereiro de 2026, reduziu a ênfase na métrica de prompt injection direta como indicador de segurança, argumentando que injection indireta representa a ameaça mais relevante em contextos enterprise, onde o atacante nunca interage diretamente com o modelo, mas contamina as fontes que o modelo consulta.
Os incidentes documentados em 2025 e 2026 demonstram que o problema não é meramente teórico, mas concreto e recorrente. O CVE-2025-53773, classificado com CVSS 7.8, demonstrou que um prompt injection em qualquer conteúdo processado pelo Copilot (arquivos de código, páginas web, issues, respostas de tool calls) podia manipular o GitHub Copilot pra modificar configurações do VS Code e habilitar execução automática de código sem aprovação do usuário. Em fevereiro de 2026, o ataque batizado de RoguePilot pela Orca Research Pod, equipe de pesquisa da Orca Security, se tornou um dos primeiros casos documentados de weaponização completa de um assistente de código: prompt injections em linguagem natural embutidos em Issues de repositórios GitHub iniciavam uma cadeia que incluía symlinks pra arquivos de credenciais, exploração de JSON $schema pra exfiltração via GET e execução de comandos via tools do Copilot dentro de sessões Codespaces, resultando em roubo de credenciais e takeover de repositório. O CrowdStrike Global Threat Report 2026 documentou o uso de técnicas de prompt injection contra ferramentas de GenAI em mais de 90 organizações, com foco no roubo de credenciais e criptomoedas. Em um caso distinto, invasores incorporaram conteúdo oculto a e-mails de phishing para enganar um sistema de triagem baseado em IA.
Pra mim, o problema central está aqui: WAFs, SIEMs e ferramentas tradicionais de segurança operam sobre padrões sintáticos: assinaturas de payloads conhecidos, regex sobre inputs, rate limiting, detecção de anomalias em tráfego de rede. Prompt injection não tem assinatura sintática estável. Nenhuma. O payload é linguagem natural, pode estar em qualquer idioma, pode ser semanticamente equivalente ao uso legítimo e muda de forma a cada tentativa. Um WAF que bloqueia a string "ignore previous instructions" não detecta "disregard the context above and instead" nem uma instrução equivalente em mandarim embutida num PDF que o modelo processa via RAG. E ainda que se tente cobrir 100% dos alfabetos e idiomas, ainda sobram as pseudo-fontes unicode de estilização, que alguns modelos entendem tão bem quanto humanos. A detecção precisa operar no nível semântico, e as ferramentas de controle perimetral foram projetadas pro nível sintático. Na perspectiva de uma auditoria ISO 27001, os controles A.8.9 e A.8.25 não contemplam nativamente um vetor onde o input malicioso é indistinguível do legítimo no nível de formato, o que exige controles compensatórios específicos pra aplicações que integram LLMs.
A mitigação opera em camadas, e nenhuma é suficiente isoladamente. Na entrada, classificadores treinados pra detectar padrões de injection reduzem a superfície ao custo de falsos positivos em inputs legítimos. Na saída, a validação das respostas bloqueia dados que o modelo não deveria expor antes que cheguem ao usuário ou a sistemas em etapas posteriores no fluxo. Entre essas duas camadas, a separação de privilégios, associada a listas de permissão para ferramentas e ao isolamento em contêineres com gVisor ou Firecracker, assegura que mesmo um ataque bem-sucedido opere dentro de um perímetro controlado. A validação humana em operações destrutivas, por sua vez, atua como a última barreira antes da execução de ações irreversíveis. O custo dessa arquitetura em camadas está no aumento da latência e da complexidade operacional, além de exigir uma manutenção capaz de acompanhar a evolução dos ataques.
Pra mim o ponto que equipes de segurança precisam internalizar é que prompt injection não é uma vulnerabilidade que será eliminada por um patch ou por uma versão futura do modelo. A ambiguidade entre instrução e dado é constitutiva da arquitetura atual, e enquanto modelos processarem linguagem natural como sequência indiferenciada de tokens, a superfície de ataque existirá. Tratar segurança de LLMs com o mesmo framework conceitual de aplicações web tradicionais produz uma falsa sensação de cobertura, até porque o modelo de ameaças é estruturalmente diferente. O que uma auditoria de segurança de aplicações com LLM exige é a demonstração de que os controles operam no nível semântico onde o ataque acontece.