Prompt injection em agentes de IA: ataques, riscos e proteção

Um e-mail lido pelo seu agente não pode virar autorização para enviar outra mensagem, exportar dados de clientes ou alterar uma oportunidade de venda. O Open Worldwide Application Security Project (OWASP) classifica o prompt injection como LLM01 em seu Top 10 de aplicações com LLMs. Para quem desenvolve esses sistemas, a resposta prática é limitar o que a aplicação pode fazer mesmo quando o modelo obedece à instrução errada. Hoje, nenhuma defesa resolve o problema por completo.

Texto conferido com base nas orientações vigentes do OWASP e da Anthropic em 26 de outubro de 2026. Os cenários de e-mail e CRM abaixo ilustram propostas de implementação; não são resultados observados em sistemas em produção.

O que é prompt injection?

Prompt injection, ou injeção de prompts, ocorre quando uma entrada desvia um modelo de linguagem das instruções que ele deveria seguir. Um modelo de linguagem de grande porte, ou LLM, interpreta a linguagem para produzir respostas e propor ações. O problema começa quando algo que ele deveria apenas ler passa a ser tratado como uma ordem.

Imagine um funcionário analisando uma carta de um fornecedor. A carta pode descrever um problema na entrega; não pode conceder ao fornecedor acesso à sua base de clientes. Um agente precisa fazer essa mesma distinção entre informação e autoridade, e cabe aos controles da aplicação garantir que ela seja respeitada.

O OWASP aponta tanto a entrada direta do usuário quanto o conteúdo externo indireto como portas de entrada em LLM01:2025 Prompt Injection. O limite decisivo é quem pode definir a tarefa e as permissões, independentemente de o texto suspeito parecer profissional.

Uma resposta errada não é, por si só, uma injeção. O modelo pode inventar um fato sem nenhuma manipulação externa. A injeção envolve especificamente uma entrada que direciona seu comportamento. Ambos os casos podem causar danos, mas um filtro que procura instruções hostis não detecta todos os erros comuns do modelo.

Como o prompt injection funciona na IA generativa?

O modelo lê as instruções junto com o material da tarefa e pode atribuir a esse material uma autoridade que ele não deveria ter. A identificação dos papéis das mensagens e das fontes ajuda a separar as duas coisas, mas não substitui os controles de acesso.

Com um agente, há uma etapa adicional com consequências concretas: a aplicação transforma uma ação proposta em uma chamada de ferramenta. Uma ferramenta é uma função que faz algo fora da conversa, como buscar registros ou enviar uma mensagem. Se a aplicação executa tudo o que o modelo propõe usando credenciais com permissões amplas, um erro de interpretação pode virar uma ação no negócio.

Esse é o limite com que todo agente que usa ferramentas se depara: entender um pedido não significa que ele esteja autorizado.

Exemplos de prompt injection: ataques diretos e indiretos

A diferença está no caminho por onde chega a instrução hostil. Os exemplos a seguir descrevem o comportamento que o atacante tenta provocar, sem reproduzir o texto do ataque.

Prompt injection direto

Um cliente escreve para um assistente de suporte e tenta convencê-lo a revelar anotações da conta de outro cliente, alegando uma autorização interna especial. O atacante usa diretamente o canal de entrada da aplicação.

A defesa precisa incluir um serviço de registros que verifique os direitos de acesso do cliente autenticado. Mesmo que o modelo aceite a história, esse serviço deve negar acesso ao registro de outra pessoa. Uma instrução de recusa no prompt de sistema ajuda a orientar o modelo; a verificação dos registros é o que faz valer o limite.

Prompt injection indireto

Um fundador que também cuida das vendas pede a um agente que resuma o e-mail de um potencial cliente e sugira o próximo passo. A mensagem contém material criado para desviar o agente e fazê-lo exportar contatos sem relação com a tarefa do sistema de gestão de relacionamento com clientes (CRM) para um destinatário externo. O pedido é legítimo; a instrução hostil vem do e-mail que está sendo processado.

