Cinco Documentos Comprometidos Quebram Seu RAG: Onde Está a Vulnerabilidade Real e Como Lidar com Ela

Se você já implementou um sistema de Geração Aumentada por Recuperação (Retrieval-Augmented Generation, RAG), sua equipe de segurança provavelmente se concentrou no vetor de ataque mais óbvio: requisições maliciosas do usuário. Você implementou validação de entrada, restrições de segurança, ou seja, filtros que detectam e bloqueiam prompts maliciosos, e talvez até um classificador de prompt injection. A porta de entrada do usuário está trancada.

Mas há uma segunda fronteira de confiança. E ela é frequentemente deixada desprotegida.

O RAG funciona da seguinte forma: o sistema recupera documentos relevantes de uma base de conhecimento e os adiciona ao contexto de um Large Language Model (LLM) junto com a requisição do usuário. Essa arquitetura cria uma divisão implícita de confiança que a maioria das equipes de segurança nem sequer questiona: a entrada do usuário não é confiável, mas o conteúdo recuperado é confiável. Afinal, ele vem da sua própria base de conhecimento.

É essa suposição que se torna uma vulnerabilidade arquitetônica, tornando os sistemas RAG particularmente suscetíveis. Um invasor que possa influenciar o que entra na sua base de conhecimento – o corpus de documentos do qual o sistema recupera dados – pode injetar instruções maliciosas através de uploads de documentos, integrações de dados ou pipelines de processamento de dados comprometidos.

Essas instruções contornarão todos os mecanismos de segurança do usuário que você implementou. A ameaça não entra pela porta da frente que você está guardando. Ela entra pelo corpus em que você confia.

Se você participou de discussões sobre arquitetura de segurança para implementações de RAG, provavelmente notou um padrão: as equipes passam horas discutindo validação de entrada e proteção contra prompt injection, e depois, sem muitas perguntas, aprovam o pipeline de upload de documentos porque "são apenas dados internos". Essa é uma zona cega que aparece repetidamente, e é onde reside a superfície de ataque mais interessante.

A Matemática do Ataque: Cinco Documentos em Meio a Milhões

Quão eficazes são esses ataques na prática? De acordo com o estudo PoisonedRAG (Zou et al.), publicado na USENIX Security 2025 por pesquisadores da Penn State e da Illinois Tech, apenas cinco documentos cuidadosamente elaborados, direcionados a uma consulta específica, podem manipular as respostas de IA com mais de 90% de sucesso, mesmo em uma base de conhecimento contendo milhões de documentos.

Isso não é uma exploração ampla de todo o sistema. O ataque é muito específico e funciona apenas sob duas condições. Primeiro, o documento malicioso deve ser semanticamente próximo o suficiente da consulta alvo para que o componente de recuperação o selecione de forma consistente. Segundo, uma vez no contexto, ele deve direcionar com sucesso o modelo para a resposta desejada pelo invasor. Quando ambas as condições são atendidas, um pequeno conjunto de documentos envenenados é suficiente para influenciar de forma confiável consultas valiosas específicas.

Os pesquisadores também avaliaram as medidas de proteção propostas e as consideraram insuficientes. Isso sugere que mudanças arquitetônicas mais fundamentais podem ser necessárias.

Bancos de Dados Vetoriais: Construídos para Velocidade, Não para Adversários

A edição de 2025 do OWASP Top 10 for LLM Applications introduziu uma nova categoria que as equipes de segurança devem examinar de perto: LLM08:2025 Vector and Embedding Weaknesses. Esta categoria reconhece que a infraestrutura subjacente aos sistemas RAG – especificamente bancos de dados vetoriais e pipelines de construção de embeddings – cria sua própria classe de vulnerabilidades.

Bancos de dados vetoriais armazenam documentos como embeddings: vetores numéricos multidimensionais que capturam o significado semântico. Quando você constrói um embedding para uma frase, o vetor resultante a coloca em um espaço matemático onde frases semelhantes se agrupam. É assim que a recuperação funciona. E é por isso que esses sistemas se tornam vulneráveis.

Há uma desconexão estrutural aqui que, na minha opinião, a indústria ainda não compreendeu totalmente: bancos de dados vetoriais foram projetados para busca de similaridade escalável. Eles são ótimos em encontrar documentos semanticamente próximos a uma consulta. Mas eles não foram projetados para um ambiente hostil onde atacantes tentam ativamente influenciar o que será recuperado.

Recuperação Inversa de Embeddings: Seus Vetores Revelam Mais do Que Parecem

