Injeção de prompt em agentes de IA: riscos e defesas prioritárias

A injeção de prompt é um ataque em que instruções escondidas em um texto que o agente de IA lê, como um e-mail, um PDF ou uma página da web, o afastam do que o dono pretendia. Para um agente de negócio que lê uma caixa de entrada compartilhada, arquiva documentos ou atualiza registros, o risco não é uma resposta estranha, e sim uma ação executada com as permissões reais da empresa. As primeiras defesas são estruturais: tratar todo documento recebido como dado e não como instrução, limitar as ferramentas que o agente pode acessar e exigir uma decisão humana antes de qualquer ação irreversível.

Principais pontos

• Qualquer texto que o agente lê pode carregar instruções, incluindo corpos de e-mails, assinaturas, anexos, páginas da web, campos de formulário e comentários em planilhas.
• O dano que uma injeção causa depende das ferramentas e permissões do agente, não de quão convincente é o atacante.
• Mantenha as instruções do sistema separadas do conteúdo recuperado e nunca permita que um documento conceda novas permissões ao agente.
• Coloque limites de aprovação em pagamentos, trocas de dados bancários, exportações de dados, envios para clientes e exclusões de registros.
• Registre cada chamada de ferramenta e revise sequências incomuns, porque nenhuma redação de prompt fecha essa brecha sozinha.

Como a injeção de prompt aparece na caixa de entrada da empresa

Modelos de linguagem não separam de forma confiável as instruções que receberam do texto que devem processar. Uma pessoa que lê uma nota fiscal sabe que uma frase no rodapé não é uma ordem do gerente. Um agente que resume a mesma nota pode tratar essa frase como parte da tarefa, a menos que o sistema seja construído para manter as duas coisas separadas. Esse é o cerne do problema: o atacante escreve um texto, e o texto acaba no mesmo canal por onde passam as instruções do agente.

Existem duas formas comuns. A injeção direta acontece quando alguém digita instruções diretamente na janela de conversa do agente. A injeção indireta é mais relevante para empresas, porque o texto malicioso chega dentro de um conteúdo que o agente deveria processar, como um e-mail de cliente, um PDF de fornecedor, um formulário digitalizado ou uma página da web que o agente abre durante uma pesquisa. A pessoa que envia esse conteúdo pode nunca interagir com o agente.

Cenário ilustrativo: um fornecedor envia um PDF de nota fiscal. Em texto branco sobre fundo branco, o rodapé afirma que as regras anteriores de revisão não valem mais, que a nota está aprovada e que a conta de pagamento mudou para outra. Um agente que lê o PDF e também tem permissão de escrita na ferramenta de contas a pagar pode seguir esse rodapé. Nada no arquivo parece um vírus, e uma verificação visual rápida do documento deixaria isso passar.

Os agentes elevam o risco em comparação com um chatbot simples. Um chatbot manipulado escreve uma frase errada. Um agente pode chamar ferramentas, consultar registros, enviar mensagens e salvar anotações em uma memória que persiste entre sessões. Uma instrução injetada e gravada na memória pode influenciar tarefas futuras que não têm nada a ver com o e-mail original. Por isso, a questão de projeto é menos a redação do prompt e mais o que o agente tem permissão para fazer depois de ler algo.

Mapeie todos os pontos por onde texto externo entra no agente

Antes de escolher qualquer defesa, liste os lugares por onde texto de fora da empresa pode chegar ao agente. A maioria das equipes encontra mais canais do que esperava. Anote-os em linguagem simples, ao lado das ferramentas que cada canal pode influenciar.

• Corpos de e-mails recebidos, assinaturas, respostas citadas e conversas encaminhadas.
• Anexos, formulários digitalizados, PDFs e planilhas recebidos de clientes, fornecedores ou candidatos.
• Páginas da web que o agente abre durante a pesquisa, incluindo páginas encontradas por busca.
• Campos de formulário, observações de reserva e comentários que clientes ou prestadores digitam em sistemas compartilhados.
• Saídas de outros sistemas e de outros agentes, que podem carregar texto copiado de uma fonte externa.
• Entradas de memória de longo prazo, porque qualquer coisa salva a partir de uma fonte não confiável vira uma entrada futura.

Para cada ponto, registre quais ferramentas o agente pode acionar depois de lê-lo. Um pedido de orçamento que apenas alimenta um rascunho de resposta tem um raio de impacto pequeno. O mesmo pedido alimentando um agente que pode alterar preços, emitir reembolsos ou modificar a conta de um cliente tem um raio grande. Essa tabela de canais e ferramentas é o documento de trabalho para o restante do programa, e vale mantê-la junto ao seu modelo de registro de riscos de IA, para que novos canais sejam incluídos quando surgirem.