O mesmo caminho de entrada pode passar por uma página da web, um documento, um anexo ou o resultado de uma ferramenta. Estar armazenado internamente não torna todo registro confiável: o texto que agora está no CRM pode ter sido fornecido por um cliente. A Anthropic, criadora do modelo de linguagem Claude, trata essas fontes de terceiros como um modelo de ameaça distinto em suas orientações de proteção contra prompt injection.

Em um agente de e-mail, quem envia uma mensagem jamais deve herdar as permissões de ferramentas do dono da caixa de entrada só porque ele pediu um resumo.

Qual é a diferença entre prompt injection e jailbreak?

Um jailbreak tenta contornar as restrições de segurança de um modelo. Já o prompt injection também pode ter como alvo a tarefa normal da aplicação ou suas permissões. Um resumo de vendas adulterado ou uma atualização não autorizada de contato pode parecer inofensivo para um sistema de moderação de conteúdo e, ainda assim, violar as regras do negócio.

Use tanto proteções de conteúdo quanto verificações de autorização. Elas respondem a perguntas diferentes.

Por que ataques de prompt injection colocam o negócio em risco?

O dano potencial aumenta conforme o agente ganha acesso a mais dados e ações. Em suas orientações específicas sobre autonomia excessiva de agentes, o OWASP identifica o excesso de funcionalidades, permissões e autonomia como causas de comportamentos prejudiciais.

Em um sistema de e-mail ou CRM, as consequências se traduzem em problemas conhecidos pelas empresas:

• Dados privados vazam. Uma resposta, um anexo, uma requisição de saída ou uma mensagem inclui informações que o destinatário não deveria receber.
• Registros são alterados sem autorização. O agente edita uma conta, apaga um histórico útil ou muda a etapa de uma oportunidade porque o texto recuperado desviou seu comportamento.
• Uma decisão é distorcida sem chamar atenção. Um potencial cliente parece mais qualificado, uma reclamação desaparece de um resumo ou um fornecedor recebe uma recomendação sem justificativa.

O acesso somente para leitura é mais restrito que o acesso de escrita, mas não impede o vazamento de dados confidenciais. Se a aplicação busca registros privados e pode expô-los em uma resposta ou conexão de saída, a confidencialidade continua exigindo proteção.

A Unit 42, da Palo Alto Networks, documentou instruções maliciosas inseridas em conteúdo publicado na web em uma pesquisa de 3 de março de 2026. Encontrar uma tentativa não prova que todos os alvos a seguiram. Mas mostra por que o conteúdo externo precisa entrar no modelo de ameaças antes de um agente receber permissão para agir.

Quem funda a empresa deve aprovar o dano máximo que um fluxo de trabalho pode causar. Quem desenvolve deve fazer esse limite valer nos pontos de acesso a dados e ferramentas. Quem opera precisa conseguir pausar a execução e investigar quando esses limites são colocados à prova.

Como evitar que o prompt injection vire um incidente?

Projete o sistema considerando que uma injeção pode passar pelas defesas. A proposta abaixo aplica as orientações de privilégios e aprovação do OWASP a um fluxo concreto de agente de e-mail ou CRM. É uma recomendação de controles, não um benchmark de produto nem uma garantia de imunidade.

Comece pelas permissões reais da ferramenta. Uma função chamada “resumir caixa de entrada” não fica limitada a resumos se a credencial por trás dela permite enviar mensagens e apagar e-mails. Verifique a configuração da conta e do serviço usados pela função, além do nome que ela recebeu.

Em seguida, controle os dados que saem da aplicação. Uma lista de destinos de rede permitidos, ou allowlist, ajuda a reduzir as rotas disponíveis para vazamentos. Mas permitir um serviço de e-mail não autoriza qualquer destinatário, assim como permitir o domínio de um CRM não autoriza qualquer conta ou operação de exportação. Valide também a requisição dentro do serviço permitido.

