Injeção indireta de instruções: como impedir que um documento, e-mail ou página web transforme um assistente conectado em um canal de vazamento ou ação indevida

A ameaça: dados que tentam se comportar como ordens

Uma injeção indireta de instruções surge quando um assistente incorpora conteúdo de uma fonte que não controla — por exemplo, um e-mail, um PDF, uma página web, um ticket ou o resultado de uma ferramenta — e esse conteúdo tenta modificar seu comportamento. O texto hostil pode pedir que o assistente ignore restrições, busque segredos, encaminhe informações, mude o destinatário de uma ação ou use uma ferramenta diferente da necessária. O vetor é indireto porque quem ataca não precisa escrever na caixa de conversa: basta conseguir que o sistema leia o recurso manipulado.

Isso não é o mesmo que uma alucinação. Uma alucinação é uma resposta incorreta ou sem fundamento; a injeção tenta fazer com que o sistema siga uma instrução que não deveria ter autoridade. Tampouco equivale a um pedido mal redigido por um usuário legítimo. A questão central é a procedência e o privilégio: quem pode definir o objetivo da tarefa, autorizar uma capacidade e determinar quais informações podem sair do ambiente.

O risco aumenta quando o assistente combina recuperação documental, navegação, e-mail e ferramentas com efeitos externos. Um assistente estritamente informativo pode produzir uma resposta desviada; um assistente conectado também pode enviar uma mensagem, consultar dados fora do escopo previsto, modificar um registro ou transmitir informações a um destino não autorizado. A publicação do NIST inclui a injeção indireta entre os ataques de injeção e descreve cenários de sequestro de agentes, vazamento de dados e conteúdo malicioso em recursos como documentos ou sistemas de recuperação.

A defesa não deve se basear em detectar uma lista de frases suspeitas. Um atacante pode reformular, fragmentar, ocultar ou ofuscar instruções. Mais importante: mesmo uma detecção perfeita de certos padrões não resolveria o problema de projeto. Nenhum conteúdo não confiável deveria poder adquirir autoridade para alterar o objetivo, ampliar permissões, escolher um destino externo ou modificar uma política de divulgação.

Mapa de fronteiras: separe controle, dados, capacidades e efeitos

Antes de selecionar um modelo ou um filtro, desenhe o percurso completo de uma tarefa. Diferencie as instruções de controle definidas pela organização, a solicitação explícita do usuário, os dados fornecidos por ele, o conteúdo obtido de fontes internas ou externas, as descrições de ferramentas, os segredos e as ações que produzem efeitos. Essas categorias podem estar presentes na mesma conversa, mas não devem ser confundidas na decisão sobre o que o sistema pode fazer.

As instruções de controle incluem a política de segurança, a finalidade do fluxo, os requisitos de autorização e as restrições de saída. O pedido do usuário pode detalhar uma tarefa dentro desses limites. Documentos, e-mails, páginas e resultados de ferramentas são evidências ou contexto: podem influenciar uma resposta factual, mas não decidir que o sistema deve exportar dados, modificar permissões ou entrar em contato com alguém. Uma separação conceitual explícita ajuda o projeto, os registros e os testes a aplicarem regras diferentes a cada elemento.

Também é aconselhável separar o plano da execução. O modelo pode propor uma ação, mas um componente de política independente deve verificar se a ferramenta é permitida, qual identidade será usada, quais argumentos são válidos, para qual destino a operação se dirige e se é necessária uma revisão humana. Tratar uma chamada de ferramenta como uma sugestão verificável, em vez de uma ordem executável, reduz a dependência de que o modelo interprete corretamente a hierarquia em todos os casos.

Essa fronteira é especialmente relevante para os resultados das ferramentas. Uma busca, uma API de tickets ou uma caixa de e-mail podem devolver texto controlado por terceiros. Se o assistente reinserir esse texto como se fosse uma ordem de alto nível, o resultado da ferramenta se tornará uma via de escalonamento. O trabalho sobre hierarquia de instruções analisa justamente a ausência de privilégios entre instruções como uma causa de ataques de injeção.

Inventário de superfícies e relações de confiança

O inventário deve abranger toda entrada que possa chegar ao contexto durante uma tarefa, não apenas a base documental principal. Inclua anexos, corpos e assinaturas de e-mail, convites de calendário, comentários, tickets, transcrições, resultados de busca, páginas navegadas, repositórios, bases vetoriais, memórias conversacionais e texto retornado por conectores. Registre também se o conteúdo vem de um usuário, de um sistema interno, de um terceiro, de uma fonte pública ou de uma origem desconhecida.

A procedência não transforma automaticamente uma fonte interna em fonte confiável para fornecer instruções. Um ticket interno pode conter texto inserido por um cliente; uma wiki pode ser editada por muitas pessoas; uma memória pode ter preservado uma instrução maliciosa de uma sessão anterior. A etiqueta deve refletir tanto o sistema de origem quanto o nível de controle editorial, o proprietário, a data de recuperação e o método pelo qual foi incorporada ao contexto.

