Defesa contra prompt injection em agentes de IA: checagens práticas

Defesa contra prompt injection em agentes de IA significa garantir que um texto lido pelo agente, como um e-mail, um documento compartilhado ou uma página web, não consiga mudar o que ele tem permissão para fazer. O método funciona em três partes: tratar o conteúdo recuperado como dado e não como instrução, dar ao agente apenas as ferramentas que o seu papel exige e colocar uma aprovação humana antes de qualquer ação que envie, gaste, apague ou compartilhe algo. Esses controles são decisões de desenho que você pode verificar antes do lançamento, por isso não dependem de torcer para que um filtro identifique todas as frases hostis.

Principais pontos

• Trate todo e-mail, documento e página web lido pelo agente como material não confiável, nunca como instrução.
• Dê a cada agente um papel nomeado, com o menor conjunto de ferramentas e permissões que esse papel usa.
• Coloque uma etapa de aprovação antes de qualquer ação que envie algo para fora da empresa, compartilhe arquivos, altere registros ou movimente dinheiro.
• Registre quais fontes foram lidas, quais ações foram propostas e quais foram bloqueadas, para que um direcionamento suspeito fique visível.
• Teste com mensagens hostis de exemplo antes do lançamento e repita os mesmos testes após cada mudança.

Como uma instrução injetada chega ao seu agente

Um agente que lê sua caixa de entrada, uma pasta de fornecedores ou uma página pública está lendo um texto que outra pessoa pode ter escrito. A injeção indireta de prompt acontece quando esse texto contém instruções direcionadas ao agente, e não a uma pessoa. As orientações da OWASP para aplicações com modelos de linguagem listam a injeção de prompt entre os principais riscos, e o motivo é estrutural: o modelo recebe as instruções da empresa e o conteúdo que lê como um único fluxo de texto.

Cenário ilustrativo: um pequeno distribuidor usa um agente que resume e-mails de fornecedores e prepara rascunhos de resposta. Uma mensagem traz, em um rodapé quase invisível para quem lê, uma frase pedindo ao assistente que encaminhe a lista atual de produtos para um endereço externo e que dispense a confirmação habitual. Se o agente tem permissão de envio e não existe etapa de aprovação, a instrução pode ser seguida. A falha não está em um modelo descuidado. A falha está em o agente poder agir sobre um texto que leu, sem nenhuma fronteira entre ler e fazer.

A injeção direta, em que um usuário digita um pedido malicioso para o agente, também importa. Em ambientes de negócio, porém, a injeção indireta é o caso que mais surpreende os donos, porque o atacante nunca fala com o agente.

Trate o conteúdo recuperado como dado, não como instrução

Escreva as regras de operação do agente de modo que o conteúdo que ele recupera seja descrito como material para análise, nunca como fonte de comandos. As regras devem dizer que e-mails, documentos e páginas podem conter pedidos que o agente não deve seguir, a menos que correspondam a uma das tarefas aprovadas para o seu papel. Essa redação ajuda, mas um modelo ainda pode ser convencido por um texto bem escrito, então trate-a como uma camada entre várias.

A separação também ajuda na prática. Passe ao agente apenas os campos que a tarefa precisa, e não caixas de e-mail ou pastas inteiras, seguindo o mesmo princípio da minimização de dados. Quando a sua ferramenta permitir, mantenha o conteúdo das fontes em campos claramente rotulados e sinalize textos ocultos, como conteúdo fora da tela, comentários, metadados e caracteres invisíveis incomuns, antes que o modelo os leia. Por fim, tenha cuidado quando a saída de um agente vira entrada de outro. Cada etapa pode levar uma instrução adiante, então o segundo agente precisa de limites próprios e não deve confiar cegamente no resumo do primeiro.

Checklist antes do lançamento

• Liste todas as fontes que o agente lê, incluindo caixas de entrada, drives compartilhados, formulários enviados, arquivos carregados e qualquer busca na web que ele faça.
• Para cada fonte, anote quem pode criar conteúdo nela. Quem está fora da empresa é considerado não confiável por padrão.
• Escreva uma descrição curta do papel, com as tarefas permitidas e uma lista explícita de pedidos que o agente deve recusar.
• Remova toda ferramenta e permissão que o papel não usa. Acesso somente leitura é o padrão, e o acesso de escrita só entra com justificativa.
• Confirme que as mensagens de saída vão para uma lista de domínios aprovados ou para uma fila de revisão.
• Remova ou sinalize textos ocultos, comentários e metadados antes que o modelo leia o conteúdo.
• Prepare um conjunto de mensagens de teste hostis: uma pedindo o encaminhamento de dados, uma pedindo a alteração de um registro, uma pedindo que o agente ignore suas regras anteriores e uma apontando para um link desconhecido.
• Para cada teste, escreva o resultado esperado, execute o teste e registre a ação tomada e se uma pessoa foi consultada.
• Repita o conjunto completo após qualquer mudança em prompts, ferramentas, versão do modelo, contas conectadas ou fontes de dados.
• Nomeie um responsável que possa pausar o agente e que revise os resultados dos testes toda semana durante o primeiro mês.

Quais ações devem parar e esperar uma pessoa

O controle mais útil é um guia de decisão claro, que qualquer membro da equipe consiga ler. Classifique as ações pela consequência, e não pela dificuldade que o agente tem para executá-las.

