rag-security-architect

name

rag-security-architect

description

Design or review the security of a RAG / retrieval pipeline and its vector store (OWASP LLM08) — enforce authorization AT RETRIEVAL TIME so a query only ever returns documents the calling user and tenant may see (never post-retrieval filtering), scope every vector index/namespace by tenant, carry document-level ACLs into the query filter, and address embedding-specific risks (inversion, membership inference, poisoned documents, stale-permission re-embedding). Composes tenant-isolation-reviewer and multi-tenant-data-architect for tenant scoping rather than re-deriving it. Use when building or reviewing RAG retrieval, a vector store, or semantic search over access-controlled or multi-tenant data. Do NOT use for injection via retrieved content once in context (prompt-injection-defender), training-time corpus poisoning (model-poisoning-reviewer), disclosure in the completion (sensitive-disclosure-guard), or generic tenant-data design (multi-tenant-data-architect).

RAG Security Architect

Purpose

Design or review a retrieval-augmented-generation pipeline so that retrieval itself is access-controlled: a query returns only documents the calling user and tenant are authorized to see, enforced AT RETRIEVAL TIME in the query, never by filtering results after the store already returned them. The output covers vector-store tenant scoping, document-level ACL propagation into the retrieval filter, and embedding-specific risks (LLM08) — inversion, membership inference, document poisoning, and stale permissions in already-embedded content. Tenant-scoping semantics are composed from tenant-isolation-reviewer and multi-tenant-data-architect, not re-invented here.

Use When

• Use when: building or reviewing a RAG pipeline, vector database, embedding index, or semantic search over access-controlled or multi-tenant data.
• Use when: adding retrieval to an AI feature and retrieved documents have per-user or per-tenant access rules.
• Use when: a vector store is shared across tenants and you need to prove one tenant's queries cannot surface another tenant's documents.
• Do NOT use when: the risk is injected instructions in retrieved content once it is in context — that is prompt-injection-defender.
• Do NOT use when: the concern is poisoning the training/fine-tuning corpus (model-poisoning-reviewer) or sensitive data appearing in the completion (sensitive-disclosure-guard).
• Do NOT use when: designing the general tenant data layer with no retrieval dimension — multi-tenant-data-architect.

Inputs to Inspect

1. The retrieval architecture: vector store/index, how documents are ingested and chunked, what metadata is stored, how queries are built and filtered.
2. The access model for the source documents: who may see what, per-tenant and per-user/role/document ACLs — from authorization-matrix-designer / tenant-modeler output where it exists.
3. Where authorization currently happens: at retrieval (in the query) or after (filtering the returned set) — this is the central finding.
4. Tenant scoping of the store: shared index with a filter, namespace per tenant, or database per tenant; tenant-isolation-reviewer findings for the vector-store surface.
5. Ingestion/permission sync: what happens to embeddings when a document's ACL changes or a document is deleted; re-embedding and deletion paths.
6. Embedding/model details relevant to inversion and membership inference: what data is embedded, whether embeddings or raw chunks are returned to clients.

Workflow

1. Trace a query end to end. From user query → embedding → vector search → candidate set → filter → context assembly. Identify exactly where authorization is applied. No retrieval design to inspect → Stop Conditions.
2. Enforce authorization at retrieval time. The query MUST carry the tenant scope and the user's document-level permissions as filter predicates so the store never returns unauthorized vectors. Post-retrieval filtering is a finding: it means unauthorized documents were fetched, can leak via ranking/counts/latency, and one filter bug exposes everything.
3. Scope the vector store by tenant. Verify the isolation mechanism (namespace/index/collection per tenant, or a mandatory tenant filter that cannot be omitted) using references/rag-retrieval-authz.md. Compose multi-tenant-data-architect for the per-store scoping decision.
4. Propagate document-level ACLs into the index. Store the authorization metadata (owner, tenant, allowed roles/groups) alongside each chunk so it can be a query predicate. Decide how ACL changes and deletions propagate to embeddings — stale permissions on embedded content are a leak.
5. Address embedding-specific risks (LLM08): embedding inversion (raw source recoverable from vectors — don't expose embeddings to clients, consider the sensitivity of what's embedded); membership inference; and document poisoning (an attacker-planted document engineered to rank for a target query — cross-reference model-poisoning-reviewer for corpus integrity and prompt-injection-defender for payloads inside documents).
6. Design negative tests. Two-tenant fixtures where tenant A queries for tenant B's known content and must get nothing; user-without-access queries for a restricted document; a deleted/ACL-changed document must stop appearing. Hand executable form to multi-tenant-security-tester and suite encoding to ai-evaluation-harness.
7. Handle citations/evidence safely. Returned citations must not reveal existence or metadata of documents the user cannot access; snippet boundaries must not spill adjacent unauthorized content.