As orientações da Anthropic para implantação segura descrevem como manter credenciais fora do ambiente do agente, restringir o acesso à rede e validar requisições por meio de um proxy. Um proxy é um intermediário que pode aplicar políticas antes de encaminhar uma requisição. Em uma integração de e-mail hospedada, esse papel pode caber ao seu próprio serviço de ferramentas: ele guarda a credencial e rejeita operações fora do escopo.

Para conhecer o conjunto mais amplo de verificações de entrada, saída e execução, veja o guia de guardrails de IA.

Como aplicar as orientações da Anthropic ao conteúdo recuperado?

A Anthropic recomenda passar material de terceiros em blocos tool_result, identificar sua origem, definir uma política explícita para conteúdo não confiável e codificar strings em JSON em vez de inseri-las em instruções de texto livre. As orientações também incluem analisar as saídas das ferramentas e monitorar o comportamento. Consulte as orientações atuais para o Claude.

No exemplo de vendas, mantenha o corpo do e-mail do potencial cliente identificado como uma mensagem daquele remetente. Não o copie para uma instrução privilegiada só porque uma etapa anterior do modelo fez um resumo. Preserve a referência da fonte ao passar as informações extraídas para outra etapa.

JSON é um formato de dados estruturados. Escapar corretamente seu texto impede que ele quebre a serialização ao redor; isso não impede o modelo de ser persuadido pelo significado do conteúdo. Trate a recomendação de codificação como uma camada de defesa, mantendo a autorização sob controle em outro ponto do sistema.

Vincule a aprovação à ação exata que será executada

Um botão de aprovação só protege o negócio se a execução depender daquilo que a pessoa revisou. “Continue processando esta conta” é vago demais para um agente capaz de enviar anexos ou reescrever registros de clientes.

Considere uma proposta de responder a um potencial cliente e atualizar uma oportunidade de venda. Quem revisa precisa ver o destinatário real, a mensagem, a lista de anexos, o registro afetado e os valores dos campos antes e depois da alteração. A aplicação deve preservar a proposta aprovada e executar essa versão. Se o modelo mudar o destinatário ou o anexo depois disso, exija uma nova revisão.

A aprovação também precisa vir de uma pessoa autenticada e com a autoridade necessária. Uma afirmação dentro de um e-mail de que alguém já aprovou o trabalho é conteúdo da fonte, não um evento de aprovação. O modelo não pode criar seu próprio registro de aprovação nem acessar outra ferramenta que contorne essa verificação.

Mantenha a ação pendente se a pessoa responsável recusar a proposta, a aprovação expirar ou o sistema de revisão estiver indisponível. Um tempo limite excedido não pode virar permissão silenciosamente. Planeje as novas tentativas para que uma falha de entrega não faça a mesma mensagem aprovada ser enviada repetidas vezes.

Essas são recomendações de implementação para o fluxo de trabalho, não uma afirmação de que a revisão humana detecta todos os ataques. O guia de IA com participação humana no processo explica como dimensionar a equipe para as filas de revisão e lidar com o encaminhamento de casos que exigem atenção adicional.

Checklist rápido para um agente de e-mail ou CRM

Comece pelo menor escopo que já entregue valor. Use este checklist antes de habilitar ações externas autônomas:

• Identidade: Toda leitura e alteração fica restrita ao usuário autenticado e à conta empresarial autorizada. O modelo não pode escolher uma identidade com mais privilégios.
• Dados: Busque apenas os registros e campos necessários para a tarefa. Mantenha segredos fora do conteúdo visível ao modelo e preserve a origem dos textos de e-mails, documentos e CRM.
• Ferramentas: Ler, criar rascunhos, enviar, exportar e editar exigem permissões separadas. Remova capacidades de que o fluxo não precisa.
• Liberação: Verifique as respostas e os argumentos das ferramentas antes que saiam da aplicação. Valide destinatários, anexos, destinos e alterações permitidas nos registros.
• Aprovação: Ações de alto impacto exigem revisão da ação exata, com cumprimento garantido pelo código da aplicação. Se a aprovação estiver ausente ou tiver sido alterada, a ação fica pendente.
• Operação: Mantenha um log de ações que respeite a privacidade, defina um responsável pelos alertas, ofereça um mecanismo de pausa e teste o fluxo completo antes de ampliar o acesso.

