A OWASP diz que a prompt injection está por resolver. Configurar não o salva.
A indústria de segurança passou dois anos a tratar a prompt injection como um bug: algo que um bom filtro, um system prompt mais rígido, ou a próxima versão do modelo acabaria por limpar. Esse enquadramento é confortável porque implica que o problema tem dono e data de correção. Também acontece estar errado, e quem está mais perto do problema começou a dizê-lo em voz alta.
Só que a notícia vinda da Infosecurity Europe, como reportou a Infosecurity Magazine, não é "encontrámos um filtro melhor". É o contrário. A OWASP classifica a prompt injection como o risco número um para aplicações com LLM, e um investigador da OWASP usou um palco público para avisar que continua por resolver. Não difícil. Não parcialmente mitigado. Por resolver. É uma afirmação de outro tipo do que a indústria está habituada a ouvir sobre uma vulnerabilidade no topo da tabela, e devia mudar a forma como constrói arquitetura, e não apenas a forma como se preocupa.
Porque, se a própria autoridade da área em risco de LLM lhe está a dizer que o problema não tem correção na camada do modelo, então todas as defesas que assumem que a correção está a caminho estão construídas sobre areia.
"Por resolver" é um input de desenho, não um aviso legal
A maioria das pessoas ouve "por resolver" e arquiva-o em más notícias a gerir. É o sítio errado para arquivar. Por resolver é um facto arquitetural, e dita aquilo que um desenho responsável pode assumir.
A prompt injection está por resolver por uma razão estrutural, não de maturidade. Um modelo de linguagem lê um fluxo de tokens e não consegue separar com fiabilidade as instruções que lhe deu do conteúdo que lhe pediu para processar. Quando lê um documento, o texto do documento e os seus comandos chegam pelo mesmo canal, e o modelo não tem forma privilegiada de saber qual é qual. É por isso que o problema resiste a correções: é uma propriedade de como o modelo lê, não um defeito de um modelo em particular.
A cobertura do mesmo material da OWASP pela Help Net Security enquadra as falhas em redor sem rodeios, e a linha é consistente. A superfície de ataque não está a encolher à medida que os modelos melhoram. Está a crescer à medida que são ligados a mais ferramentas. Relatórios citados a par do aviso da OWASP apontam para um grande aumento homólogo destes ataques, que é exatamente o que se esperaria se a fraqueza subjacente for estrutural e o número de agentes implementados estiver a subir.
Por isso, o pressuposto honesto de planeamento não é "a injeção será reduzida a uma taxa aceitável". É "a injeção vai ter sucesso algumas vezes, e a minha arquitetura tem de continuar segura quando tiver". Tudo o que vem a seguir decorre de aceitar essa frase em vez de discutir com ela.
Configuração não é fronteira
É aqui que a maioria das defesas empresariais falha em silêncio. Perante um problema por resolver, as equipas deitam mão à configuração: um system prompt melhor, um delimitador à volta do texto não confiável, um classificador afinado para sinalizar inputs suspeitos. Ajudam, e deve usá-los. Mas nenhum é uma fronteira. São todos redutores de probabilidade, e um redutor de probabilidade aplicado a um problema estruturalmente insolúvel baixa a taxa de falha sem nunca chegar a zero.
A razão por que configurar não chega tornou-se concreta em 2026. A CVE-2025-6514, com uma pontuação CVSS de 9,6, foi divulgada na infraestrutura central de MCP: execução remota de código na canalização que liga agentes a ferramentas. E a Microsoft documentou, na sua investigação "when prompts become shells", como a prompt injection deixa de ser um problema de texto e se torna uma primitiva de execução de código no momento em que um agente é ligado a ferramentas reais. É esse o escalamento que importa. Num chatbot, uma injeção bem-sucedida produz uma frase má. Num agente com ferramentas, a mesma injeção produz uma ação, e se a canalização tiver uma RCE, produz código arbitrário a correr no seu ambiente.
Nenhum ajuste de system prompt resolve isso. A distância entre "o modelo disse algo errado" e "o agente fez algo errado" não se fecha com configuração, porque o perigo não é o que o modelo acredita. É o que o modelo pode fazer depois de acreditar. Um classificador que deixa passar um input bem construído não se degradou com elegância. Entregou a um atacante as ferramentas que estão por trás dele.
Um problema estrutural precisa de uma resposta estrutural
Se o problema não se resolve na camada do modelo, a única jogada responsável é deixar de tentar tornar o modelo digno de confiança e começar a tornar os erros do modelo inofensivos. É uma passagem da probabilidade para a estrutura, e tem uma forma concreta.
Uma fronteira de contaminação. Dados não confiáveis, tudo o que o agente leu em vez de ter escrito, são marcados e nunca podem tornar-se privilégio executável. Não é um filtro por onde conteúdo não confiável possa escapar. É uma regra sobre o que conteúdo não confiável pode estruturalmente tornar-se, aplicada pelo sistema em vez de esperada do modelo.
O padrão dual-LLM CaMeL. Divida o trabalho por dois modelos. Um planeador privilegiado planeia e invoca ferramentas mas nunca lê conteúdo não confiável. Um leitor em quarentena lê o documento envenenado e extrai o necessário mas não detém ferramentas e não consegue agir. Perante qualquer dúvida, o padrão falha fechado. O componente que vê o ataque não tem mãos, e o componente com mãos nunca vê o ataque. Onde um classificador baixa a probabilidade de confusão, isto remove a capacidade de agir sobre ela.
Identidade não humana de privilégio mínimo. Cada agente corre sob a sua identidade delimitada e de curta duração, com uma allow-list de saída explícita, por isso uma injeção bem-sucedida comanda um ator que só consegue executar um punhado de ações com nome para um punhado de destinos permitidos. Um agente roubado ou sequestrado não vale quase nada porque não há poder permanente de que abusar.
Defesa em profundidade. Nenhum destes é considerado suficiente sozinho. São dispostos em camadas para que contornar um caia no seguinte, precisamente porque "por resolver" significa que qualquer controlo isolado acabará por ser batido por algo novo.
Repare no que une os quatro. Nenhum tenta fazer com que o modelo resista à injeção. Cada um assume que a injeção tem sucesso e garante que esse sucesso não faz nada com consequência. É assim que se parece uma resposta estrutural a um problema estrutural.
O reenquadramento
A pergunta que a indústria insiste em fazer, a que leva diretamente a mais um classificador, é "como travamos a prompt injection?". A OWASP acabou de responder: não trava, não na camada do modelo, não ainda, talvez nunca. Organizar a sua defesa à volta de a resolver é organizar-se à volta de uma solução que não existe.
A pergunta melhor é esta. Quando uma injeção tiver sucesso, e a OWASP está a dizer-nos que vai ter, o que é que a nossa arquitetura estruturalmente a impede de fazer? Se a resposta for "depende de o classificador a apanhar", não tem uma fronteira, tem uma aposta. Se a resposta for "o componente que leu o ataque não consegue agir, e o ator que consegue agir corre sob uma identidade delimitada a quase nada", conteve um problema por resolver em vez de fingir que está resolvido.
A camada do modelo não o salva. A configuração não o salva. A estrutura é a única coisa que aguenta quando aquilo contra que se defende não tem correção.
Se quiser passar os seus agentes em produção pelos quatro controlos estruturais e descobrir até onde chegaria mesmo uma injeção bem-sucedida, marque uma reunião e traga-nos o que está ligado a mais ferramentas.