Torne visível o trânsito de dados entre zonas. Por exemplo, um agente de e-mail pode ler uma mensagem externa, usar um índice interno para contextualizá-la e propor uma resposta por meio de um serviço de envio. Nesse percurso há pelo menos três decisões diferentes: qual texto é mostrado ao modelo, quais dados internos são consultados e quais informações são enviadas para fora. Cada decisão precisa de restrições próprias; uma etapa não deve herdar a permissão de outra apenas porque ambas compartilham uma conversa.

A documentação da Microsoft trata e-mails, documentos, páginas web e complementos como vias de injeção indireta e propõe controles de fluxo de informações para distinguir conteúdo e confiança. Essa é uma orientação útil, mas sua adaptação concreta depende das identidades disponíveis, dos conectores implantados e da sensibilidade dos dados em cada organização.

Regra de arquitetura: os dados não concedem capacidades

Uma política operacional pode ser formulada de modo simples: um fragmento não confiável pode ser citado, resumido, comparado ou usado como evidência, mas não pode redefinir o objetivo autorizado nem ativar uma capacidade por conta própria. Isso exige que as decisões sobre ferramentas se baseiem em uma combinação da intenção autenticada do usuário, da política do fluxo e das permissões da identidade que executa a ação. O conteúdo recuperado só pode fornecer parâmetros quando eles passarem por uma validação independente.

Aplique o princípio do menor privilégio por tarefa. Um assistente que resume documentos não precisa de credenciais para enviar e-mails. Um rascunho de resposta não precisa de permissão para enviá-la. Uma ferramenta que consulta um registro não deveria reutilizar uma credencial com capacidade de modificá-lo. Sempre que a plataforma permitir, use tokens de curta duração, com escopo limitado a uma operação e emitidos depois da verificação da política. A separação de credenciais reduz as consequências caso o modelo proponha uma ação inadequada.

Restrinja também a exposição de dados. Recupere somente os fragmentos necessários, limite a quantidade de contexto e remova campos sensíveis que não contribuam para a tarefa. Se uma consulta exigir dados internos e uma resposta posterior for destinada ao exterior da organização, introduza uma barreira de saída que avalie a classificação da informação, o domínio de destino, a finalidade declarada e a autorização aplicável. Não permita que um documento sugira o domínio ou a caixa postal para a qual os dados devem ser enviados.

Listas de destinos autorizados podem ser apropriadas para integrações de alto risco, embora exijam manutenção e não substituam a verificação do conteúdo. Em fluxos variáveis, uma política de destino pode combinar relações organizacionais verificadas, regras de classificação e confirmação humana. O objetivo é que o destinatário seja derivado de uma fonte de autoridade — por exemplo, um cadastro de clientes ou uma seleção explícita do usuário — e não de uma frase inserida em um anexo.

Controles por camada e limites dos controles aparentes

A etiquetagem de procedência deve acompanhar o conteúdo até a geração e a execução. Não basta adicionar um aviso textual ao contexto, porque esse aviso pode se perder em transformações posteriores. Use estruturas de dados que preservem origem, confiança, classificação e relação com a tarefa. Ao mesmo tempo, delimite quais campos dessas estruturas o modelo pode ler e quais campos são usados exclusivamente pelo mecanismo de políticas.

A validação de chamadas de ferramentas requer regras semânticas e estruturais. Verifique se a ferramenta é permitida para a tarefa, se seus argumentos atendem a um esquema, se os identificadores são resolvidos em registros autorizados e se o efeito solicitado corresponde ao plano aprovado. Para operações de escrita, valide pré-condições e aplique idempotência quando possível. Para ações irreversíveis ou de grande alcance, exiba uma pré-visualização antes da execução.

A aprovação humana só é eficaz quando a pessoa consegue decidir com informações suficientes. A interface deveria mostrar a ação proposta, o destino final resolvido, os dados que sairão, a fonte dos parâmetros relevantes, o efeito esperado e se ele pode ser revertido. Uma aprovação que apresenta apenas um botão genérico de confirmação pode transferir o risco à pessoa sem lhe dar uma capacidade real de detectar a manipulação.

Pedir ao modelo que ignore instruções presentes em documentos pode fazer parte de uma defesa em profundidade, mas não é uma fronteira de segurança. Um único prompt de sistema, o bloqueio de palavras ou a confiança de que o RAG recuperará fontes reputadas também não são suficientes. A OWASP alerta que RAG e ajuste fino não eliminam por si só o risco de injeção; suas recomendações incluem separação entre instruções e dados, menor privilégio, validação de ferramentas, supervisão e testes. Esses controles reduzem o risco, mas não permitem prometer uma detecção completa de conteúdo hostil.

Projete uma bateria de testes adversariais, não apenas testes de qualidade

Os testes devem demonstrar propriedades observáveis: que um documento não pode ampliar o escopo dos dados; que um e-mail não pode mudar um destinatário; que uma página não pode iniciar uma chamada de ferramenta injustificada; e que uma instrução em resultados de uma API não pode persistir como preferência ou memória. Defina cada caso com uma solicitação legítima, uma entrada adversarial, as capacidades disponíveis, o comportamento esperado e os eventos que devem permanecer registrados.