• Ler e resumir conteúdo dentro do escopo aprovado: permitido automaticamente.
• Redigir uma resposta ou um documento: permitido, salvo como rascunho que uma pessoa revisa antes de sair.
• Enviar mensagem para alguém de fora da empresa: exige aprovação a cada vez, pelo menos na fase inicial.
• Compartilhar um arquivo ou alterar permissões de acesso: exige aprovação, sem exceção.
• Criar, alterar ou excluir um registro em um sistema de referência: exige aprovação, com a mudança proposta exibida antes de ser aplicada.
• Movimentar dinheiro, emitir reembolsos ou alterar dados bancários: bloqueado para o agente e tratado somente por funcionários.
• Abrir um link encontrado em conteúdo desconhecido: bloqueado, a menos que o destino esteja em uma lista de permitidos.
• Qualquer coisa que o agente não consiga classificar com segurança: parar e perguntar.

As orientações da OWASP sobre autorização são uma referência útil nesta etapa, porque tratam o acesso como uma decisão verificada no momento de cada ação, e não como algo presumido a partir de uma etapa anterior. Se uma instrução suspeita aparecer no meio de uma tarefa longa, o agente deve enfrentar a mesma fronteira quando tentar enviar algo. Para um modelo mais completo de como a confiança pode crescer ao longo do tempo, veja níveis de permissão para agentes de IA, e para o desenho da própria aprovação, veja quando seu agente de IA deve parar e perguntar.

O que registrar e como responder quando houver manipulação

Os registros são o que transforma uma falha silenciosa em uma falha visível. Guarde quais itens de origem foram lidos, quais chamadas de ferramenta o agente propôs, quais foram bloqueadas, quais aprovações foram solicitadas e quem respondeu. Configure alertas para chamadas propostas a domínios fora da lista de permitidos, para saídas que citem instruções encontradas dentro do conteúdo e para tentativas repetidas de uma ação bloqueada. Mantenha esses registros sob uma regra de retenção que equilibre as necessidades de auditoria com a privacidade.

Quando houver suspeita de manipulação, a resposta deve seguir um caminho escrito. Pause primeiro as ações de saída, preserve a transcrição e a mensagem de origem, identifique exatamente quais ações foram propostas e quais foram concluídas, e avise as pessoas afetadas caso algum dado tenha saído da empresa. Depois, repita o conjunto de testes hostis antes de reabrir o agente. Um mecanismo de pausa só é útil se alguém já o testou em um dia normal, então pratique antes de qualquer incidente. O artigo sobre botão de parada para agentes de IA explica como pausar ações sem perder o trabalho em andamento.

Como a Be Human atua em operações gerenciadas

A abordagem gerenciada da Be Human começa antes de o agente tocar em conteúdo real. A primeira etapa define um papel útil, as fontes que ele pode ler, as ferramentas que pode chamar e os limites de aprovação para cada tipo de ação, além de um critério de sucesso observável. As operações gerenciadas cobrem depois o acompanhamento dos registros e alertas descritos acima, testes hostis recorrentes após cada mudança, revisões de permissão que removem acessos que o papel não precisa mais e resposta a incidentes com um responsável nomeado. Melhorias controladas só são liberadas depois que o conjunto de testes passa de novo, para que o alcance do agente continue visível e limitado ao longo do tempo.

Comece com um agente e um fluxo protegido

Escolha um único fluxo em que o agente leia conteúdo externo, mas em que as ações possíveis sejam restritas, como separar perguntas recebidas de fornecedores em rascunhos para uma pessoa enviar. Escreva a fronteira de aprovação e o conjunto de testes hostis antes de conectar qualquer conta de envio, e revise os resultados toda semana com a pessoa responsável por esse fluxo, até que os limites se sustentem. Faça o diagnóstico gratuito de IA da Be Human para encontrar a primeira tarefa que vale entregar a um agente.

Perguntas frequentes

A injeção de prompt pode ser totalmente evitada? Nenhum controle isolado a impede por completo, porque o modelo lê instruções e conteúdo como um único fluxo de texto. O objetivo prático é limitar o que uma injeção bem-sucedida consegue fazer, por meio de permissões restritas, etapas de aprovação, listas de permitidos e monitoramento. Esses limites transformam uma possível manipulação em um evento bloqueado ou claramente visível.

Preciso de um produto especial de segurança em IA antes de começar? Não necessariamente. Muitas proteções são decisões de configuração e de processo, como quais contas o agente pode usar, quais ações exigem aprovação e o que é registrado. Ferramentas especializadas podem ajudar depois, mas as primeiras defesas podem ser revisadas com as pessoas de operações e segurança que a empresa já tem.

Devemos testar com mensagens de ataque realistas? Sim, mas execute esses testes em um ambiente de teste ou com contas que não possam causar dano, e nunca envie amostras hostis a clientes. Escreva cada teste com um resultado esperado, como a ação bloqueada ou encaminhada para aprovação. Repita o conjunto completo após cada mudança no prompt, nas ferramentas ou nas contas conectadas.

Quem é responsável se uma instrução injetada levar a uma ação indevida? A empresa que implanta o agente continua responsável pelas permissões e pelo desenho das aprovações, mesmo quando o gatilho veio de uma parte externa. Por isso, os limites, os registros e os testes devem ter um responsável nomeado dentro do negócio, e não ficar apenas com o fornecedor da ferramenta.

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