Prompt injection: a ordem escondida no que o seu agente de IA lê

Um agente de IA no WhatsApp, no chat do site ou na caixa de e-mail passa o dia lendo texto que a empresa não escreveu. É para isso que ele existe: entender o pedido do cliente, abrir o comprovante que ele mandou, resumir o e-mail do fornecedor. O problema é que, para o modelo de linguagem, instrução e conteúdo chegam pelo mesmo canal, como texto. Se alguém escreve uma ordem dentro do conteúdo, o agente pode obedecer.

As explicações que aparecem no topo da busca contam bem o que é o ataque e trazem exemplos de fora do Brasil, com conselhos para o usuário final ou para quem treina modelos. Este artigo fala com outra pessoa: a empresa que já pôs um agente para conversar com cliente ou mexer em sistema. Você vai ver por onde o texto de terceiro entra, por que reforçar o prompt não resolve e a matriz que decide o que o agente pode fazer sozinho.

O que é prompt injection?

Prompt injection, ou injeção de prompt, é a manipulação de um sistema de IA por meio do próprio texto que ele recebe. O OWASP, fundação que mantém as listas de referência em segurança de aplicações, define a vulnerabilidade como o caso em que entradas alteram o comportamento ou a saída do modelo de forma não pretendida, e lembra que essas entradas nem precisam ser visíveis para uma pessoa: basta que o modelo as processe.

A OpenAI usa uma definição parecida no guia de segurança para quem constrói agentes: o ataque acontece quando texto ou dado não confiável entra no sistema e o conteúdo malicioso tenta sobrepor as instruções dadas à IA. Note a palavra sobrepor. O atacante não invade o servidor; ele escreve algo que o modelo trata como se fosse ordem da empresa.

Como funciona o prompt injection por dentro?

Um agente recebe, a cada passo, um bloco de texto montado pela aplicação: as instruções da empresa, o histórico da conversa, o resultado de uma consulta, o conteúdo de um anexo. O modelo lê tudo junto e decide o próximo passo. Não existe, dentro dele, uma parede física entre “isto é ordem do dono” e “isto é o que o cliente mandou”. Existe só a tendência, treinada, de dar mais peso a uma parte do que à outra.

O OWASP separa dois tipos. Na injeção direta, a pessoa que conversa com o agente escreve a ordem na própria mensagem, de propósito ou sem querer. Na injeção indireta, a ordem está num conteúdo que o agente busca ou recebe: um site que ele consulta, um arquivo que alguém anexou, um documento da base de conhecimento. A indireta é a mais perigosa para empresa, porque quem planta a ordem não precisa nem falar com o agente.

A ordem também não precisa estar à vista. A Anthropic descreve o caso de um e-mail com instruções escritas em fonte branca, invisíveis para quem lê, mas processadas pelo agente. O OWASP lista ainda ordens escondidas em imagens, divididas em pedaços ao longo de um currículo e codificadas em outros idiomas, Base64 ou emojis para passar pelos filtros.

Qual a diferença entre prompt injection e jailbreak?

Os dois termos aparecem misturados, e o OWASP reconhece que costumam ser usados como sinônimos. Pela definição dele, jailbreak é uma forma de prompt injection: aquela em que o objetivo é fazer o modelo abandonar por completo as regras de segurança, para gerar algo que ele recusaria. Já a injeção de prompt é o gênero, e inclui ataques que não têm nada a ver com conteúdo proibido: só querem que o agente faça outra coisa.

Na prática, a empresa que opera um agente de atendimento se preocupa menos com jailbreak, que é sobretudo um problema de quem desenvolve o modelo, e mais com a injeção indireta. É ela que transforma um anexo inocente em comando.

Por onde o texto de terceiro entra no agente da sua empresa?

A pergunta útil não é “meu agente pode sofrer prompt injection?”, porque qualquer agente que lê texto de fora pode. A pergunta é quais portas existem. No agente típico de uma empresa brasileira, elas são estas.

Repare que nenhuma dessas portas é exótica. São exatamente os canais que justificam ter um agente. Fechar todas elas tiraria a utilidade dele, e por isso a defesa não pode depender de impedir o texto de entrar. Ela tem de limitar o que acontece depois que ele entra.

Quais são exemplos reais de prompt injection?

O OWASP descreve cenários que qualquer empresa reconhece. Num deles, o atacante escreve ao chatbot de suporte mandando ignorar as diretrizes, consultar bases privadas e enviar e-mails. Em outro, alguém altera um documento usado pela base de conhecimento, e todo usuário que cair naquela resposta recebe o conteúdo manipulado. Num terceiro, um candidato manda um currículo com a ordem dividida em partes, e a ferramenta que avalia candidatos passa a recomendá-lo.

