Um documento recuperado pode sequestrar seu assistente RAG? Um plano de testes para injeção de prompt

Por que os documentos recuperados devem fazer parte do seu modelo de ameaças

Um assistente RAG usa materiais recuperados para ajudar a responder à pergunta de um usuário. Esses materiais também podem conter textos que parecem instruções para o modelo. O Centre for Emerging Technology and Security do The Alan Turing Institute descreve a injeção indireta de prompt como informações maliciosas inseridas nas fontes de dados de um sistema de IA generativa, incluindo instruções ocultas nesses dados. [Leia a visão geral sobre injeção indireta de prompt](https://cetas.turing.ac.uk/publications/indirect-prompt-injection-generative-ais-greatest-security-flaw).

O limite importante é aquele entre as instruções que regem o assistente e o conteúdo que ele recupera para responder a uma pergunta. O plano abaixo é uma recomendação prática, não um procedimento estabelecido pela fonte citada nem uma garantia de proteção. Ele se concentra em resultados observáveis, como o que foi recuperado, o que o assistente divulgou e se houve uma tentativa de ação não autorizada.

• Concentre o teste no conteúdo recuperado e na influência que ele exerce sobre o assistente.
• Inclua documentos aparentemente inofensivos: o teste avalia como o conteúdo é tratado, não apenas se um documento parece suspeito.
• Avalie a aplicação conforme configurada, incluindo as permissões de recuperação e as ferramentas conectadas que estiverem no escopo.

Defina os limites do teste antes de começar

Como ponto de partida, registre o que a aplicação pode recuperar e fazer antes de adicionar documentos de teste. Use um ambiente de homologação isolado ou um índice de teste separado; mantenha os documentos adversariais fora do conjunto de dados ativo. Isso ajuda a distinguir uma resposta do assistente de um problema de permissões de recuperação ou de uma tentativa de ação, sem afetar usuários ou respostas de produção.

Inclua as identidades e os níveis de acesso que pretende testar. Se a aplicação atende a diferentes grupos, registre quais fontes de documentos cada grupo deve poder acessar. Liste as ferramentas conectadas e as ações que podem tentar executar, mantendo desativadas ou simuladas as ações com consequências.

• Isolamento: use um ambiente de homologação ou índice de teste separado. Remova o conjunto de teste após a avaliação.
• Fontes de documentos: liste as coleções, os repositórios ou outras fontes incluídas no teste.
• Identidades de usuário: escolha funções representativas, incluindo uma com acesso mais restrito e outra com acesso mais amplo, caso a aplicação tenha essas distinções.
• Permissões de recuperação: registre quais documentos cada identidade deve conseguir recuperar e quais devem permanecer indisponíveis.
• Ferramentas conectadas: registre quais estão habilitadas, quais ações podem tentar executar e como serão simuladas com segurança.
• Informações confidenciais: identifique as categorias que devem ser protegidas e use apenas valores fictícios, nunca segredos reais, dados pessoais ou registros de produção.

Crie um conjunto de testes pequeno e controlado

Crie documentos especificamente para os testes e armazene-os apenas no ambiente de homologação ou índice separado. Inclua primeiro materiais de referência comuns como linha de base e, em seguida, documentos com instruções deliberadamente conflitantes ou inadequadas. Identifique o conteúdo de teste para que a equipe possa rastrear uma resposta até o material recuperado.

Para cada cenário, registre a função do usuário, a pergunta, o limite de acesso esperado, o documento a recuperar e o comportamento esperado. Não use segredos reais, registros de produção ou ações em sistemas ativos como alvos de teste.

• Linha de base inofensiva: um documento com fatos relevantes e sem instruções dirigidas ao assistente.
• Instrução conflitante: um documento que pede ao assistente para ignorar o comportamento pretendido ou seguir uma instrução diferente.
• Solicitação de informação restrita: coloque em um documento indisponível à função testada um valor fictício claramente identificado. Use instrumentos de teste autorizados para verificar a recuperação sem disponibilizar o valor ao assistente ou ao usuário de teste.
• Verificação entre funções: peça a um usuário com acesso mais restrito que faça uma pergunta sobre um documento destinado a uma função com acesso mais amplo.
• Tentativa de influenciar uma ferramenta: inclua um pedido para iniciar uma ação por meio de uma ferramenta conectada. Use um ambiente isolado, uma simulação ou um fluxo de ação desativado.

Execute os mesmos cenários em diferentes funções e contextos

Execute cada teste com as identidades e os contextos de recuperação incluídos no escopo. Inclua uma pergunta direta sobre o assunto do documento e outra que possa tornar relevante a instrução incorporada. O objetivo é observar o comportamento do assistente nas condições de acesso definidas.

Registre a função do usuário, a pergunta, os identificadores dos documentos de teste, a resposta e qualquer tentativa de acionar uma ferramenta. No cenário de informação restrita, use os instrumentos autorizados para verificar se o documento apareceu na recuperação, sem expor seu valor fictício à função testada. Se o material recuperado não estiver visível na interface normal, consulte os registros ou instrumentos disponíveis sem alterar o comportamento de segurança avaliado.

Repita os cenários importantes: uma execução registra apenas o comportamento observado naquela ocasião e não estabelece como a aplicação se comportará em todas as execuções.

• Use o mesmo caso de teste com cada função de usuário pertinente.
• Verifique se o documento esperado foi recuperado e se apareceram documentos fora do acesso permitido àquela função.
• Registre o que o assistente divulgou, se repetiu as instruções do documento e se tentou acionar uma ferramenta.
• Nos casos relacionados a ferramentas, registre separadamente as ações tentadas e as concluídas; mantenha o fluxo sem consequências.
• Anote a data do teste e as configurações ou alterações relevantes para interpretar o resultado.

Avalie o resultado em relação ao limite de segurança

Avalie o comportamento segundo as regras definidas antes dos testes. Uma resposta com aparência segura não prova como o modelo tratou internamente uma instrução. Em vez disso, observe se o usuário recebeu informações fora do seu nível de acesso, se o valor fictício restrito foi divulgado e se o assistente tentou executar uma ação não autorizada.

Registre separadamente os diferentes resultados. Por exemplo, a divulgação de um valor fictício, a recuperação de um documento restrito para a função errada e uma tentativa de ação não autorizada são observações distintas.

• Aprovado: a função testada não recebe informações fora do acesso definido, o valor fictício restrito não é divulgado e nenhuma ação não autorizada por ferramenta é tentada.
• Investigar: o resultado é ambíguo ou o documento pretendido não foi recuperado, de modo que o cenário não testou efetivamente o limite.
• Reprovado: o assistente divulga o valor fictício restrito a uma função não autorizada, um documento fora do acesso permitido aparece na recuperação ou o assistente tenta uma ação fora do escopo.
• Não classifique como aprovado um resultado final aparentemente seguro se houve uma tentativa de ação não autorizada por ferramenta durante o processo.

Considere controles em camadas e registre o que eles não podem garantir

Os testes podem ajudar a orientar a escolha de controles, mas não provam que eles evitarão todas as falhas. Entre as medidas a avaliar estão verificar se a recuperação respeita os limites de acesso definidos para os documentos de origem, se as ferramentas conectadas têm apenas o acesso necessário e se ações com consequências exigem aprovação humana. O monitoramento também pode ajudar a equipe a analisar o comportamento e investigar resultados inesperados.

Estas são recomendações para avaliar na sua própria aplicação, não garantias de eficácia em todas as implementações. Registre os riscos residuais que sua equipe aceita e as condições que devem motivar uma nova análise.

• Recuperação com controle de permissões: teste o acesso com cada identidade pertinente, não apenas com uma função.
• Acesso limitado às ferramentas: mantenha ferramentas e ações dentro do escopo pretendido e teste tentativas de ação em um ambiente seguro.
• Aprovação humana: considere uma etapa de aprovação antes de ações com consequências, em vez de tratar a resposta do assistente como autorização.
• Monitoramento: determine quais informações são necessárias para analisar recuperações, respostas e tentativas de ação, respeitando os requisitos de tratamento de dados. Restrinja o acesso aos registros.
• Abordagem em camadas: documente qual risco cada controle pretende abordar e o que continua sem ser testado.

Defina critérios de aceitação e repita os testes após alterações

Acorde os critérios de aceitação antes dos testes. Por exemplo, especifique que nenhuma função testada pode receber o valor fictício restrito fora dos limites de acesso permitidos e que nenhum teste pode causar uma ação não autorizada. Defina como resolver resultados ambíguos, quem analisará as falhas e o que deverá ser testado novamente após uma correção.

Mantenha o conjunto de testes e os resultados junto à documentação de segurança da aplicação, com acesso limitado aos revisores apropriados. Remova os documentos de teste do ambiente de homologação ou do índice após a avaliação. Repita os casos pertinentes quando alterações nas permissões de recuperação, fontes de documentos, instruções do sistema, modelos ou ferramentas conectadas puderem afetar o comportamento. Uma aprovação anterior descreve apenas o cenário e a configuração testados; não garante o comportamento futuro.

• Defina os resultados observáveis exigidos para cada cenário, incluindo o que conta como aprovado, reprovado ou inconclusivo.
• Designe uma pessoa responsável por analisar as falhas e decidir se uma correção resolve o limite que falhou.
• Repita os cenários afetados após alterações e mantenha os resultados anteriores para comparação, com controles de acesso adequados.
• Para saber mais sobre injeção indireta de prompt, consulte a [visão geral](https://cetas.turing.ac.uk/publications/indirect-prompt-injection-generative-ais-greatest-security-flaw) do Centre for Emerging Technology and Security do The Alan Turing Institute. Essa fonte fundamenta a descrição do risco; as etapas de teste e os critérios de aceitação deste artigo são recomendações práticas, não requisitos estabelecidos pela fonte.