Uma das descobertas mais preocupantes de pesquisas recentes é que os embeddings podem ser revertidos para recuperar fragmentos significativos do texto original. As organizações frequentemente tratam embeddings como uma forma de abstração e presumem que o conteúdo original não pode ser recuperado de sua representação vetorial. Essa suposição está incorreta.

Neste modelo de ameaça, um invasor precisa obter acesso aos embeddings armazenados – através de um banco de dados comprometido, acesso interno, uma API mal configurada ou consultas ao armazenamento vetorial sem controle de acesso adequado. Uma vez que os vetores são obtidos, o atacante pode treinar um modelo auxiliar que atua como um "decodificador de embeddings", efetivamente revertendo o processo de construção de embeddings para recuperar o texto original.

De acordo com o estudo "On the Transferability of Embedding Inversion Attacks" (Huang et al.), apresentado na ACL 2024, os atacantes podem usar modelos auxiliares para inferir conteúdo apenas a partir de vetores. Nomes próprios, termos técnicos e frases únicas são particularmente vulneráveis, pois ocupam regiões distintas no espaço de embeddings.

Para sistemas RAG que constroem embeddings de documentos confidenciais, dados de clientes ou correspondências internas, isso significa que o próprio banco de dados vetorial, se comprometido, se torna uma fonte de vazamento de dados. Mesmo que os documentos originais estejam protegidos por controles de acesso, um invasor que consiga roubar ou interceptar os embeddings poderá decodificar uma parte substancial do texto original, incluindo dados sensíveis: nomes, números de conta ou informações que constituem segredos comerciais.

Falhas de Isolamento em Ambientes Multi-usuário

Em ambientes onde vários usuários ou aplicações compartilham um banco de dados vetorial, também existe o risco de vazamento de informações entre contextos. Se o controle de acesso for implementado incorretamente no nível de embeddings e recuperação, as consultas de um contexto de usuário podem recuperar documentos de outro. De acordo com as diretrizes da OWASP, um controle de acesso insuficiente ou incorretamente aplicado pode levar ao acesso não autorizado a embeddings que contêm informações sensíveis.

Imagine uma plataforma SaaS financeira onde os documentos de cada cliente são transformados em embeddings e armazenados em um armazenamento vetorial compartilhado. Um usuário da Empresa A faz uma pergunta inócua sobre previsões de receita trimestral. Se os vetores não forem isolados por cliente, a busca por similaridade pode recuperar conteúdo semanticamente relacionado de documentos financeiros confidenciais da Empresa B, expondo seus dados de receita a um usuário da Empresa A. A consulta não foi maliciosa – a arquitetura foi.

A complexidade reside no fato de que os mecanismos tradicionais de controle de acesso em bancos de dados se encaixam mal na busca por similaridade vetorial. Uma consulta não acessa documentos específicos por ID; ela solicita documentos semelhantes a um embedding de consulta. Embora muitos bancos de dados vetoriais suportem multi-usuário através de namespaces, coleções ou filtragem de metadados, eles geralmente dependem de aplicação no nível da aplicação, em vez de garantias de segurança em nível de linha gerenciadas por políticas e integradas.

Na prática, isso significa que as equipes devem manter índices vetoriais separados para cada cliente, com todos os custos e complexidade operacional associados, ou garantir que cada consulta vetorial seja complementada por filtros de metadados conscientes de permissão para impor limites de acesso. Se você já tentou adicionar controle de acesso a um sistema que não foi projetado para isso, sabe quantos casos de borda isso cria.

Quando a Teoria Encontra a Produção

Estas não são preocupações teóricas. Pesquisadores e equipes de segurança já demonstraram a exploração de vulnerabilidades RAG em sistemas de produção reais.

Slack AI: Prompt Injection Indireta via Canais Públicos

Em agosto de 2024, pesquisadores de segurança revelaram uma vulnerabilidade no Slack AI que combinava prompt injection indireta com recuperação no estilo RAG. O Slack AI processa mensagens de canais para gerar resumos e respostas de IA. Por design, as mensagens de canais públicos são pesquisáveis por todos os membros do espaço de trabalho, independentemente de terem ingressado no canal ou não.

O ataque explorou esse comportamento: um invasor publicou uma mensagem com instruções maliciosas em um canal público. Quando o Slack AI recuperou essa mensagem como contexto para responder a uma consulta do usuário, as instruções embutidas poderiam fazer com que a IA gerasse um link de phishing, através do qual os dados do contexto da conversa do usuário seriam vazados.

A vulnerabilidade era real, mas sua escala era menor do que poderia parecer: o atacante já precisava ter uma conta no mesmo espaço de trabalho do Slack, e o comportamento de recuperação de dados de canais públicos era uma decisão de design, não uma falha de controle de acesso.