Para o assistente de vendas de um fundador, um ponto de partida razoável é ler uma conversa selecionada com um potencial cliente e propor um rascunho. Exportar dados em massa, enviar mensagens automaticamente ou atualizar oportunidades em lote devem ser capacidades justificadas separadamente. Defina as permissões a partir do trabalho que você pretende oferecer, em vez de habilitar tudo o que a integração permite fazer.

O playbook para limitar o impacto de falhas em agentes de IA em produção aprofunda a arquitetura de contenção. O raio de impacto, ou blast radius, é a medida de até onde uma falha pode se espalhar pelos sistemas conectados.

Testes de prompt injection: verifique os efeitos, além da resposta

Um teste passa quando o resultado proibido não acontece. Um assistente pode exibir uma recusa depois que uma chamada de ferramenta já alterou um registro. Inspecione o serviço de ferramentas e o estado resultante, além do histórico da conversa.

Use contatos sintéticos, caixas de e-mail de teste e um ambiente controlado para ensaiar o lançamento. O roteiro abaixo é um plano de testes da aplicação, não uma coleção de instruções de ataque.

1. 1

   Estabeleça o funcionamento autorizado de referência

   Execute uma tarefa comum de resumo de um potencial cliente. Confirme que os registros corretos são recuperados, o rascunho é útil e a aprovação é exigida exatamente nos pontos definidos pela política. O trabalho legítimo precisa continuar funcionando.

2. 2

   Teste os dois caminhos de entrada

   Inclua um pedido não autorizado no ponto de entrada do usuário e uma mensagem de terceiros que tente desviar a tarefa. Verifique se os registros sem relação com ela continuam inacessíveis e se as operações proibidas nas ferramentas são negadas.

3. 3

   Coloque à prova a aprovação e o tratamento de falhas

   Teste mudanças nos detalhes da ação depois da aprovação, uma revisão recusada, um serviço de políticas indisponível e uma nova tentativa de execução. Confirme que a aplicação mantém a ação pendente ou a rejeita e evita efeitos duplicados.

4. 4

   Inspecione as evidências e os alertas

   Verifique o estado final do CRM, as mensagens enviadas, os destinos das tentativas, o registro de aprovação e o log de políticas. Confirme que quem opera consegue identificar a fonte e interromper o fluxo sem depender da explicação do modelo.

Repita os testes relevantes quando houver mudanças nos prompts, modelos, mecanismos de recuperação, ferramentas ou permissões. Um resultado vale para a configuração testada; não certifica todas as versões futuras.

Registre o suficiente para reconstruir a decisão sem transformar a trilha de auditoria em outra cópia da caixa de entrada inteira. Prefira referências estáveis dos registros, detalhes necessários da ação, versões das políticas e evidências com controle de acesso. Defina um responsável por investigar destinos bloqueados, exportações inesperadas e falhas repetidas de aprovação.

O que é exagero e o que continua sem solução?

Nenhum modelo, prompt, filtro ou produto de guardrails deve ser tratado como uma solução completa. O OWASP afirma explicitamente que a geração aumentada por recuperação e o fine-tuning não mitigam totalmente o prompt injection. A geração aumentada por recuperação, ou RAG, fornece documentos para ajudar o modelo a responder; ela não dá a esses documentos autoridade para mudar a tarefa.

Um prompt de sistema mais robusto pode melhorar o comportamento. Ele não consegue restringir uma credencial com permissões amplas. Um classificador pode sinalizar conteúdo suspeito. Ele não consegue decidir se determinado funcionário pode compartilhar determinado anexo. Um segundo modelo revisando o primeiro acrescenta uma verificação, mas ainda depende de uma política independente da aplicação.