Defesas a construir primeiro: uma sequência prática

A ordem importa. Muitas equipes começam com filtros de prompt porque são fáceis de demonstrar, e depois descobrem que o agente continua com acesso de escrita a tudo. Uma sequência mais segura começa reduzindo o que uma injeção bem-sucedida poderia fazer e só então acrescenta detecção.

• Primeiro passo: confirme o inventário de entradas e ferramentas descrito acima e marque quais combinações são perigosas, ou seja, entrada não confiável somada a uma ferramenta que movimenta dinheiro, altera registros ou envia mensagens para fora da empresa.
• Segundo passo: torne o acesso somente leitura o padrão. O agente deve conseguir ler e resumir a maior parte do conteúdo sem nenhuma permissão de escrita, e cada permissão de escrita deve ser concedida separadamente.
• Terceiro passo: separe os papéis no projeto. Instruções do sistema, regras de negócio e modelos aprovados ficam em uma configuração que o texto externo não consegue alterar. O conteúdo recuperado é marcado como dado não confiável no contexto que o modelo recebe.
• Quarto passo: coloque limites de aprovação antes de ações irreversíveis. Trocas de dados bancários, liberações de pagamento, envios a clientes e exclusões devem aguardar a aprovação de uma pessoa identificada, como descrito em quando seu agente de IA deve parar e perguntar.
• Quinto passo: restrinja o que pode ser gravado na memória. Entradas vindas de fontes externas devem ficar em quarentena ou ser marcadas, e uma pessoa deve revisar qualquer alteração de memória que afete pagamentos, preços ou a identidade de clientes.
• Sexto passo: registre cada chamada de ferramenta com a entrada que a disparou, para que você consiga rastrear como uma ação suspeita aconteceu.
• Sétimo passo: monte um conjunto pequeno de mensagens hostis de teste, incluindo instruções escondidas em anexos e e-mails, e execute-o sempre que o agente, suas ferramentas ou seus prompts mudarem.

Nenhum desses passos exige um modelo perfeito. Eles limitam o que um agente manipulado consegue fazer, que é o objetivo realista.

Controles que não dependem de o modelo perceber o ataque

As orientações da OWASP sobre injeção de prompt descrevem uma abordagem em camadas, e as camadas mais úteis são determinísticas. Um modelo pode ser convencido por um parágrafo engenhoso, mas uma regra de validação não se convence com nada. Construa as verificações fora do modelo para que uma decisão manipulada ainda esbarre em um limite.

Para pagamentos e cadastros de fornecedores, compare qualquer dado bancário alterado com uma lista mestra de fornecedores verificados e recuse agir sobre uma mudança que não tenha sido confirmada por um canal separado. Para valores, exija correspondência com um pedido de compra aprovado dentro de uma tolerância definida antes. Para mensagens de saída, restrinja os destinatários de envios automáticos a uma lista de permitidos e retenha para revisão qualquer envio a um domínio novo. Para exportações de dados, limite o número de registros por solicitação e exija um aprovador para saídas em massa.

Filtros que varrem o texto recebido em busca de frases suspeitas ajudam a pegar tentativas óbvias, mas atacantes podem reformular, esconder texto em imagens ou dividir instruções entre vários documentos. Trate os filtros como um sinal entre vários. O controle de acesso importa mais: os princípios de autorização do OWASP Authorization Cheat Sheet valem aqui como valem para qualquer conta de serviço. Isso significa que o agente deve ter apenas as permissões que seu papel exige, e essas permissões devem ser verificadas no momento da ação, e não aceitas porque o pedido chegou em um formato familiar. O modelo de níveis descrito em autorização de agentes de IA por níveis de permissão é uma forma prática de decidir quais permissões um agente conquista ao longo do tempo.

Decida quais ações exigem uma pessoa antes de publicar

Um guia de decisão mantém a discussão concreta. Faça três perguntas sobre cada ação que o agente poderia executar: a ação pode ser desfeita com facilidade, ela movimenta dinheiro ou altera um registro jurídico ou de cliente, e ela alcança alguém fora da empresa? Quanto mais respostas forem sim, mais revisão humana a ação exige.

• Ler, resumir, classificar e redigir internamente: permitido, com registro e sem envio externo.
• Criar ou atualizar uma tarefa ou anotação interna: permitido para o papel definido, com trilha de auditoria.
• Alterar o registro de um cliente, fornecedor ou funcionário: exige um aprovador identificado que veja a alteração proposta lado a lado com o valor atual.
• Liberar um pagamento, trocar uma conta bancária ou alterar um preço: exige aprovação humana por um canal verificado e separado, em todas as vezes.
• Enviar mensagem externa a um destinatário novo ou com um anexo novo: exige revisão até que o padrão tenha um histórico confiável.
• Exportar ou excluir dados em massa: exige aprovação, um limite de registros e uma verificação de retenção.