Cobrir variantes é mais importante do que repetir literalmente o mesmo ataque. Inclua instruções diretas, fragmentadas, codificadas, ocultas em metadados quando seu extrator os processar, formuladas como traduções ou resumos e distribuídas entre várias fontes. Teste também conflitos: um documento pode pedir uma ação enquanto outro a contradiz, ou um resultado de busca pode tentar fazer o modelo esquecer a finalidade inicial. O critério não é que o sistema classifique todo texto malicioso, mas que preserve as proibições de capacidade mesmo quando o texto é interpretado.

Meça separadamente a detecção, o bloqueio e a contenção. A detecção identifica conteúdo suspeito; o bloqueio impede uma ação não autorizada; a contenção limita dados e privilégios se a detecção falhar. Registre bloqueios falsos que interrompam tarefas legítimas, pois uma política excessivamente ampla pode levar usuários a procurar canais alternativos. Revise os testes a cada mudança de modelo, conector, modelo de orquestração, permissão ou ferramenta.

O conjunto de dados LLMail-Inject estuda tentativas adaptativas contra um assistente de e-mail com ferramentas. Ele pode servir como referência para estruturar avaliações de fluxos de e-mail, mas não demonstra, por si só, a resistência de outra arquitetura, outro modelo ou um ambiente com permissões diferentes. Complemente qualquer corpus externo com cenários derivados de seus conectores, dados e operações reais.

Observabilidade e resposta a incidentes

Um registro útil permite reconstruir o fluxo sem conservar mais conteúdo sensível do que o necessário. Ele deve relacionar a solicitação autenticada, a versão da política, os identificadores e as etiquetas dos fragmentos recuperados, o plano proposto, as ferramentas candidatas, os argumentos normalizados, as decisões de autorização, as aprovações e o resultado. Conforme a sensibilidade, armazene impressões digitais, referências controladas ou cópias criptografadas com acesso restrito, em vez de replicar livremente documentos completos.

Defina sinais de alerta: desvio entre o objetivo inicial e uma ação proposta, solicitação de ferramentas indisponíveis para a tarefa, mudança de destinatário, tentativa de acessar campos não recuperados, cadeias incomuns de ferramentas e saídas para novos destinos. Os sinais não substituem a política preventiva, mas ajudam a priorizar a revisão e a descobrir caminhos não previstos. O monitoramento de desvios de plano e de cadeias de ferramentas está alinhado à abordagem de defesa descrita pela Microsoft.

Diante de um incidente, primeiro contenha o fluxo: desative temporariamente a ferramenta ou o conector afetado, revogue tokens ou sessões quando aplicável e preserve os registros. Depois, determine o escopo: qual conteúdo foi lido, quais ferramentas foram propostas e executadas, quais dados saíram, sob qual identidade e para quais destinos. A investigação deve diferenciar uma proposta bloqueada de uma ação efetivamente concluída.

A recuperação inclui corrigir a regra que permitiu o trânsito, revisar privilégios e adicionar uma regressão que reproduza o caso. Se houver saída de dados, acione os processos de resposta e notificação que correspondam à classificação e à jurisdição aplicáveis. Não atribua automaticamente um vazamento à injeção indireta: confirme a cadeia causal com rastros, pois erros de configuração, permissões excessivas ou automações independentes podem produzir efeitos semelhantes.

Matriz de decisão por caso de uso e critérios de implantação

A mesma política geral assume formas diferentes conforme o caso de uso. Um assistente documental exige forte separação entre evidências e instruções, mas talvez não tenha efeitos externos. Um agente de e-mail adiciona risco de destinatários e anexos. Um navegador com ferramentas incorpora conteúdo mutável de múltiplas origens. Uma automação interna pode operar sobre sistemas críticos mesmo quando suas fontes parecem internas. Ajuste os controles ao impacto das ações, e não apenas à probabilidade de encontrar texto hostil.

Antes de abrir um fluxo para usuários, exija provas registradas de que o conteúdo não confiável não altera objetivo, permissões, destinatários nem ferramentas permitidas. Verifique também que a identidade de execução tem os privilégios mínimos e que operações de alto impacto possuem uma pré-visualização ou uma barreira de aprovação. Se não for possível demonstrar essas propriedades, limite o fluxo à leitura, reduza os conectores ou mantenha a ação manual.

Este guia complementa o guia de RAG com fontes e o guia de agentes com ferramentas do índice de segurança. O primeiro ajuda a avaliar as evidências que sustentam uma resposta; o segundo trata permissões e recuperação de forma ampla. Aqui, a pergunta específica é outra: mesmo que o assistente tenha recuperado conteúdo pertinente e disponha de uma ferramenta permitida, qual mecanismo impede que esse conteúdo se transforme em autoridade para ordenar uma ação?

Não existe uma garantia geral de que um modelo reconhecerá toda injeção indireta. Por isso, o limiar razoável não é afirmar invulnerabilidade, mas demonstrar defesas em camadas, limitar o dano caso a detecção falhe e manter testes de regressão para os fluxos realmente implantados.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.