Segurança em RAG: riscos e como proteger seu pipeline

Um sistema RAG (Retrieval-Augmented Generation) não fica mais seguro só porque busca informação em vez de depender da memória do modelo — ele troca um risco por outro conjunto de riscos. Todo documento que entra na base de conhecimento vira uma superfície de ataque em potencial, porque o conteúdo recuperado é tratado pelo modelo como contexto confiável. Este guia cobre os quatro vetores de ataque específicos de pipelines RAG e os controles práticos para reduzir cada um.

Por que RAG amplia a superfície de ataque

Um LLM sem busca externa só pode ser manipulado pelo que o usuário digita diretamente no prompt. Um sistema RAG herda esse risco e soma outro: qualquer texto que entrar na base vetorial — um PDF enviado por um cliente, uma página raspada da web, um e-mail arquivado — pode carregar instruções escondidas que o modelo vai executar como se fossem parte do contexto legítimo. O [artigo sobre Prompt Injection](/artigo/prompt-injection-o-que-e-como-funciona-como-proteger) do Bytezine já cobre esse mecanismo em geral, incluindo o caso real do EchoLeak (CVE-2025-32711) no Microsoft 365 Copilot. Aqui o recorte é mais específico: o que muda quando o vetor de entrada é uma base vetorial inteira, com centenas ou milhões de documentos, mantida por múltiplas pessoas ao longo do tempo.

O OWASP Top 10 for LLM Applications trata esse conjunto de riscos como uma categoria própria — Vector and Embedding Weaknesses (LLM08:2025) — justamente porque afeta principalmente aplicações que usam RAG com bancos de dados vetoriais e busca por similaridade. Segundo o levantamento da entidade, as falhas mais comuns nessa categoria são recuperação não autorizada de documentos, controles de acesso mal configurados, vazamento entre tenants em bases compartilhadas, envenenamento (poisoning) do índice e inversão de embeddings.

Os quatro vetores de ataque específicos de RAG

1. Injeção indireta via documentos recuperados

Um atacante planta instruções maliciosas dentro de um documento que sabe (ou espera) que vai ser indexado — em texto invisível, em metadados, ou disfarçado de conteúdo legítimo. Quando alguém faz uma pergunta cuja busca semântica traz esse documento entre os resultados, o texto malicioso entra no prompt como "contexto confiável" e o modelo pode segui-lo. Em cenários com agentes, isso pode alterar o planejamento da tarefa, disparar chamadas de ferramenta não previstas ou levar à exfiltração de dados em ações subsequentes.

2. Poisoning do índice vetorial

Diferente da injeção pontual, o poisoning ataca a base como um todo: o objetivo é inserir documentos que rankeiem bem na busca por similaridade para respostas específicas, fazendo o sistema repetidamente recuperar e reproduzir o conteúdo forjado. O estudo acadêmico PoisonedRAG (Zou et al., 2024, apresentado na USENIX Security 2025) mostrou que injetar apenas cinco textos maliciosos otimizados em uma base com milhões de documentos foi suficiente para atingir 90% de taxa de sucesso em respostas direcionadas pelo atacante — e que várias defesas testadas na época não foram suficientes para bloquear o ataque, o que reforça que esse é um problema estrutural do RAG, não um bug pontual de implementação.

3. Vazamento entre tenants e controle de acesso deficiente

Em bases vetoriais compartilhadas por múltiplos usuários, times ou clientes, um controle de acesso mal desenhado permite que a busca por similaridade retorne documentos de um tenant para a consulta de outro. É especialmente fácil de introduzir esse bug porque a semântica da busca vetorial não tem noção nativa de permissão — ela só sabe medir distância entre vetores. Se o filtro de quem pode ver o quê não estiver na própria camada de retrieval, ele simplesmente não existe do ponto de vista de segurança.

4. Inversão de embeddings

Embeddings não são anônimos por natureza. Pesquisadores demonstraram em 2023 ("Text Embeddings Reveal (Almost) As Much As Text", arXiv 2310.06816) que é possível reconstruir o texto original a partir do vetor com um método iterativo de re-embedding, recuperando exatamente até 92% de textos curtos (32 tokens). Trabalhos posteriores generalizaram esse tipo de ataque para outros modelos de embedding. Na prática, isso significa que um vetor vazado — via API mal protegida, backup exposto ou banco vetorial sem controle de acesso — pode ser tão sensível quanto o texto que ele representa.

Defesa 1: controle de acesso na camada de retrieval, não depois

A recomendação que aparece de forma consistente em guias de fornecedores de bancos vetoriais e provedores de nuvem é a mesma: o filtro de permissão precisa acontecer na consulta ao banco vetorial (pré-filtro), não depois que os resultados já voltaram (pós-filtro). Filtrar depois da busca por similaridade tem dois problemas: o modelo pode acabar recebendo menos resultados relevantes do que deveria (porque alguns dos top-K foram descartados), e, se a filtragem falhar silenciosamente, o dado sensível já passou pela camada de recuperação.