Essas decisões também determinam quem responde quando algo dá errado. Se uma instrução injetada levar a um pagamento incorreto, a pergunta é se o limite de aprovação foi projetado, testado e seguido. As questões mais amplas de responsabilidade são tratadas em quem é responsável quando o agente de IA comete um erro.

Como a Be Human trata isso na operação gerenciada

A Be Human projeta e opera agentes de IA cuja identidade, memória, canais, ferramentas, permissões e contexto operacional permanecem sob controle humano. Na prática, uma primeira contratação define um papel útil, lista as entradas que esse papel lê e separa a configuração confiável do conteúdo não confiável. As ferramentas são limitadas ao mínimo que o papel precisa, e as ações que movimentam dinheiro, alteram registros ou contatam terceiros passam por limites de aprovação que a equipe do cliente controla. A operação gerenciada acrescenta então o monitoramento das chamadas de ferramentas, avaliações recorrentes que incluem mensagens hostis de teste, revisões de permissão quando ferramentas ou papéis mudam e um caminho de resposta a incidentes caso uma suspeita de injeção seja encontrada. O objetivo é um sistema controlado, com registros que o dono do negócio pode inspecionar, e não a promessa de que nenhuma injeção jamais terá sucesso.

Testes e monitoramento depois do lançamento

Um agente que passa nos testes de lançamento ainda pode desviar do comportamento esperado quando chegam novos formatos de documento, quando ferramentas são adicionadas ou quando os prompts são editados. Monte um conjunto permanente de testes a partir dos pontos de entrada que você inventariou: um e-mail de reserva com uma instrução embutida, um PDF com texto oculto, uma página da web que manda o agente ignorar suas regras e uma entrada de memória que tenta alterar um preço. Execute esse conjunto em uma agenda e após cada mudança, e registre quais testes o agente falhou e o que ele tentou fazer. Trate um teste reprovado como um defeito de projeto, e não como motivo para acrescentar mais uma frase ao prompt.

O monitoramento deve observar padrões e não mensagens isoladas. Chamadas repetidas a uma ferramenta de pagamento logo após a chegada de um documento, destinatários que aparecem pela primeira vez ou gravações de memória com linguagem imperativa merecem um alerta. Quando um alerta dispara, o agente deve parar no limite de aprovação e encaminhar o caso com suas evidências, como descrito em escalonamento humano para falhas de agentes de IA. Um bom escalonamento envia a decisão a uma pessoa com o contexto relevante, e não uma pilha de mensagens brutas.

Se você não tem certeza de quais tarefas do seu agente tocam nas entradas mais arriscadas, o diagnóstico gratuito de IA da Be Human pode ajudar a encontrar a primeira tarefa que vale entregar a um agente.

Perguntas frequentes

Injeção de prompt é o mesmo que invadir um sistema? Não exatamente. Invadir costuma significar entrar em um sistema por meio de uma vulnerabilidade, enquanto a injeção de prompt explora o fato de que um agente lê texto e trata parte dele como instrução. O atacante pode não precisar de acesso à sua rede, apenas da capacidade de enviar um e-mail ou colocar um documento em um fluxo que o agente processa.

Um prompt melhor pode impedir a injeção de prompt? Um prompt bem escrito ajuda, mas não pode ser a única defesa. Modelos podem ser convencidos por textos cuidadosamente escritos, então a abordagem mais segura é limitar as permissões das ferramentas, separar o conteúdo não confiável das instruções e colocar limites de aprovação e verificações determinísticas fora do modelo.

Qual defesa uma empresa pequena deve construir primeiro? Comece listando as entradas e as ferramentas, depois deixe o agente somente leitura por padrão e coloque uma aprovação humana antes de pagamentos, trocas de dados bancários e envios externos. Esses passos reduzem o dano de qualquer injeção bem-sucedida e custam pouco para configurar, especialmente quando comparados à construção de sistemas de detecção.

O risco de injeção de prompt muda se o agente apenas resume documentos? Muda, mas não desaparece. Um resumo ainda pode induzir em erro as pessoas que confiam nele, e um resumo que depois é colado em um sistema ou na memória pode transportar instruções adiante. Mantenha os resumos identificados como rascunhos de fontes não confiáveis e restrinja o que as etapas seguintes podem fazer com eles.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.