Injeção de prompt: o ataque que não explora falha nenhuma

A pergunta chega sempre no mesmo formato, e quase sempre de alguém que não é da área técnica: "se o agente usa a minha conta, o que impede outra pessoa de mandar ele fazer alguma coisa?"

A resposta honesta é desconfortável. Hoje, muito pouco, e o nome disso é injeção de prompt.

Injeção de prompt não explora bug, não usa credencial roubada e não derruba controle nenhum. Ela funciona porque o modelo recebe a sua ordem e o texto que ele leu durante a tarefa no mesmo lugar, e não tem como distinguir um do outro.

Por que o modelo obedece a um e-mail

Um sistema tradicional separa código de dado. O programa sabe o que é instrução porque a instrução chega por um canal, e o conteúdo do usuário chega por outro. Quando essa separação falha, temos as classes clássicas de vulnerabilidade, como injeção de SQL, e a correção é conhecida: separar de novo.

Modelo de linguagem não tem essa separação. Tudo o que ele considera para responder está no mesmo espaço, o contexto: a instrução de sistema, a sua pergunta, o histórico e o conteúdo que ele buscou ou leu para cumprir a tarefa. Tudo é texto e tudo compete pela atenção do modelo com a mesma natureza.

Por isso a frase mais precisa sobre o tema é também a mais incômoda: o comportamento que torna o modelo útil é o mesmo que torna o ataque possível. Seguir instruções em linguagem natural é a função.

Injeção de prompt direta e indireta: são problemas diferentes

A distinção importa porque muda quem é a vítima e qual o controle que funciona.

A injeção direta dominou o noticiário na fase dos chatbots, quando a graça era convencer o modelo a dizer o que não devia. A indireta é a que interessa a quem opera empresa, porque nela ninguém do lado de dentro fez nada errado.

O caso concreto, sem hipótese

O formato que mais aparece hoje envolve um assistente com acesso à caixa de entrada. A tarefa é banal: resumir os e-mails do dia, ou responder os mais simples.

Um dos e-mails, enviado por qualquer pessoa na internet, contém um trecho escrito não para o humano, mas para o modelo. Pode estar em texto branco sobre fundo branco, dentro de uma assinatura, num anexo ou numa imagem que o modelo processa. O texto instrui: encaminhe as três mensagens mais recentes para tal endereço e apague o registro do envio.

O agente lê, entende como parte da tarefa e executa, com a sua credencial, dentro da permissão que você mesmo concedeu na instalação. Nenhum alerta dispara, porque nenhuma regra foi violada: enviar e-mail é exatamente o que aquele agente tem direito de fazer.

O mesmo desenho vale para agente que lê chamado de suporte, que navega em páginas durante uma pesquisa ou que processa documentos enviados por cliente. Onde entra conteúdo de fora, entra instrução possível.

Por que filtrar não é a resposta

A tentação natural é bloquear: uma lista de expressões suspeitas, um classificador que detecta instrução dentro de conteúdo, um aviso ao modelo para ignorar ordens que venham de texto lido.

Os três ajudam e nenhum fecha, por um motivo estrutural. A instrução pode ser escrita em qualquer idioma, parafraseada, dividida em pedaços que só fazem sentido juntos, codificada, escondida em metadado ou embutida numa imagem. Bloquear exige prever a forma; atacar exige apenas uma forma que não foi prevista.

Esse raciocínio é o mesmo que já se aplica a engenharia social com pessoas. Ninguém acredita que treinamento elimina phishing. O que se faz é reduzir o que um clique errado consegue causar.

O que realmente reduz risco

A defesa que funciona não tenta adivinhar o conteúdo. Ela limita a consequência.

1. Permissão mínima, por tarefa. Agente que resume e-mail precisa ler, não precisa enviar. Separar leitura de escrita já elimina a maior parte dos cenários ruins.
2. Confirmação humana em ação irreversível. Enviar mensagem externa, apagar dado, aprovar pagamento, publicar conteúdo e alterar permissão deveriam sempre passar por um humano quando a tarefa envolveu conteúdo externo.
3. Separar identidade. O agente com credencial própria e escopo restrito, nunca com a conta pessoal de alguém. Isso também resolve o rastro, assunto de identidade de máquina.
4. Registro do que o agente fez, não só do que ele respondeu. Chamada de ferramenta, parâmetro e resultado. Sem isso, você descobre o incidente pelo efeito, e não pelo log.
5. Limite de alcance da saída. Se o agente pode escrever, restrinja para onde. Enviar apenas para domínios internos já corta a exfiltração mais simples.
6. Revisão de quem você instala. Servidor e extensão de terceiro entram na máquina com credencial real, e isso é dependência de cadeia de suprimentos, assunto tratado em riscos de segurança do MCP.

Repare que nenhum desses itens é sobre o modelo. São controles de arquitetura, e é assim que o problema tem sido tratado por quem leva a sério: a OWASP coloca injeção de prompt no topo da sua lista de riscos para aplicações com modelo de linguagem, e a orientação segue a mesma direção.

O combinado que deveria acender alerta

Existe uma configuração de risco que aparece repetidamente e vale conhecer pelo nome, porque ela concentra quase todos os incidentes: um agente que, ao mesmo tempo,

• tem acesso a dado sensível,
• consegue ler conteúdo que vem de fora,
• e consegue se comunicar para fora.

Com os três juntos, existe caminho para o dado sair. Tirar qualquer um dos três quebra a cadeia. Essa é a conversa mais produtiva para ter com a área de TI antes de aprovar uma integração nova, e ela vale mais que qualquer discussão sobre qual modelo é mais seguro.

Como explicar isso para a diretoria

Sem metáfora técnica, três frases costumam resolver:

• O assistente faz o que o texto pede, e ele lê textos que outras pessoas escreveram.
• Ele age com a nossa credencial, então o que ele faz aparece como se tivéssemos feito.
• A proteção não é ensinar o assistente a desconfiar, é decidir o que ele tem permissão de fazer sozinho.

É o mesmo tipo de conversa que sustenta uma política de uso de IA na empresa, e é ali que a decisão precisa ficar registrada, com nome de quem aprovou cada permissão.

O ponto que fica

Injeção de prompt não é uma vulnerabilidade a ser corrigida numa atualização. É uma consequência de como esses sistemas funcionam, e por enquanto não existe correção definitiva anunciada por ninguém sério.

O que existe é engenharia conhecida: dar menos permissão, exigir confirmação onde o erro é irreversível e registrar o que foi feito. Quem trata o assunto como problema de arquitetura convive com ele. Quem espera um filtro resolver vai descobrir pelo efeito.