Explore um Pipeline de RAG Vulnerável

Problema

Sistemas de Retrieval-Augmented Generation (RAG) respondem perguntas primeiro buscando trechos relevantes de documentos num vector store, e depois entregando esses trechos a um LLM como contexto. Num produto multi-tenant — pense num SaaS onde o Tenant A e o Tenant B fazem upload cada um dos seus próprios documentos privados — o passo de retrieval *precisa* filtrar por tenant antes que qualquer coisa chegue ao modelo. Se não filtrar, o modelo pode receber o texto confidencial do Tenant B enquanto responde uma pergunta feita em nome do Tenant A, e ele vai citar esse conteúdo sem problema, porque do ponto de vista do modelo todo trecho recuperado é só "contexto que ele recebeu para usar". Isso é um vazamento de dados entre tenants escondido dentro do que parece, na superfície, uma feature funcionando: o chatbot responde perguntas corretamente na maior parte do tempo, até o retrieval trazer o trecho do tenant errado e o modelo repetir o que está nele — incluindo, neste lab, um documento deliberadamente "envenenado" com instruções para vazar uma flag secreta. Neste lab você vai rodar a **DARE Vulnerable AI Suite** localmente e atacar seu desafio `vulnerable-rag`: enviar perguntas comuns como `tenant-a` até o retrieval acidentalmente trazer à tona um trecho que pertence ao `tenant-b`. > Pratique só contra a suíte descartável `dare-vulnerable-ai` rodando > localmente em `127.0.0.1:8000` (vinculada só ao localhost), com > documentos sintéticos de seed. Nunca tente ataques de retrieval > cross-tenant contra um produto multi-tenant real ou qualquer sistema > que você não seja dono ou não tenha autorização explícita por escrito > para testar.

Objetivos

Ao final deste lab você será capaz de:

• Explicar por que o filtro de tenant num pipeline de RAG precisa
  acontecer na camada de vector store / retrieval, não só na resposta
  da API.
• Enumerar o inventário de documentos de um desafio de RAG sem ler o
  conteúdo completo, para entender o que está em escopo.
• Sondar um endpoint de query de RAG com perguntas variadas para trazer
  à tona um vazamento de retrieval cross-tenant.
• Reconhecer um "documento envenenado" plantado para testar exatamente
  essa classe de vazamento.
• Ler a solução oficial de um desafio e articular por que uma correção
  só na camada de API seria insuficiente.

Pré-requisitos

Para completar este lab você vai precisar de:

• Docker e Docker Compose instalados.
• Acesso ao repositório privado dare-vulnerable-ai (alunos
  matriculados têm acesso): git@github.com:darelabs-tech/dare-vulnerable-ai.git.
• curl (ou um cliente HTTP equivalente) e um terminal.
• Familiaridade básica com JSON; nenhuma experiência prévia com
  RAG/bancos vetoriais é exigida.

O modelo mental: retrieval é uma busca por similaridade, não um fato

O passo de retrieval de um sistema RAG é, por baixo do termo de
marketing, uma busca por similaridade: "encontre os N trechos cujos
embeddings estão mais próximos do embedding desta pergunta." Busca por
similaridade não tem noção nenhuma de "tenant" — ela só ranqueia por
distância vetorial. Se um documento envenenado ou meramente parecido em
tópico de outro tenant pontuar alto o suficiente, ele é trazido, ponto
final, a menos que algo antes do ranking já o tenha excluído.

Fluxo de retrieval vulnerável

  pergunta ──▶ embed ──▶ busca por similaridade em TODOS os vetores de todos os tenants
                                        │
                                        ▼
                      top-N trechos (filtro de tenant aplicado onde? em lugar nenhum)
                                        │
                                        ▼
                            entregue ao LLM como contexto

Por que isso é pior do que parece

Um bug de filtro de tenant num endpoint REST normalmente é visível no
formato da resposta da API — você notaria tenant_id: "tenant-b"
aparecendo em algum lugar que não deveria. No RAG, o vazamento é
lavado através de linguagem natural: o modelo parafraseia ou cita o
trecho vazado como parte de uma resposta fluente, então isso pode
escapar de revisores que só estão checando "a resposta soa razoável",
não "essa resposta acabou de repetir o documento privado de outro
cliente".

Como você vai trabalhar neste lab

1. Desbloqueie o desafio vulnerable-rag.
2. Liste seus documentos para entender o que está no corpus (sem ler o
   conteúdo completo).
3. Envie perguntas variadas como tenant-a até um trecho do tenant-b
   aparecer em retrieved_chunks.
4. Confirme solved: true e inspecione o trecho vazado.
5. Leia a solução oficial e explique por que a correção pertence ao
   vector store, não à camada de API.