O caso que fez o termo subir na busca brasileira veio do Judiciário. Segundo reportagem do Migalhas, de maio de 2026, duas advogadas incluíram numa petição trabalhista em Parauapebas (PA) um texto em fonte branca sobre fundo branco, dirigido à inteligência artificial, pedindo uma contestação superficial. A ferramenta de IA usada pela Justiça do Trabalho detectou o comando, e o juiz aplicou multa solidária de 10% sobre o valor da causa e oficiou a OAB.

O mecanismo é o mesmo que ameaça uma empresa: um documento que uma pessoa lê de um jeito e a máquina lê de outro. A diferença é que, no atendimento, o documento chega pelo cliente, e quem decide o que fazer com ele é o seu agente.

Por que escrever “ignore ordens de terceiros” no prompt não resolve?

É a primeira reação de quem descobre o problema: acrescentar às instruções uma linha dizendo que o agente nunca deve obedecer a ordens vindas de mensagens ou anexos. Ajuda. O próprio OWASP lista “restringir o comportamento do modelo” no prompt como mitigação. Mas é uma instrução a mais disputando atenção com a instrução plantada, e o modelo decide por tendência, não por regra rígida.

O OWASP é direto: dada a natureza probabilística dos modelos, não está claro se existem métodos infalíveis de prevenção. E quem desenvolve os modelos diz o mesmo com números.

Um por cento parece pouco até ser traduzido para volume. Um agente que lê milhares de mensagens e anexos por mês não enfrenta uma tentativa; enfrenta todas as que aparecerem. E o número é de um teste de laboratório de quem fabrica o modelo, com as defesas mais recentes dele, não do agente montado às pressas numa plataforma qualquer.

A pergunta certa não é se o agente vai ser enganado um dia. É o que ele consegue fazer no dia em que for.

Quem pode escrever para o agente e o que ele pode fazer sozinho?

Se não dá para garantir que o agente nunca será enganado, o risco passa a ser medido por duas perguntas. A primeira: quem consegue fazer texto chegar até ele? Só a equipe interna, clientes identificados ou qualquer pessoa, inclusive por arquivo e página da web. A segunda: o que ele faz sem ninguém conferir? Só responde, consulta dados ou altera, envia e paga.

Cruzando as duas, aparecem três zonas. Um agente interno que só responde é de risco baixo: o pior caso é uma resposta errada para alguém da casa. Um agente de atendimento que consulta pedidos fica no meio: o risco é mostrar a um cliente o dado de outro. E um agente aberto a qualquer pessoa, que lê anexos e pode estornar, enviar e-mail ou alterar cadastro, está na zona crítica.

A matriz serve para uma conversa que quase nunca acontece antes do lançamento: em que célula o nosso agente está, e em que célula ele precisa estar? Muitas vezes a resposta é tirar uma permissão que ninguém usava, ou trocar uma ação automática por um botão de confirmação. Se o agente ainda está em desenho, vale a mesma conversa que fazemos ao decidir entre agente de IA ou fluxo automatizado: tarefa que pode ser regra fixa não precisa ler texto livre.

Quais são as três travas que limitam o estrago?

O OWASP lista sete mitigações. Três delas mudam a arquitetura, não o texto, e são as que seguram quando a instrução plantada vence o prompt. A OpenAI chega às mesmas no guia para quem constrói agentes.

1. Menor privilégio: o agente só alcança o que a tarefa pede

O OWASP recomenda que a aplicação tenha as próprias credenciais e trate as funções no código, em vez de entregá-las ao modelo, e que o acesso do modelo fique no mínimo necessário. Na prática: o agente que informa status de pedido consulta o pedido daquele cliente, pelo número e pelo telefone verificado, e não a tabela inteira. Se ele não tem acesso, nenhuma ordem plantada faz ele vazar.

2. Aprovação humana para ação de risco

Para operações privilegiadas, o OWASP pede controle com uma pessoa no circuito. O guia da OpenAI vai além para ferramentas conectadas: manter a aprovação ligada para que o usuário revise e confirme cada operação, inclusive leituras e gravações. Para uma empresa, isso vira uma lista curta de ações que nunca acontecem sozinhas: estorno, desconto fora da tabela, envio de documento para endereço novo, alteração de cadastro, exclusão.

3. Conteúdo de fora separado e marcado

A terceira trava trata do caminho do texto. O OWASP manda separar e identificar com clareza o conteúdo não confiável. A OpenAI detalha: não colocar variáveis não confiáveis nas mensagens de desenvolvedor, que têm prioridade sobre as demais, e extrair de entradas externas só campos estruturados e validados, como uma lista fechada de opções.

Um exemplo concreto: o agente que lê comprovantes não deveria receber o PDF e “decidir”. Ele deveria extrair valor, data e CNPJ do pagador em campos fixos, e um código comum compara esses campos com o boleto. Qualquer frase a mais no PDF fica sem ter para onde ir.

Como identificar uma tentativa de prompt injection?