Também não existe uma taxa universal de detecção que indique se o seu agente de e-mail está pronto. Os limites úteis dependem do fluxo: quais contas ele pode ler, quais campos pode alterar, para onde os dados podem ir e quais ações exigem revisão. O resultado de um fornecedor em outra tarefa não prova que o seu fluxo de aprovação seja impossível de contornar.

A afirmação que se sustenta é mais restrita e mais útil: controles em camadas reduzem a exposição e limitam as consequências, enquanto testes e monitoramento revelam falhas. Ainda há risco residual.

Aja agora se um agente já lê conteúdo externo e pode divulgar informações privadas ou alterar o estado do negócio. Espere para ampliar a autonomia até que as permissões, a aprovação e o tratamento de falhas sejam efetivamente impostos. Um resumidor de documentos públicos sem acesso a dados privados nem a ferramentas de ação tem consequências potenciais mais limitadas, mas ainda precisa de proteção contra respostas manipuladas.

Perguntas frequentes

Como se proteger de ataques de prompt injection?

Limite o acesso a dados e ferramentas, separe conteúdo não confiável de instruções, valide saídas e ações, exija revisão para operações de alto impacto e monitore os resultados. Faça as permissões valerem fora do modelo; nenhuma camada isolada elimina o risco.

Qual é um exemplo de prompt?

“Resuma o e-mail deste potencial cliente e prepare um rascunho de resposta para revisão” é um prompt comum. O e-mail do potencial cliente é material da tarefa, não uma autorização para mudar o pedido.

A injeção de SQL ainda é usada?

Sim. A injeção de SQL continua relevante para aplicações que montam consultas inseguras ao banco de dados. Ela exige defesas específicas para bancos de dados, além de eventuais controles de prompt injection; veja as orientações do OWASP sobre prevenção de injeção.

O que é injeção em programação?

Em segurança, injeção ocorre quando uma entrada não confiável altera o que um interpretador executa ou processa. O prompt injection tem como alvo o comportamento de um modelo; outras falhas de injeção atingem consultas a bancos de dados, comandos ou código no navegador.

O que é injeção, em termos simples?

É uma entrada que ultrapassa um limite e passa a ser tratada como uma instrução que nunca teve autorização para dar.

Quais são os tipos de injeção de código?

Alguns exemplos são a injeção de SQL, de comandos do sistema operacional e de scripts. As defesas dependem do interpretador envolvido. O prompt injection tem em comum o problema dos limites de confiança, mas não é sinônimo de toda injeção de código.

Quais são os tipos de prompt injection?

A principal distinção no caminho de entrada é entre direto e indireto: o ataque chega pela entrada do usuário ou pelo conteúdo recuperado pela aplicação. Textos em imagens e outras mídias também podem carregar instruções; o caminho de entrada e o formato da mídia são dimensões diferentes.

Quais são os 7 principais tipos de hackers?

Classificações de hackers não servem como política de permissões para um agente. Baseie os controles em quem está autenticado, quem pode influenciar o conteúdo e o que a aplicação pode acessar ou alterar.

O que são DDoS e injeção de SQL?

DDoS significa negação de serviço distribuída, um ataque à disponibilidade que usa fontes distribuídas. A injeção de SQL manipula consultas a bancos de dados. São problemas distintos do prompt injection; as orientações do OWASP sobre negação de serviço tratam das defesas de disponibilidade.

O que colocar em prática na segunda-feira

Escolha um fluxo de e-mail ou CRM em uso e liste os dados, as ferramentas e os destinos externos que ele consegue alcançar. Remova acessos desnecessários, faça as ações com consequências aguardarem a aprovação da ação exata e demonstre que uma proposta rejeitada não produz efeito externo. Só amplie a autonomia depois que tanto a tarefa útil quanto os caminhos de recusa estiverem funcionando.

Receba guias práticos para criar fluxos de trabalho com IA na newsletter.