# Filtro de permissão aplicado ANTES da busca por similaridade,
# na própria consulta ao banco vetorial — não depois de já ter os resultados.
import chromadb

client = chromadb.PersistentClient(path="./vectordb")
collection = client.get_collection("documentos_empresa")

resultados = collection.query(
    query_texts=["política de reembolso"],
    n_results=5,
    where={"allowed_roles": {"$in": [papel_do_usuario]}}
)

Esse padrão é o que a literatura de arquitetura chama de retrieval permission-aware: as regras de acesso do sistema de origem (quem pode ver qual documento) são espelhadas como metadados em cada chunk no momento da ingestão, e atualizadas sempre que uma permissão muda — não só uma vez, na criação do índice. Em bases multi-tenant, a prática mais citada é isolar por namespace (um por cliente ou organização) além do filtro por metadados, para que um erro de filtro não vire um vazamento entre empresas diferentes.

Defesa 2: tratar a ingestão como fronteira de confiança

Como o poisoning explora justamente o que entra na base, a defesa central é validar a fonte antes de indexar, não depois. Isso inclui: aceitar conteúdo só de fontes verificadas quando possível; registrar a proveniência de cada documento (de onde veio, quando, por quem foi aprovado); e auditar periodicamente a base em busca de conteúdo anômalo — um documento que aparece com frequência desproporcional nos resultados de buscas muito diferentes é um sinal de alerta clássico de poisoning.

import hashlib

def pode_indexar(conteudo: str, fonte_verificada: bool, hashes_bloqueados: set) -> bool:
    if not fonte_verificada:
        return False
    hash_atual = hashlib.sha256(conteudo.encode()).hexdigest()
    return hash_atual not in hashes_bloqueados

Esse tipo de checagem é deliberadamente simples — não existe hoje um filtro que detecte com certeza um documento adversarial otimizado como os do PoisonedRAG. A defesa real é em profundidade: validação na entrada, monitoramento contínuo do padrão de recuperação e limitação de dano quando (não se) algo passar.

Defesa 3: reduzir a exposição das embeddings em si

• Nunca exponha vetores brutos em respostas de API públicas — devolva apenas o texto/documento associado, não o embedding.
• Trate backups e réplicas do banco vetorial com o mesmo controle de acesso e criptografia em repouso que os dados originais que eles representam.
• Limite e monitore consultas de vizinhos mais próximos em volume alto vindas de uma mesma origem — é o padrão de tráfego usado para reconstruir vetores em massa.
• Considere que, para dados regulados pela LGPD, um embedding gerado a partir de dado pessoal ainda é dado pessoal — veja o [checklist de LGPD para startups](/artigo/lgpd-checklist-startups-2026) para o que isso implica em retenção e consentimento.

Defesa 4: nunca tratar o conteúdo recuperado como confiável por padrão

A última linha de defesa é a mesma técnica usada contra prompt injection em geral: delimitar explicitamente, no prompt enviado ao modelo, onde termina a instrução do sistema e onde começa o dado externo recuperado — e instruir o modelo a nunca executar comandos que apareçam dentro dessa área delimitada. Como esse padrão já foi detalhado com exemplo de código no artigo sobre Prompt Injection, vale a pena revisitá-lo ao montar a etapa final do pipeline RAG: é o filtro que pega o que passou pelas três defesas anteriores.

Checklist rápido

• Filtro de permissão aplicado na consulta ao banco vetorial (pré-filtro), não depois dos resultados.
• Namespace ou coleção separada por tenant em bases multi-tenant.
• ACLs da fonte original espelhadas como metadados a cada ingestão e atualizadas em mudança de permissão.
• Fonte de cada documento registrada (proveniência) e ingestão limitada a fontes verificadas quando possível.
• Monitoramento de padrões anômalos de recuperação (mesmo documento retornando com frequência incomum).
• Vetores nunca expostos brutos em respostas de API; backups com o mesmo controle de acesso que os dados originais.
• Conteúdo recuperado sempre delimitado como dado não confiável no prompt final.

Onde essas defesas ainda falham

Nenhuma das defesas acima é garantia absoluta. Os próprios autores do PoisonedRAG testaram defesas de detecção e filtragem disponíveis à época e concluíram que nenhuma neutralizava o ataque de forma confiável — sinal de que esse continua sendo um problema de pesquisa ativo, não um item que se resolve com uma configuração. Isolamento de acesso e proveniência reduzem a superfície de ataque, mas não eliminam o risco de que um documento aparentemente legítimo, vindo de uma fonte já confiável, esteja carregando conteúdo adversarial. Trate RAG como qualquer sistema que processa entrada externa: com defesa em camadas e a expectativa de que uma camada pode falhar.