O Slack reconheceu o problema em 20 de agosto de 2024 e lançou um patch no mesmo dia. Em seu aviso, a empresa descreveu isso como um cenário em que "em circunstâncias muito limitadas e específicas, um invasor com uma conta existente no mesmo espaço de trabalho do Slack poderia enganar os usuários para obter determinados dados". A empresa relatou não ter encontrado evidências de acesso não autorizado a dados de clientes.

O interesse aqui não está na gravidade ou insignificância da descoberta específica, mas no padrão em si: uma vez que um LLM recupera conteúdo influenciado por um invasor e o trata como contexto confiável, o prompt injection se torna um amplificador que transforma uma pequena decisão de design em um caminho para vazamento de dados.

Memória do ChatGPT: Spyware Persistente via Contexto Envenenado

Em setembro de 2024, o pesquisador de segurança Johann Rehberger demonstrou o SpAIware – uma técnica para exfiltração persistente de dados do ChatGPT através do envenenamento da função de memória. Ao enganar um usuário para visitar um site malicioso ou analisar um documento malicioso especialmente preparado, um invasor poderia injetar instruções na memória do ChatGPT. Essas instruções persistiriam entre as sessões e fariam com que a IA enviasse todas as conversas subsequentes para um servidor controlado pelo atacante.

Defesa em Camadas para Sistemas RAG

Então, o que fazer com tudo isso na prática? Proteger um RAG requer controle em três níveis distintos: ingestão de dados, recuperação e geração. Uma falha em um nível não deve levar à comprometimento total.

Controle na Ingestão de Dados: Trate Documentos como Código A base de conhecimento agora faz parte da sua superfície de ataque. Cada documento de entrada deve ser tratado com o mesmo cuidado que você trata a entrada do usuário.

• Verificação de Proveniência significa aceitar dados apenas de fontes confiáveis e verificadas. Mantenha um log de auditoria: o que exatamente entrou na base de conhecimento, quando e de onde. Se o seu sistema RAG carrega documentos de fontes externas, canais de compartilhamento de dados de parceiros ou uploads de usuários, você precisa de pipelines de verificação que confirmem a proveniência dos dados antes da construção de embeddings.
• Pré-processamento para Instruções Ocultas envolve escanear documentos antes da construção de embeddings em busca de padrões semelhantes a tentativas de prompt injection. Isso inclui frases como "ignore as instruções anteriores", "agora você é" e construções de comando semelhantes – e esses são apenas os exemplos mais óbvios. Ferramentas como o PromptGuard open-source da Meta podem ajudar a detectar tentativas de injeção no conteúdo do documento. Filtros baseados em expressões regulares fornecem a primeira linha de defesa, mas classificadores baseados em LLMs detectam tentativas mais sofisticadas.
• Monitoramento de Integridade de Conteúdo requer auditorias regulares da base de conhecimento em busca de alterações inesperadas. Implemente logging imutável de todas as modificações. Se os documentos puderem ser atualizados após o upload inicial, verifique se as atualizações vêm de fontes autorizadas.
• Criptografia de Embeddings significa tratar vetores como dados sensíveis que precisam ser protegidos em repouso e em trânsito. Muitos bancos de dados vetoriais priorizam desempenho em detrimento da segurança e não criptografam embeddings por padrão, confiando em segurança no nível da aplicação.

Se um invasor obtiver acesso à rede ou um token de API roubado, ele poderá descarregar todo o índice de embeddings e executar ataques de recuperação inversa offline. Criptografar embeddings em repouso e exigir TLS para todas as conexões com o banco de dados vetorial aumenta a dificuldade de roubo de dados.

Controle na Recuperação: Busca Consciente de Permissões O nível de recuperação precisa de mecanismos de controle de acesso que considerem o contexto do usuário, não apenas a similaridade da consulta.

• Recuperação Consciente de Permissões garante que, quando um usuário consulta um sistema RAG, os documentos encontrados sejam filtrados com base no que esse usuário tem permissão para acessar. Isso requer a passagem da identidade e das permissões do usuário para o processo de recuperação, em vez de se limitar ao nível da aplicação.
• Isolamento de Clientes em ambientes multi-usuário significa a separação lógica rigorosa de conjuntos de dados em um banco de dados vetorial. Diferentes grupos de usuários ou aplicações não devem ser capazes de recuperar documentos uns dos outros através de busca por similaridade.
• Detecção de Anomalias na Recuperação envolve monitorar consultas que retornam combinações incomuns de documentos, ou documentos que são recuperados com frequência incomum para certos padrões de consulta. Documentos envenenados frequentemente têm características de recuperação distintas: eles disparam em faixas estreitas de consultas, especificamente adaptadas aos objetivos do invasor.
• Autenticação de Consulta e Logging de Auditoria garantem que cada consulta ao banco de dados vetorial seja autenticada e registrada. Monitore leituras em massa incomuns de embeddings: isso pode indicar que um atacante está se preparando para ataques de recuperação inversa ou exfiltração de dados. Limitar a taxa de recuperação de embeddings pode impedir descarregamentos em massa sem prejudicar as consultas normais da aplicação.