Output Format

RAG SECURITY DESIGN/REVIEW — <system>
Query trace: <query → embed → search → filter → context> | Authz point: <retrieval | POST (finding)>
Vector-store tenant scoping: <namespace/index/filter mechanism + can-it-be-omitted>
Document ACL propagation: <metadata stored | how ACL change/delete flows to embeddings>
Embedding risks (LLM08):
  Inversion: <embeddings exposed? sensitivity of embedded data>
  Membership inference: <exposure + mitigation>
  Poisoning: <ingestion trust + ranking abuse> (→ model-poisoning-reviewer)
Findings (severity-ranked): [SEV] <issue> — <leak path> — <fix>
Negative tests: <cross-tenant / no-access / stale-ACL cases> (→ multi-tenant-security-tester)
Citation safety: <no existence/metadata leak of unauthorized docs>
Not reviewed: <areas + why>

Validation Checklist

• The query trace pinpoints where authorization is applied; any post-retrieval filtering is flagged as a finding.
• Retrieval-time filter carries BOTH tenant scope and user document-level permissions; the tenant filter cannot be silently omitted.
• Vector-store isolation mechanism is named and its bypass conditions stated (composed from multi-tenant-data-architect, not re-derived).
• ACL-change and deletion propagation to embeddings is specified; stale permissions are treated as a leak.
• Embedding inversion, membership inference, and document poisoning are each addressed or explicitly ruled out with a reason.
• Negative tests include cross-tenant, no-access, and stale-ACL cases.
• Citations/snippets cannot reveal unauthorized documents' existence or content.

Security Rules

• Authorization is enforced at retrieval time, in the query — never by filtering results after the store returns them.
• The vector store is tenant-scoped by a mechanism that cannot be omitted by a forgotten filter; shared indexes require a mandatory, tested predicate.
• Retrieved content remains untrusted as INSTRUCTIONS even when authorized as DATA — retrieval authz does not make document content safe to obey (prompt-injection-defender owns that half).
• Deletion and permission changes must reach the embeddings; an index is a copy of the data and inherits its access rules.

Gotchas

• Post-retrieval filtering feels safe and is the most common leak: the store already searched all tenants' vectors, so ranking, result counts, latency, and one filter bug all leak — the fix is filtering INSIDE the query.
• "Namespace per tenant" only isolates if the namespace is derived server-side from the authenticated tenant; a client-supplied namespace is just an IDOR with extra steps.
• Embeddings are lossy but not safe: inversion attacks reconstruct source text well enough to leak PII — don't hand raw vectors to clients and weigh what you embed.
• Chunk overlap can spill: a snippet window that runs past the authorized chunk into the next document leaks content the user can't see.
• Deleting the source row but leaving the embedding is a classic residual leak — the "deleted" document keeps answering queries.
• Re-embedding after an ACL tightening is easy to forget; the old vector keeps the old (looser) permission until it's rebuilt.

Stop Conditions

• No retrieval pipeline, vector store, or query code is available — stop; this skill secures a concrete retrieval design, not a description.
• The tenant-isolation model itself is undefined — get tenant-modeler / multi-tenant-data-architect output first; retrieval scoping needs a tenant definition to enforce.
• A review finds an active cross-tenant leak in production — route to incident-response-runbook; containment is a human decision.
• The real issue is injected instructions, corpus poisoning at training time, or completion-side disclosure — hand to the owning skill.

Supporting Files

• references/rag-retrieval-authz.md — retrieval-time authorization patterns, vector-store tenant-scoping mechanisms and their bypass conditions, ACL propagation, and the embedding-risk (inversion/membership/poisoning) rubric.
• evals/evals.json — trigger + behavior cases.
• evals/trigger-evals.json — discrimination within the data & retrieval cluster and against multi-tenant-data-architect, tenant-isolation-reviewer, and multi-tenant-security-tester.