Como cinco documentos podem quebrar um sistema RAG e transformar uma base de conhecimento em um vetor de ataque

Os sistemas RAG são frequentemente percebidos como uma maneira de reduzir alucinações e forçar LLMs a confiarem em documentos corporativos. Mas se a base de conhecimento é considerada confiável por padrão, ela pode se tornar o canal mais conveniente para injeção de prompts e substituição silenciosa de respostas.

Onde está o ponto fraco

O problema não é que o modelo "lê" mal os documentos, mas que ele não distingue entre fatos e instruções da forma como os humanos fazem. Se uma base de conhecimento recebe vários arquivos especialmente preparados, a camada de recuperação do RAG pode trazer consistentemente esses documentos para o contexto de consultas relevantes. Então o LLM vê os trechos como parte de seu ambiente de trabalho e começa a seguir instruções ocultas: ignorar o prompt do sistema, mudar prioridades, inserir conclusões falsas ou conduzir o diálogo em uma direção favorável ao atacante.

Para uma equipe, isso é especialmente perigoso porque o ataque se mascara como operação normal da base de conhecimento. Um usuário faz uma pergunta legítima, a recuperação retorna trechos "relevantes", e a resposta parece confiante e conectada à consulta. Os logs também podem parecer normais: o modelo não quebra, não entra em um jailbreak óbvio e não mostra nada suspeito.

Mas a qualidade da solução cai, e com ela—a confiança no produto, que deveria se basear em documentos verificados.

Por que cinco documentos são suficientes

O risco principal é que a segurança do RAG é frequentemente superestimada por causa dos embeddings. Parece que a busca vetorial transforma textos de origem em abstrações matemáticas seguras, mas não é assim. Os embeddings ajudam a encontrar fragmentos semelhantes, não neutralizam seu significado.

Se cinco documentos são escritos para corresponder a consultas populares de usuários e conter instruções maliciosas nos lugares certos, o sistema vai repetidamente incluí-los no contexto. O ataque não requer controle total da base de conhecimento: às vezes, alguns apontamentos, FAQs ou políticas internas que acabam no índice sem verificação são suficientes. O efeito é amplificado pela própria mecânica de recuperação.

O sistema raramente fornece o documento inteiro ao modelo—normalmente o divide em chunks e seleciona os melhores resultados. Isso significa que o atacante não precisa escrever um texto malicioso longo: fragmentos curtos, mas semanticamente "grudados" que aparecem nos resultados top-k são suficientes. Como resultado, o LLM recebe não uma referência neutra, mas um conjunto pré-selecionado de prompts influentes, e o operador do sistema pode não notar por muito tempo que as respostas estão se desviando na direção estabelecida por esses fragmentos.

O que precisa ser protegido

Em produção, o RAG não pode ser protegido por um único filtro na entrada. Você precisa de um esquema multicamadas que verifique documentos, chunks extraídos e a resposta final do modelo. Caso contrário, uma equipe pode limpar a consulta do usuário, mas deixar a mesma injeção passar pela base de conhecimento. Um problema separado são ataques "silenciosos", onde o sistema não falha ou mostra um erro óbvio—simplesmente começa a aconselhar com confiança ações erradas, substituir prioridades ou revelar o que não deveria mostrar.

• Verificação de documentos antes da indexação para instruções ocultas e padrões suspeitos
• Isolamento de dados por fonte, função e nível de confiança
• Políticas de recuperação: limites sobre dominância de fonte única e controle de diversidade
• Filtragem de contexto antes de alimentar o LLM e guardrails separados para a resposta
• Logs, testes de red-team e reavaliação regular do corpus após atualizações

Os cenários de demonstração normalmente ocultam esse problema porque o corpus é pequeno, as fontes são conhecidas com antecedência e as consultas são previsíveis. Em um sistema funcional, tudo é diferente: documentos são carregados em lotes, atualizados sem moderação manual, vêm de departamentos diferentes e frequentemente misturam fatos, conselhos, modelos e instruções de serviço. Em tal ambiente, o RAG deve ser projetado não como "busca + LLM", mas como um pipeline sensível à segurança com zonas de confiança claras, auditorias de mudanças e regras separadas para diferentes tipos de conteúdo.

O que isso significa

A principal vulnerabilidade no RAG não está apenas no modelo, mas na confiança colocada no contexto fornecido pela infraestrutura. Se o sistema funciona com dados reais de negócios, a proteção deve começar muito antes da geração de respostas: nas fases de carregamento de documentos, recuperação e pós-processamento. Caso contrário, até mesmo um pequeno conjunto de arquivos envenenados pode distorcer sistematicamente o resultado.