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".
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".
["any RAG / retrieval pipeline whose corpus is shared across >1 tenant, customer, org, user, or permission scope","reviewing PRs that touch `vector_store.query` / `index.as_retriever` / `similarity_search` / `vectorstore.query_points`","designing ingestion for a SaaS knowledge base, internal corpus split by team, or per-customer corpus","responding to a 'we got the wrong document' bug — confirm it isn't actually a cross-tenant leak first","before shipping any RAG endpoint that exposes retrieved content to end users"]
when_not_to_use
["single-tenant / single-user corpora with no access scopes — over-engineering","purely internal eval / offline notebooks against fully public data","the retrieval boundary is enforced by a per-tenant collection / index that the application can never address by name — already isolated"]
Multi-Tenant RAG · Security-First Isolation SOP
Third-person operating model for a coder agent that owns retrieval correctness
across tenant boundaries. The audience is the LLM agent writing or reviewing
the code — not the end user.
One sentence: Isolation lives at the vector store query boundary, not
at the model. Anything that reaches the LLM's context window has already
leaked.
1. 何时激活 (Activation Rules)
Activate this skill whenever any of the following holds:
The codebase contains a retrieval call (vector_store.query,
query_points, similarity_search, as_retriever().retrieve(...), raw
pgvectorORDER BY embedding <-> $1) and the corpus serves more than
one tenant, customer, organisation, workspace, user, or permission scope.
The user mentions any of: multi-tenant RAG, namespace, tenant, workspace,
tenant_id, org_id, user_id, "cross-customer", "shared index",
"knowledge base per team".
A bug report says "User A saw User B's document", "wrong company's data
surfaced", "the assistant cited a doc I don't have access to", or anything
that smells like cross-context bleed.
PR review: any new code calling a vector store without a tenant-scoped
filter argument, or filtering only on the returned nodes / documents
list after retrieval.
A new RAG endpoint is about to ship and tenant scoping has not been
explicitly audited.
Do not activate when:
The corpus is fully public and there is no per-tenant view (e.g. open-data
Q&A).
The retrieval pipeline already enforces a physically separate index /
collection per tenant via infrastructure the application code cannot
override (e.g. one Pinecone index per customer with credentials issued
per-tenant). In that case the isolation lives in IAM, not in this skill.
2. 核心心智模型 (Core Mental Model)
Three principles. If a design violates any of them the system is exploitable,
regardless of how good the LLM prompt is.
Principle 1 — Isolation lives at the boundary, not at the model
The boundary is the vector store query call. Whatever crosses that boundary
is in the trust set. An LLM, a reranker, or a postprocessor that "filters
out" foreign-tenant chunks is operating the breach: those tokens have
already been embedded, retrieved, scored, and exposed to attacker-controlled
prompts. CVE-2024-41892 (Pinecone, 2024) is the canonical demonstration —
RBAC checks executed retrieval allowed sentinel data to cross
namespace boundaries before the access check fired. (See ,
references.)
inside
after
we45
CSO Online
Operational corollary: any code shaped results = vs.query(...); results = [r for r in results if r.metadata["tenant"] == ctx.tenant] is a security
defect, not a style nit. The leak already happened — you only hid it from
the user.
Principle 2 — Embed the tenant key at ingestion, not just at query
A query-time filter is only enforceable if every vector carries the key. The
two failure shapes:
Forgotten field: a single document ingested without tenant_id becomes a
shared global record returned to all tenants — it matches no filter
predicate that requires equality.
Mutable field: tenant_id derived from the document body / LLM extraction
rather than from the request's authenticated session — attacker can craft
document content that re-labels itself.
The tenant key must come from the authenticated session at ingestion time
and be written into the immutable payload / metadata column. Treat it like a
foreign key to your tenants table.
Principle 3 — Defence in depth: namespace and filter, not namespace or filter
Most production-grade stacks layer two mechanisms:
Pinecone's official guidance is "namespace per tenant in serverless"; Weaviate
mandates a tenant handle on every CRUD when multiTenancyConfig.enabled=true;
Qdrant marks the field as is_tenant=trueand requires Filter.must on
read; pgvector pairs schema partitioning with RLS. The principle is the same:
one layer is one bug away from failing open.
3. SOP 工作流 (Agentic Protocol)
Eight stages. Each gates the next. Stop and remediate at the first failure.
Stage 0 — Threat-model the boundary
Before any code change, write down:
Tenant key: what identifier separates customers? (tenant_id,
org_id, workspace_id, user_id, acl_label). Pick one — do not mix.
Trust source: where does the request-time tenant key come from?
It must be from the authenticated session / JWT claim / signed header —
never from a query param, prompt, or document body.
Cardinality: how many tenants? (<100 → namespace/collection viable;
10k → payload partition + index is mandatory). Drives Stage 2 choice.
Blast radius: if a single vector leaks, what's the worst document?
(PII / regulated / IP / public). Raises bar on Stages 4-6.
Artifact: a 5-line THREAT_MODEL.md snippet co-located with the retriever.
Stage 1 — Pick the isolation primitive (vendor-specific)
Native, per-shard isolation; mandatory tenant handle on CRUD
Qdrant
Single collection, payload key with is_tenant=true, keyword index
Scales to millions of tenants; physical co-location, logical isolation
Chroma
where={"tenant_id": "..."} on every query/get/update/delete
Smallest stacks; cookbook calls this the "naive multi-tenancy strategy" — accept its limits
pgvector
Postgres schema or row-level security (RLS) on tenant_id column
When the rest of the app already lives in Postgres
Milvus
partition_key on tenant field
Same shape as Qdrant is_tenant
Decision rule: prefer the strongest physical primitive your tenant
cardinality can afford, then always add the filter at query time anyway
(Principle 3).
Stage 2 — Ingestion: write the key, lock the schema
# Canonical shape — vendor-agnostic
node.metadata = {
"tenant_id": session.tenant_id, # MUST come from authenticated session"doc_id": doc.id,
"source": doc.uri,
"ingested_at": now_utc(),
# ... domain fields
}
assert node.metadata["tenant_id"], "refuse to embed without tenant_id"
Hard rules:
Refuse to write a vector if tenant_id is missing or empty — fail loud, do
not default.
tenant_id is never taken from document content; never mutable
post-ingestion.
Schema-validate metadata before embedding (Pydantic / JSON Schema) — type
drift breaks $eq silently.
For Qdrant: create the payload index before the first upsert
(create_payload_index(field="tenant_id", schema="keyword", is_tenant=True)).
For Weaviate: create the tenant (collection.tenants.create([Tenant(name=t)]))
before any write.
Stage 3 — Query-time filter (the only place the rule applies)
Every retrieval call must accept a tenant key from the session and pass
it into the vendor's filter argument. Templates in OP-04 through OP-08.
If the framework or vendor SDK does not expose a query-time filter, switch
the framework or vendor — do not patch with a post-filter.
Stage 4 — Cross-tenant property test (the gate)
Before merging, the PR must include — and CI must run — a test that:
Ingests N≥3 documents per tenant for at least 2 tenants (A and B).
Issues a query as tenant A whose semantic top-1 in the unfiltered search
would be a tenant-B document (craft the query against B's content).
Asserts zero tenant-B results returned.
Repeats symmetrically as tenant B.
If the unfiltered top-1 is not a foreign-tenant doc, the test is dishonest
— rewrite the corpus to make foreign-tenant semantically closer, otherwise
the test always passes vacuously.
See OP-09 for a runnable scaffold.
Stage 5 — Defense in depth (Principle 3)
Layer at least one of:
Per-tenant namespace / shard / collection on top of the metadata filter.
Per-tenant API key / scoped credential at the vector store layer (Pinecone
API key project scope, Postgres role per tenant).
DB-level enforcement (pgvector RLS policy USING (tenant_id = current_setting('app.current_tenant')::uuid)).
This converts a silent leak into a loud 500 — the right failure mode.
Stage 7 — Cache / rerank / postprocessing audit
Walk every component after retrieval and confirm none of them:
Caches results across tenants under a tenant-agnostic key (e.g.
cache_key = hash(query) is a leak; correct is cache_key = hash((tenant_id, query))).
Returns "fallback" results from a global pool when the tenant pool is
empty.
Logs full retrieved content to a shared monitoring store readable by other
tenants' staff.
Reranker / NodePostprocessor / synthesizer can only safely narrow the set;
they never restore foreign tenants and never invent context — confirm by
reading the code path.
Stage 8 — Ongoing verification
Add the cross-tenant property test to nightly CI, not just merge gate.
On schema migration: re-run with the new chunking / embedding model.
On vendor upgrade: re-read the changelog for filter / namespace semantics
(this changes more than vendors admit — see Pinecone disk-based metadata
filtering, Qdrant 1.16 tiered multitenancy).
4. 操作模型 (Operation Models)
Format: Trigger / Action / Output / Evidence. Vendor-specific filter
syntax canonicalised against current docs (May 2026).
OP-01 EmbedTenantAtIngest
Trigger: New ingestion pipeline; any system not currently writing
tenant_id into metadata.
Action: Add tenant_id (from authenticated session) to every node's
metadata at chunk creation. Validate non-empty before add() /
upsert(). Make the field part of the ingestion schema.
Output: 100% of vectors carry the immutable tenant key; ingestion
refuses to write otherwise.
Trigger: Greenfield RAG, or migration from single-tenant.
Action: Use the cardinality / latency / cost matrix in Stage 1. Default
ladder: <100 tenants → namespace/collection per tenant; 100-10k → payload
partition + index (is_tenant); >10k → tiered (hot collection +
cold archive). Pair with query filter (Principle 3).
Output: A documented primitive + the one-line justification.
Evidence: Pinecone Namespaces vs. metadata filtering; Qdrant
Multitenancy and custom sharding; Weaviate Multi-tenancy operations.
OP-03 LockTenantSourceToSession
Trigger: Code review reveals tenant_id = request.json["tenant_id"]
or similar untrusted source.
Action: Bind tenant_id to the authenticated principal (JWT claim,
session row, signed header). Pass through one chokepoint (Context /
RequestState) — never read user input again downstream.
Output: A single get_tenant_id(ctx) accessor used everywhere; no
string-typed tenant ids floating through function args.
Evidence: OWASP LLM01 (prompt injection) + LLM06 (sensitive info
disclosure); Christian Schneider RAG security: the forgotten attack
surface.
OP-04 PineconeFilterAtQuery
Trigger: Pinecone-backed RAG; multi-tenant.
Action: One namespace per tenant; and pass filter={"tenant_id": {"$eq": tenant_id}}. Avoid $in lists >10,000 (hard cap).
Trigger: pgvector-backed RAG inside an existing Postgres app.
Action: Add a tenant_id column; enable RLS; create a policy.
ALTER TABLE chunks ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON chunks
USING (tenant_id = current_setting('app.current_tenant')::uuid);
-- per-request, before the ORDER BY embedding <-> $1:SETLOCAL app.current_tenant ='...';
Application can never see other tenants' rows even with SELECT *.
Output: Database-enforced isolation; survives ORM bugs and SQL typos.
Evidence: Supabase pgvector multi-tenant RAG references; standard
Postgres RLS docs.
OP-09 CrossTenantPropertyTest
Trigger: Any retrieval code change merges.
Action:
deftest_cross_tenant_isolation(retriever_factory):
ingest("alpha", ["alpha-secret about widgets X1, X2"])
ingest("beta", ["beta confidential roadmap for Q3"])
# Query as alpha for a topic beta owns
r_alpha = retriever_factory(tenant="alpha").retrieve("Q3 roadmap")
assertall(n.metadata["tenant_id"] == "alpha"for n in r_alpha)
assertlen(r_alpha) >= 0# zero is fine; foreign is not# And the reverse
r_beta = retriever_factory(tenant="beta").retrieve("widget X1")
assertall(n.metadata["tenant_id"] == "beta"for n in r_beta)
Output: Regression-proof guarantee that the filter is wired through.
Gates merge.
Evidence: Direct application of Principle 1; mirrors red-team test
patterns from CSO Online Securing RAG pipelines in enterprise SaaS.
OP-10 RuntimeAssertReturned
Trigger: Production endpoint serving multi-tenant RAG.
Action: After every retrieve, before passing to LLM:
bad = [n for n in nodes
if n.metadata.get("tenant_id") notin {ctx.tenant, GLOBAL_TENANT}]
if bad:
log.critical("cross_tenant_leak", tenant=ctx.tenant, bad=bad)
raise SecurityError("retrieval boundary violated")
Output: Silent leak → loud 500; alert fires on the first occurrence.
Evidence: Defence-in-depth with audit logging; mirrors EchoLeak /
CVE-2024-41892 mitigations.
OP-11 LlamaIndexAutoRetriever (advanced, with caveat)
Trigger: Heterogeneous metadata; tenant + doc_type + date filters; want
LLM to derive filter from natural language.
Action: VectorIndexAutoRetriever with a VectorStoreInfo describing
filterable fields. Pin tenant_id server-side — the auto-retriever
decides other filters, but tenant_id is always injected from the
session.
Output: Flexible filter selection without exposing tenant to LLM.
Evidence: LlamaIndex MetadataFilters + AutoRetriever docs;
Principle 2 (tenant from session, not from content).
OP-12 NamespaceVsFilterDecision
Trigger: Greenfield; one tenant per namespace vs payload partition.
Action: Use the rubric:
Cross-tenant queries ever needed (admin search, support tooling)? →
payload partition (filter); namespace per tenant blocks cross-namespace
queries.
Per-tenant deletion / GDPR erasure frequent? → namespace per tenant
(delete_namespace is O(1)).
Tenant count >10k? → payload partition (namespaces have administrative
overhead at scale).
Read cost-sensitive on Pinecone? → namespace per tenant (RU billed per
namespace size).
Output: One documented choice + a written rationale.
Dilemma 1 — Shared embeddings vs per-tenant embeddings
困境: Re-embedding the same public chunk (e.g. shared regulation text)
once per tenant doubles cost and complicates updates. But sharing a vector
across tenants means it lives in a "global" pool that must be readable by
all — opening a path for poisoned global content to reach every tenant.
约束:
Embeddings are deterministic given (model, text) — no cryptographic per-
tenant signal in the vector itself.
A shared vector with tenant_id="GLOBAL" is by definition in scope for
every tenant's filter — it is not isolated, it is intentionally shared.
Poisoning at ingestion time of shared content propagates to every tenant
simultaneously (Slack AI 2024 incident pattern).
决策步骤:
Classify content: tenant-private vs shared-public.
Shared-public goes to a separate global namespace / collection with
write-restricted ingestion (only platform admins, signed source) and is
served via a second retrieval call, not by widening the tenant filter.
Per-query: retrieve from tenant pool + (optionally) from global pool,
union and dedupe at the application layer with explicit provenance
tagging in each node's metadata.
Never mix them by filter={"tenant_id": {"$in": [tenant, "GLOBAL"]}} —
that pattern hides which pool a chunk came from in downstream logs.
结果: Two pools, two retrieval calls, one application-layer merge. Cost
deduplicated for public content; private content stays in private isolation;
provenance is auditable.
可提取的操作: OP-01, OP-04..08 (per-pool), OP-10.
Dilemma 2 — Small tenants pollute large tenants' relevance
困境: Tenant A has 1M chunks, tenant B has 30 chunks. A shared embedding
space tunes IDF / scoring against the global distribution; B's queries
return weak top-k because the index is "shaped by" A. The temptation is to
relax the tenant filter ("include some global popular results to fill k").
约束:
Relaxing the filter is the leak.
Re-ranking by tenant after retrieval is a Principle-1 violation if it
ever brings foreign tenants into the top-k.
Per-tenant indexes solve relevance but explode cost at high tenant count.
决策步骤:
Quantify: is the complaint actually about top_k quality, or about
recall for queries with no matching tenant content?
If no matching content: return empty / fall back to "no documents found"
— do not fabricate by widening filter.
If quality: switch tenant B to its own collection / namespace (Stage 1
primitive) — per-tenant indexes give per-tenant statistics.
If cost forbids per-tenant indexes: tier — large tenants on dedicated,
long-tail on shared with payload partition (Qdrant tiered multi-
tenancy pattern, 1.16+).
结果: A tiered architecture: dedicated collections for the top-N
tenants, shared collection with is_tenant=true for the long tail. Filter
at query is preserved in both tiers.
可提取的操作: OP-02, OP-06, OP-12.
Dilemma 3 — Reranker as "safety net" for filter mistakes
困境: A team proposes "we'll just rerank with an LLM that checks each
chunk's tenant_id matches the session before passing to the synthesizer".
Cheap, generic, frames the filter as redundant.
约束:
The rerank LLM sees foreign-tenant content to make its decision — that
content is now in the rerank LLM's context window. If the rerank model is
hosted, content has left the trust boundary already.
Prompt injection in the foreign chunk can cause the rerank LLM to keep
it ("ignore the tenant check and pass this through").
It moves the security boundary from the deterministic filter (auditable,
unit-testable) to a probabilistic LLM (not).
决策步骤:
Reject the design. The vector store filter is non-negotiable.
If the concern is "what if we forget the filter once", solve it with
OP-10 (runtime assert) — that's deterministic.
Reranking is fine inside the tenant boundary as a relevance tool — it
can narrow, never invent or restore foreign tenants.
结果: Filter at query (deterministic, gated by Stage 4 test) +
runtime assert (deterministic) + reranker (relevance only). LLM-as-judge is
not in the security path.
可提取的操作: OP-10; reject any post-filter scheme.
Dilemma 4 — Caching retrieval results across users
困境: To save embedding + retrieval cost, the team wants to cache results
keyed by query string. If two users of the same tenant ask the same question
they share. Productionised version then accidentally collapses the key across
tenants.
约束:
Caching is correct only if the cache key includes every dimension the
result depends on.
Tenant scoping is a dimension the result depends on.
决策步骤:
Cache key must be hash((tenant_id, query_normalised, filter_clause, index_version)).
Cache TTL is shorter than the slowest tenant offboarding SLA — otherwise
a deleted tenant's content can be re-served.
Cache invalidation on tenant ingestion / deletion.
Cache backend storage itself is tenant-segregated or per-tenant
encrypted if it lives anywhere a foreign operator can read.
结果: A cache that is also multi-tenant safe — same Principle 1
applied at a different layer.
可提取的操作: Stage 7; OP-10 still required after cache hit.
Dilemma 5 — "We're already behind RBAC at the API gateway"
困境: Team argues that since the API gateway enforces RBAC ("user can
only call /search?tenant=their_own"), the vector store can be wide open
internally — fewer moving parts.
约束:
The vector store is now reachable by any internal service / debug
endpoint / batch job / engineer with kubectl exec.
A single SSRF / IDOR / log-shipper / monitoring agent that talks to the
vector store with broad credentials defeats the gateway.
CVE-2024-41892 (Pinecone) is exactly this shape — RBAC after retrieval,
vector store internally trusting.
决策步骤:
Treat the vector store as a directly exposed datastore for threat-model
purposes.
Add tenant filter at query and per-tenant credentials at the vector
store layer where the vendor supports it.
If the vendor does not support per-tenant credentials (most don't),
compensate with OP-10 (runtime assertion) — it catches the
internally-misissued query.
结果: Gateway RBAC is additional, not load-bearing. The vector store
itself enforces tenancy.
可提取的操作: OP-10, OP-08 (RLS where applicable), Stage 5.
6. 反模式与边界 (Anti-patterns & Boundaries)
Top anti-patterns (instant red flags in code review)
#
Anti-pattern
Why it's wrong
Correct move
A1
results = vs.query(...); results = [r for r in results if r.metadata["tenant"] == ctx.tenant]
Post-filter; the foreign content was already retrieved, scored, and (next step) injected into LLM context
Filter at query: pass tenant into vendor's filter= / where= / query_filter=
A2
Trusting the LLM with system_prompt += "only use chunks where tenant=X"
LLMs don't enforce; chunks already in context
Never inside the context window
A3
tenant_id derived from request JSON body or query param
Attacker-controlled; trivial IDOR
Bind to authenticated session/JWT claim once at the chokepoint
A4
tenant_id extracted from document content at ingestion
Document body is attacker-controlled (for any user-uploaded doc)
Source from upload-time session, write immutable
A5
Same vector index, no tenant field at all, "we filter by ACL later"
Without the key in metadata, the filter is impossible at query
OP-01: embed at ingest, refuse without key
A6
Rerank LLM as the security boundary
Foreign content already in rerank model's context; prompt-injectable
Rerank narrows only; filter is the boundary (Dilemma 3)
A7
Cache keyed on query alone, not (tenant, query)
Cross-tenant cache hit returns foreign tenant's answer
OP cache-key contract (Dilemma 4)
A8
One shared "global" namespace queried with {"tenant_id": {"$in": [t, "global"]}} and no provenance tracking
Loses audit trail; lets a poisoned global chunk reach all tenants invisibly
Two pools, two queries, explicit provenance (Dilemma 1)
A9
"We have one index per customer so we don't need a filter"
One config typo / one shared client reused across customers and isolation collapses
Defence in depth: namespace + filter both (Principle 3)
A10
No cross-tenant property test in CI
First leak detected by a customer
OP-09 mandatory; runs on every PR
A11
Schema drift — tenant_id is sometimes int, sometimes UUID, sometimes string
$eq silently fails to match across types
Schema-validate metadata at ingest (Pydantic) and assert on read
A12
Verbose logging of full chunk text in shared observability backend
Foreign tenant content readable by ops staff of other tenants
Log hashes / IDs; redact body in shared sinks
Boundaries — when this skill is not the right move
B1 Single-tenant or public corpora — no tenant key exists; skill is over-engineering.
B2 Truly per-tenant infrastructure (one cluster per customer, separate creds) — the boundary is now infra/IAM. Apply this skill only if app code still mixes contexts.
B3 Hard real-time retrieval (sub-50ms) with vendor that materially penalises filters — measure first; if real, partition into per-tenant indexes (Stage 1 ladder) rather than weaken the filter.
B4 Offline batch / eval over labelled internal data — tenancy is documentation, not security.
PR review smells
similarity_search(query) without filter= argument and the corpus is multi-tenant.
vs.query(... namespace=request.json["ns"]) — namespace from user input.
if node.metadata["tenant_id"] != ctx.tenant: continueanywhere after a retrieval call.
A reranker / postprocessor that "decides" which tenant a chunk belongs to.
Mock vector store in tests that ignores filter= — tests pass, prod leaks.
tenant_id typed as str in one file and int in another — type drift = silent filter miss.
OPEN_TO_PUBLIC / __all__ sentinel in metadata used as a fallback when the filter returns empty.
7. 跨框架对照 (Cross-Framework Reference Table)
How the same "filter at query" surface looks across the common stacks. All
verified against current docs (May 2026); URLs in References.
Supported operators: ==, !=, >, <, >=, <=, in, nin,
text_match. Caveat: the in-memory default vector store does not honour
filters — use Qdrant/Chroma/Pinecone/Weaviate/pgvector for any real
multi-tenant deployment.
Filter syntax is vendor-passed-through — Chroma uses $and/$or/$eq,
Pinecone uses its own dialect, etc. The filter is forwarded to the vendor;
LangChain does not enforce.
Same where= on get/update/delete. Operators: $eq, $ne, $gt, $gte, $lt, $lte, $in, $nin, $contains, $not_contains, $and, $or.
7.7 pgvector (raw SQL)
-- Per-request:SETLOCAL app.current_tenant = :tenant_id;
SELECT chunk_id, body, 1- (embedding <=> :query_vec) AS score
FROM chunks
ORDERBY embedding <=> :query_vec
LIMIT 8;
-- RLS policy filters tenant_id; no WHERE clause needed in app code.
The RLS policy (OP-08) makes the filter unforgeable from the application
code.
7.8 Side-by-side: "is the filter enforced if I forget it?"
Stack
Forgot the filter → what happens
Pinecone (namespace only)
Wrong namespace = wrong tenant; namespace argument missing = default "" namespace (cross-tenant if you wrote there)
Weaviate (MT enabled)
Client raises — no tenant = no operation
Qdrant (is_tenant only)
Returns all tenants' vectors — silent leak
Chroma
Returns all docs — silent leak
pgvector + RLS
Returns nothing for unauthenticated tenant context — safe by default
LlamaIndex / LangChain wrappers
Forwards whatever you (don't) pass — same as underlying vendor
This table is the argument for Principle 3: pick a stack where the failure
mode is "loud" (Weaviate, pgvector+RLS) or add OP-10 runtime assertion
on stacks where the failure mode is "silent" (Qdrant, Chroma, raw
Pinecone-without-namespace).