Controle na Geração: Restrições e Monitoramento Mesmo com controles nas fases de ingestão e recuperação, deve-se presumir que algum conteúdo malicioso possa chegar à fase de geração.

• Detecção de Injeção no Contexto monitora padrões suspeitos no prompt coletado antes de ser enviado ao LLM. Os mesmos classificadores de prompt injection usados na ingestão de dados, como o PromptGuard mencionado anteriormente, podem ser usados aqui. Apenas neste caso, eles escaneiam o contexto totalmente coletado, em vez de documentos individuais.

O objetivo é capturar tentativas de injeção que passaram pelos filtros de ingestão, por exemplo, porque a instrução maliciosa só se torna aparente em combinação com certos documentos recuperados.

• Monitoramento de Saída refere-se a respostas de LLM suspeitas se elas contiverem elementos inesperados: URLs, solicitações de informações confidenciais, instruções para executar ações ou conteúdo que se desvia significativamente dos padrões de resposta esperados.

Por exemplo, se a resposta a "Qual é a nossa política de devolução?" de repente contém https://attacker.example.com/?data=... ou pede ao usuário para fornecer uma senha, é um forte indicador de injeção bem-sucedida. O escaneamento automático de URLs que levam a domínios externos, strings codificadas em base64 ou solicitações de credenciais pode interceptar tentativas de exfiltração antes que cheguem ao usuário.

• Atribuição de Recuperação fornece rastreabilidade clara de quais documentos influenciaram cada resposta. Quando anomalias são detectadas, você precisa ser capaz de rastrear de volta aos documentos originais e removê-los ou colocá-los em quarentena.

Conclusões

O paradoxo de confiança nos sistemas RAG cria caminhos de ataque que contornam a validação de entrada tradicional. Organizações que implementam RAG precisam reconhecer que sua base de conhecimento agora faz parte da superfície de ataque, não um recurso interno confiável.

• O envenenamento do corpus é surpreendentemente eficaz. Pesquisas acadêmicas mostram que cinco documentos em meio a milhões podem atingir mais de 90% de sucesso no ataque. Os invasores não precisam comprometer toda a sua base de conhecimento para manipular respostas a consultas valiosas.
• Bancos de dados vetoriais trazem suas próprias vulnerabilidades. Ataques de recuperação inversa de embeddings permitem recuperar fragmentos significativos do texto original de vetores. Em ambientes multi-usuário sem recuperação consciente de permissões, surge o risco de vazamento entre contextos.
• Sistemas de produção já enfrentaram esses problemas. Incidentes de prompt injection indireta no Slack AI e envenenamento de memória no ChatGPT mostram que esses padrões de ataque não se limitam a trabalhos acadêmicos. Mesmo quando as descobertas individuais são limitadas em escala, elas demonstram como a recuperação no estilo RAG pode amplificar problemas que, de outra forma, pareceriam insignificantes.
• A defesa requer três camadas. O controle na ingestão de dados trata os documentos como código. O controle na recuperação aplica permissões durante a consulta. O controle na geração assume que algum conteúdo malicioso chegará ao LLM e o detecta antes ou depois da geração.

No contexto de RAG e LLMs, é importante não apenas entender os riscos, mas também compreender como os principais métodos de trabalho com esses sistemas funcionam em geral.

Em 6 de maio, às 18:00, em uma aula demonstrativa gratuita "Métodos de Trabalho com LLMs: Prompt Engineering, LoRA e RAG", junto com Maria Tikhonova, analisaremos cenários básicos de aplicação de LLMs, princípios de LoRA, prompt engineering e RAG. O formato é útil para quem quer preencher lacunas, fazer perguntas a um especialista e ver como é o treinamento no curso "NLP / Natural Language Processing".

Inscreva-se na aula Um pouco de prática sobre o tema – faça o teste de admissão em NLP e descubra se há lacunas em seu conhecimento.

Tags: RAG LLM prompt injection segurança LLM envenenamento de dados bancos de dados vetoriais embeddings OWASP LLM Top 10