Prompt injection não se resolve no prompt — limite o poder do agente

Para proteger um agente de IA contra prompt injection, trate páginas, arquivos, mensagens e respostas de ferramentas como dados sem autoridade para mudar a tarefa. Limite o acesso do agente e faça o código que executa cada ferramenta conferir se a ação proposta foi autorizada pelo usuário.

Instruções no prompt e filtros ajudam a identificar tentativas de desvio, mas não devem decidir sozinhos se um arquivo será apagado ou se dados serão enviados. O guia da OWASP sobre prompt injection orienta comparar chamadas de ferramentas com a intenção original do usuário e aplicar permissões e validação de parâmetros separadamente. Mesmo que o modelo aceite uma ordem maliciosa, o executor ainda pode impedir seu efeito.

Separe a tarefa do conteúdo que o agente lê

Guarde a solicitação original, a identidade do usuário e o escopo autorizado em uma camada da aplicação que o conteúdo recuperado não possa alterar. Ao abrir uma página, um anexo ou a resposta de uma API, registre sua origem e entregue seu conteúdo ao modelo como material de consulta. Uma frase no arquivo que ordena o envio de dados a outro endereço continua sendo parte do arquivo, ainda que pareça uma instrução operacional.

Uma arquitetura de referência distingue entrada externa, interpretação pelo agente, proposta de ação e execução pela ferramenta. Entre a proposta e a execução, um componente independente consulta a tarefa original, a autorização do usuário e a política da ferramenta. Ele confere a operação, o recurso e os parâmetros antes de permitir o efeito externo. Marcar dados como não confiáveis no contexto ajuda o modelo a interpretá-los; a verificação no executor é o controle que pode barrar a ação.

Se a aplicação guarda resumos ou memória para sessões futuras, mantenha a procedência dos trechos recuperados. Defina quais dados podem ser persistidos e isole a memória por usuário e sessão. Assim, uma ordem encontrada em uma página não ganha autoridade apenas porque reapareceu no histórico do agente.

Dê ao agente somente as ferramentas exigidas pela tarefa

Configure o conjunto de ferramentas e as credenciais conforme a tarefa autorizada. Em um exemplo hipotético, resumir contratos exige leitura dos arquivos permitidos, mas não exige acesso para enviar e-mails ou excluir documentos. Quando uma integração oferece leitura e escrita, separe as operações e seus escopos; uma credencial ampla torna inútil a restrição mostrada ao modelo.

O executor deve verificar a permissão em cada chamada, inclusive quando a ferramenta já foi usada antes na mesma sessão. Confira o identificador do arquivo, o destinatário da mensagem, o domínio de uma requisição externa ou o intervalo de registros, conforme a operação. Rejeite ferramentas desconhecidas e argumentos fora do escopo antes de chamar o serviço conectado. A justificativa escrita pelo agente pode explicar sua proposta, mas não amplia a autorização recebida.

Essa separação também limita os dados disponíveis para um desvio. Se uma tarefa requer somente uma pasta, a ferramenta de leitura não precisa alcançar outras pastas; se não requer saída para a internet, a ferramenta de envio pode ficar indisponível. O controle deve valer nas credenciais e no serviço de execução, além da lista de ferramentas apresentada ao modelo.

Vincule a aprovação humana à ação concreta

Ações destrutivas, financeiras, administrativas ou visíveis a terceiros exigem uma pausa antes da execução. O guia da OWASP para agentes de IA orienta vincular a aprovação à identidade de quem autoriza, à ferramenta, ao recurso e aos parâmetros exatos, com prazo de validade e verificação imediatamente antes da execução. Alterar o destinatário ou o arquivo exige uma nova aprovação.

A pessoa responsável precisa ver o efeito proposto: qual recurso será modificado, quais dados sairão do ambiente e qual será o destino. No executor, confira a aprovação e marque seu uso em uma mesma operação, para que uma chamada repetida não reutilize a autorização. Se a consulta à política falhar, a aprovação expirar ou não houver registro confiável da decisão, encerre a tentativa sem executar a ferramenta.

Classificar uma ação como pouco arriscada não equivale a autorizá-la. Mesmo uma leitura precisa respeitar os recursos aos quais o usuário tem acesso. Para operações com impacto maior, a aprovação acrescenta uma condição à permissão já existente; não substitui a conferência de identidade, escopo e parâmetros.

Relacione cada risco ao controle e ao sinal de falha

Os controles abaixo podem virar casos de teste no ponto da arquitetura em que cada efeito seria produzido. Em todos eles, observe a decisão do executor e o estado final da ferramenta, além da resposta escrita pelo agente.

• Ordem escondida em página ou arquivo: registre a origem externa na entrada e mantenha a política de autorização fora desse conteúdo. O teste falha se a leitura ampliar as ferramentas ou o escopo concedido à tarefa.
• Envio a um destinatário indevido: confira permissão, dados e destino no executor antes da saída. O teste falha se dados fictícios chegarem a um endereço que o usuário não autorizou.
• Exclusão ou alteração indevida: restrinja a credencial de escrita e exija aprovação válida para o recurso e os parâmetros propostos. O teste falha se o estado de teste mudar sem essa autorização, mesmo que a resposta final peça desculpas.
• Contaminação de memória: preserve procedência, regras de persistência e isolamento entre sessões. O teste falha se uma instrução inserida como dado em uma tarefa passar a orientar outra tarefa ou outro usuário.

Um filtro pode sinalizar texto suspeito antes que ele chegue ao agente, mas cada controle acima protege uma consequência específica caso a tentativa passe despercebida. Bloquear a frase maliciosa é útil; impedir que uma chamada sem permissão seja executada é verificável no limite da ferramenta.

Teste desvios adaptativos com ações simuladas

Comece por uma tarefa legítima que o agente consiga concluir com dados fictícios. Registre a ação esperada, as ferramentas permitidas e o estado inicial. Depois coloque a instrução maliciosa no canal que o agente realmente consumirá: o corpo de um e-mail, uma página recuperada, um arquivo ou o resultado de uma ferramenta. Enviá-la diretamente como pedido do usuário exercita uma fronteira diferente.

Substitua efeitos reais por ferramentas instrumentadas, como uma caixa de saída simulada, arquivos descartáveis e destinos de teste. Guarde a chamada proposta, os parâmetros, a decisão de autorização e qualquer alteração produzida. Considere falha uma operação proibida que chegou à execução ou uma mudança indevida de estado. Uma recusa na resposta final não desfaz uma chamada já realizada.

O estudo do NIST sobre sequestro de agentes descreve a injeção indireta em dados consumidos pelo sistema e destaca avaliações adaptativas, por tarefa e com múltiplas tentativas. Por isso, depois de bloquear uma versão do ataque, varie sua posição no conteúdo, sua apresentação e os parâmetros solicitados. Separe os resultados por objetivo, como envio ou exclusão, e inclua tarefas benignas para identificar bloqueios indevidos.

Repita esses casos após mudanças no modelo, nas ferramentas, na memória ou na política de autorização. Para cada tentativa, preserve a entrada, a decisão do executor e o efeito observado, sem usar dados reais como isca. Se a instrumentação não permitir determinar se uma ação sensível foi executada, o resultado é inconclusivo: mantenha essa ação bloqueada até que a verificação seja possível.

Leia também:

• OpenAI relata seis desvios — um agente publicou arquivo sem permissão
• Aprender prompt não basta: quatro habilidades para trabalhar com agentes de IA
• Hotmart ou Gumroad: 0,1 ponto não resolve o custo da venda