Um assistente de e-mail recebe uma mensagem solicitando um resumo, recupera documentos corporativos relacionados, aciona uma ferramenta de calendário e gera uma resposta concisa em HTML. Um único e-mail não confiável pode entrar nesse fluxo como conteúdo, mas o modelo processa seu texto juntamente com as instruções da tarefa. Se esse conteúdo alterar a saída — mudando de “resumir esta mensagem” para “executar uma ação não planejada” —, temos uma injeção de prompt: uma entrada que altera o comportamento do modelo além da tarefa pretendida pela aplicação.
Nosso assistente em execução possui cinco pontos onde o conteúdo é incorporado a uma solicitação do modelo. O usuário fornece o texto do e-mail, o sistema de recuperação retorna trechos indexados, ferramentas conectadas retornam dados, o modelo emite texto ou argumentos de ferramenta e o renderizador transforma essa saída em HTML. Cada etapa envolve um nível de confiança diferente, mas o modelo recebe um fluxo combinado de tokens, em vez de uma separação de segurança imposta pela aplicação.
Antes de avaliarmos os controles, vamos examinar em que pontos os dados podem se transformar em instruções dentro desse fluxo.
O fluxo demonstra por que filtrar apenas a caixa de chat é insuficiente. Um e-mail externo pode conter a instrução injetada, um processo de recuperação pode inseri-la no contexto e o resultado de uma ferramenta pode repeti-la em uma etapa posterior. A renderização de HTML adiciona outra camada de complexidade, pois uma saída que, para o modelo, é apenas texto, pode se transformar em um link ativo, marcação ou solicitação no navegador. Classifique cada fonte como confiável, parcialmente confiável ou não confiável antes que ela chegue ao contexto e preserve essa classificação nos logs.
Esse fluxo misto constitui o escopo da OWASP LLM01:2026. Ele abrange a injeção direta, proveniente da entrada do usuário, e a injeção indireta, originada de documentos recuperados, e-mails, páginas da web, saídas de ferramentas, memória persistente, imagens, áudio e vídeo. Um caso direto começa com uma mensagem do usuário. Um caso indireto ocorre quando o corpo de um e-mail, presente no índice de recuperação do nosso assistente, fornece um texto que o usuário nunca escreveu ou viu.
Podemos classificar cada caso com base em três eixos. A superfície de entrega é o ponto de entrada do conteúdo, como um e-mail ou a resposta de uma ferramenta. A propagação refere-se ao trajeto subsequente, como a transferência de um resultado de recuperação para a memória persistente. A codificação diz respeito à forma de representação, incluindo texto simples, caracteres Unicode ocultos ou instruções incorporadas em uma imagem. Essa classificação nos permite testar a rota real, e não apenas um padrão de frase.
A parametrização tradicional impede que os dados alterem a sintaxe da consulta, uma vez que o banco de dados trata os parâmetros separadamente. As aplicações atuais de LLM não possuem uma separação clara equivalente quando instruções e dados chegam como tokens no mesmo contexto. Delimitadores e rótulos podem esclarecer a intenção, mas não impõem autoridade. Em vez disso, o limite de segurança deve estar situado fora do modelo, onde o código verifica permissões, valida argumentos e restringe o alcance da saída.
Premissa de trabalho Trate qualquer entrada do modelo como capaz de influenciar a saída, mesmo quando ela tiver chegado por meio de um sistema interno de recuperação de informações.
Uma vez que um e-mail injetado afeta a saída, o resultado depende do que a aplicação que envolve o modelo permite. Se o assistente revelar conteúdo oculto do sistema ou um trecho privado recuperado, o cenário enquadra-se em OWASP LLM08:2026 Hidden Context Exposure (Exposição de Contexto Oculto). Se ele gerar HTML que o renderizador aceite sem higienização, ou argumentos de ferramenta que o código subsequente execute sem validação, o cenário enquadra-se em OWASP LLM10:2026 Improper Output Handling (Manipulação Inadequada de Saída). O LLM01 é o comprometimento na entrada que desencadeia esses resultados.
A mesma injeção também pode tentar uma ação insegura no calendário ou a persistência de dados no corpus de recuperação. Essas consequências são agravadas quando um modelo pode chamar ferramentas com amplos poderes, mas a solicitação do modelo nunca deve servir como sua própria autorização. O serviço de calendário deve verificar a autoridade do usuário, limitar campos de escrita e exigir aprovação para alterações significativas. O renderizador deve permitir apenas formatos de saída seguros. Cada camada limita um caminho diferente após a alteração da saída do modelo.
Compare os resultados para identificar qual limite deve barrar cada um deles.