Detectar é útil, mas é a camada mais fraca, porque o atacante escreve justamente para não ser detectado. Mesmo assim, há sinais que valem um alerta no painel de quem acompanha o agente.

• Frases de comando dentro de conteúdo: “ignore”, “esqueça as instruções”, “a partir de agora”, “você é”, aparecendo em anexo ou e-mail, não na pergunta do cliente.
• Texto que a pessoa não vê: fonte branca, tamanho mínimo, caracteres invisíveis ou trechos codificados num documento.
• Pedido fora da tarefa: cliente de segunda via perguntando pelas regras internas do agente ou pelo desconto máximo.
• Ferramenta chamada sem motivo: o agente tenta enviar e-mail, abrir link ou consultar outro cliente numa conversa que não pedia isso.
• Resposta com link ou imagem que ninguém pôs na base: é um dos caminhos de vazamento descritos pelo OWASP.

Para enxergar esses sinais é preciso registrar as conversas e as chamadas de ferramenta, e alguém precisa ler uma amostra delas com frequência. Os testes adversariais que o OWASP recomenda entram no mesmo conjunto de testes do lançamento, que descrevemos no guia sobre como criar um agente de IA e testá-lo antes do cliente: cada tentativa de manipulação vira um caso fixo, rodado a cada ajuste.

Quais os erros mais comuns ao proteger um agente?

1. Confiar no prompt como cofre. Instrução é orientação, não permissão. O que o agente não pode fazer deve estar bloqueado no sistema.
2. Dar ao agente a credencial de administrador porque era mais rápido de integrar. Todo acesso a mais é estrago possível a mais.
3. Colar o texto do cliente dentro das instruções, montando o prompt com a mensagem no meio. É exatamente o que a OpenAI manda evitar.
4. Esquecer que a base de conhecimento também é entrada. Documento editado sem revisão muda a resposta para todo mundo.
5. Testar só com pergunta educada. Se ninguém tentou enganar o agente antes do lançamento, o primeiro a tentar será um cliente.
6. Tratar como problema só de TI. Quem decide que ação exige aprovação é a área de negócio, que sabe quanto custa um estorno indevido.

Há uma ligação direta com outro risco do atendimento automatizado: o agente que promete o que a empresa não oferece. Uma injeção bem-sucedida é uma das formas de chegar lá, e a responsabilidade perante o consumidor continua sendo da empresa, como discutimos em quem responde quando o chatbot com IA erra.

O que muda conforme o tipo de agente?

A mesma lógica se aplica a qualquer agente, mas a célula da matriz muda bastante de um uso para outro. Alguns exemplos para situar o seu caso.

• Agente de dúvidas no site, sem login e sem ferramenta: risco baixo de dano, risco real de constrangimento. Cuide da base revisada e do que ele pode afirmar.
• Agente de atendimento no WhatsApp com consulta de pedido: o centro do risco é a identificação. Ele só pode mostrar o dado de quem provou ser o titular.
• Agente que lê comprovantes, notas ou currículos: injeção indireta em estado puro. Extraia campos fixos e deixe a decisão para regra ou pessoa.
• Agente com acesso à caixa de e-mail: a porta mais aberta de todas. Enviar, encaminhar e apagar ficam atrás de aprovação, sem exceção.
• Agente que navega na web para pesquisar: toda página é conteúdo não confiável. Ele lê, resume e entrega, mas não age com base no que leu sem confirmação.

Quando é a equipe que usa assistentes de IA por conta própria, com anexos de clientes e acesso a e-mail, a matriz vale do mesmo jeito, só que sem ninguém olhando. É o tema do artigo sobre shadow AI, a IA que o funcionário já usa.

Por onde começar hoje

Não é preciso um projeto de segurança para dar o primeiro passo. Uma reunião de uma hora, com quem montou o agente e com quem responde pelo atendimento, resolve a maior parte.

1. Liste as portas: por quais canais texto de fora chega ao agente: mensagem, anexo, e-mail, página, base de conhecimento, imagem.
2. Liste as ações: tudo o que ele consegue fazer em outro sistema, com a credencial que tem hoje.
3. Marque a célula: cruze as duas listas na matriz e veja onde o agente está.
4. Corte o que sobra: retire permissão que a tarefa não usa e restrinja consultas ao dado do próprio cliente.
5. Ponha um botão nas ações de risco: estorno, envio, alteração e exclusão passam por uma pessoa.
6. Transforme ataques em testes: cada tentativa de manipulação, sua ou de cliente, vira um caso fixo no conjunto de testes.

Se o agente ainda está no papel, ou se você quer saber em que pé está a IA no seu marketing e no seu atendimento, o diagnóstico de marketing gratuito da Alliance é um bom ponto de partida. E, para desenhar ou revisar o agente com essas travas desde o início, conheça o nosso serviço de agentes de IA para empresas.