agentsop-multi-tenant-rag
This skill encodes security-first isolation patterns for RAG systems serving multiple tenants, customers, or permission scopes. It teaches agents to enforce tenant filtering at the vector store query boundary—the only place where isolation truly matters—and pairs vendor-specific primitives (Pinecone namespaces, Weaviate multiTenancy, Qdrant payload filters, pgvector RLS) with framework adapters like LlamaIndex and LangChain. Activate when designing, reviewing, or debugging any retrieval pipeline where the corpus spans more than one tenant.
agentsop-multi-tenant-rag prevents cross-tenant data leaks by enforcing isolation at the vector store query boundary.
AI-generated summary based on this skill's SKILL.md
Install
agentsope/SkillAlchemy/agentsop-multi-tenant-rag · repository language: Python
git clone https://github.com/agentsope/SkillAlchemy
cp -r SkillAlchemy/skills/agentsop-multi-tenant-rag ~/.claude/skills/agentsop-multi-tenant-ragnpx skillfed install agentsope/SkillAlchemy/agentsop-multi-tenant-ragFrequently asked questions
AI-generated answers based on this skill's SKILL.md and metadata
How do you prevent cross-tenant data leaks in vector databases?
agentsop-multi-tenant-rag teaches that cross-tenant leaks occur when retrieval queries bypass tenant filtering at the vector store boundary. Prevention requires enforcing tenant isolation at query time—not after retrieval—using vendor primitives: Pinecone namespaces, Weaviate multiTenancy mode, Qdrant payload filters, or pgvector row-level security. The skill pairs these with framework adapters (LlamaIndex metadata filters, LangChain filter parameters) to ensure every query is scoped to the requesting tenant before vectors are searched.
What isolation primitives does agentsop-multi-tenant-rag cover?
agentsop-multi-tenant-rag covers isolation strategies across major vector database vendors: Pinecone's namespace-based separation, Weaviate's multiTenancy class setting, Qdrant's payload filtering, and pgvector's row-level security (RLS). The skill also teaches how to integrate these with retrieval frameworks—LlamaIndex metadata filters and LangChain filter parameters—so tenant scoping is enforced consistently whether you're building with a managed service or self-hosted database.
Why does tenant filtering matter at query time in RAG?
agentsop-multi-tenant-rag emphasizes that query-time filtering is the only enforcement point that truly prevents leaks. Filtering after retrieval—a common defect—allows the vector store to return cross-tenant results before your application filters them, creating a window for exposure. By enforcing tenant_id or workspace scoping at the vector store query boundary itself, you eliminate that risk and ensure isolation is database-enforced, not application-enforced.
How does agentsop-multi-tenant-rag apply to SaaS knowledge bases?
agentsop-multi-tenant-rag teaches secure retrieval pipeline design for SaaS systems where a shared vector index serves multiple customers. It covers per-tenant namespace or collection strategies, workspace separation patterns, and how to audit existing RAG systems for tenant boundary violations. The skill activates when designing multi-customer knowledge bases to ensure each tenant's queries return only their own documents, preventing data exposure incidents.
What does agentsop-multi-tenant-rag teach about metadata vs namespace?
agentsop-multi-tenant-rag compares isolation strategies: namespaces (Pinecone) provide hard logical separation and are preferred for strong isolation; metadata filtering (Qdrant, Weaviate) is flexible but requires careful query-time enforcement to avoid bypass. The skill teaches when to choose each—namespaces for strict multi-tenant SaaS, metadata for permission-scoped retrieval within a single tenant—and how to pair them with framework adapters for consistent enforcement.
How do you implement tenant filtering in LlamaIndex or LangChain?
agentsop-multi-tenant-rag teaches framework-specific patterns: LlamaIndex uses metadata filters to scope queries by tenant_id before retrieval; LangChain uses filter parameters to pass tenant context to the vector store. Both require the underlying database to respect the filter at query time. The skill shows how to wire tenant context through your retrieval pipeline so filtering is automatic and auditable, reducing the risk of accidental cross-tenant exposure.
SKILL.md
rendered from the published skill — quoted content, verbatim
name: agentsop-multi-tenant-rag
version: 0.1.0
description: |
Security-first SOP for multi-tenant RAG systems. Activate when a calling agent
is building, reviewing, or debugging any retrieval pipeline whose vector store
is shared across more than one user, organisation, workspace, customer, or
permission scope. Encodes the single non-negotiable rule — filter at the
vector store query, never after retrieval / never after rerank — together
with the per-vendor query-time filter APIs (Pinecone namespaces +
$eq/$in, Weaviate multiTenancyConfig + tenant handle, Qdrant
is_tenant payload index + Filter.must, Chroma where, pgvector RLS),
and the cross-framework adapters (LlamaIndex MetadataFilters, LangChain
filter= dict). Frame the work as preventing CVE-2024-41892 / EchoLeak /
Slack-AI-class cross-tenant leakage, not as "adding a filter for relevance".
trigger_keywords:
- "multi-tenant RAG"
- "tenant isolation"
- "metadata filter"
- "namespace per tenant"
- "multitenancy vector store"
- "RLS pgvector"
- "cross-tenant leak"
- "RAG security"
- "workspace separation"
when_to_use:
- "any RAG / retrieval pipeline whose corpus
(truncated - see the full file via the links below)
Read as markdown · JSON record · Browse the source repository
File tree — 4 files
skills/agentsop-multi-tenant-rag/SKILL.md
skills/agentsop-multi-tenant-rag/intermediate/research_notes.md
skills/agentsop-multi-tenant-rag/references/R1-vendor-filter-cheatsheet.md
skills/agentsop-multi-tenant-rag/references/R2-cross-tenant-test-recipes.md