Skip to content
Security
Skill

/vector-store-isolation-test

Test that retrieval enforces per-user / per-tenant authorization so one user cannot retrieve another's documents through the RAG system. Use on an authorized multi-tenant or multi-user RAG app to validate access control on retrieval.

From plugin
awesome-claude-security
7111 skills17 agents13 commands1 MCP
Install
$ npx -y skills add jassics/awesome-claude-security --skill vector-store-isolation-test --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/vector-store-isolation-test

Context preview

The summary Claude sees to decide when to auto-load this skill.

Test that retrieval enforces per-user / per-tenant authorization so one user cannot retrieve another's documents through the RAG system. Use on an authorized multi-tenant or multi-user RAG app to validate access control on retrieval.

SKILL.md

vector-store-isolation-test.SKILL.md
name: vector-store-isolation-test
description: >-
  Test that retrieval enforces per-user / per-tenant authorization so one user
  cannot retrieve another's documents through the RAG system. Use on an authorized
  multi-tenant or multi-user RAG app to validate access control on retrieval.

Goal

Evidence on whether the retrieval layer leaks documents across users/tenants — the highest-impact RAG confidentiality failure (OWASP LLM08 / LLM02).

Prerequisites

  • Authorization, and ideally two test identities (User A and User B / Tenant A and

Tenant B) with distinct, identifiable documents.

Test cases

1. **Direct cross-tenant retrieval** — as User A, ask questions whose best answers live only in User B's documents. Does any B content surface? 2. **Filter bypass** — if isolation relies on a client-supplied filter/namespace, try altering or omitting it. Is authorization enforced server-side? 3. **Relevance-driven leakage** — craft queries semantically close to B's private docs to see if relevance overrides authorization. 4. **Metadata/citation leak** — even if content is withheld, are titles, sources, or snippets exposed via citations or errors? 5. **Embedding inversion (if applicable)** — can returned embeddings or similarity responses be used to reconstruct unauthorized source text?

Steps

1. Seed distinct, labeled documents under each identity. 2. Authenticate as User A and run the cases above; never use B's session to "prove" A's access. 3. Record per case: isolated / partial leak / full leak, with evidence (query, surfaced content/metadata, response). 4. Identify the gap: client-side-only filtering, retrieve-then-(not)-filter, shared index without ACLs.

Output

A results table: case · result · leaked element · evidence · mitigation (authorize-then-retrieve, per-tenant namespaces, server-side ACL enforcement). Confirmed leaks → `security-reporting:finding` (rate severity high+).

Notes

Authorization must be enforced on the **server** at retrieval time and tied to the authenticated caller — never trust a client-provided tenant/filter. Test the metadata/citation path too; it leaks even when document bodies are withheld.

Read more
Ships withawesome-claude-security

A Claude Code plugin marketplace for the full cybersecurity & GenAI-security lifecycle — from recon and threat modeling to detection engineering, GRC, and CISO-level strategy. A pentester knows which OWASP test bends a broken-access-control endpoint.

Get the whole plugin

Other skills on awesome-claude-security.