RAG and vector store security

Somebody asks the internal assistant a question and it answers with a paragraph from a document they were never allowed to open. Nothing was breached. The retrieval layer did exactly what it was built to do, and what it was built to do was read everything.

Why this happens

The index is almost always built by a service account with read access to the whole source system, because that is the only way to index it in one pass. Once the content is chunked, embedded and stored, the permissions that governed the original documents are no longer attached to anything. Retrieval then runs against the index rather than against the source system, so it silently bypasses the access control the organization believes it has.

That is the finding this work keeps producing, and it is worth naming plainly because it is neither exotic nor anyone’s mistake: it is the default behaviour of a naive pipeline, and it survives review because the pipeline is working as designed. It sits under OWASP LLM02 Sensitive Information Disclosure and LLM08 Vector and Embedding Weaknesses.

What we map

The unit of analysis is the retrieval path, traced end to end: source system and its access control model; the ingestion job, the identity it runs as and what it can read; chunking and what metadata survives it; the embedding model and where it runs; the vector store, its tenancy model and its filtering; the query path and whose identity it carries; and finally what reaches the prompt and what the user is shown as a citation.

Most organizations have never drawn this path. Drawing it is usually the point at which somebody in the room notices the gap without being told.

Tenant isolation at the vector layer

Isolation is tested rather than assumed, because the difference between a tenant filter applied in application code and a tenancy boundary enforced by the store is invisible until something skips the code path. We look at which mechanism is in use — separate collections, namespace partitioning, or a metadata filter attached at query time — and at what happens when a filter is absent, malformed, or supplied by the caller.

The tests are behavioural: a query from tenant A that should return nothing from tenant B, a filter removed, a filter contradicted, a retrieval issued through a path that skips the wrapper everyone assumes is mandatory. This is testing against a running system, so it happens only with signed authorization to a scope agreed in writing, as set out below.

Document permission inheritance

The question is simple to state and rarely answered: does the index respect the source system’s access control lists? We check whether permissions are captured at ingestion at all; whether they are stored per chunk or per document; whether they are evaluated at query time against the asking user; and — the one most often missed — what happens when a permission changes after indexing.

Single-tenant systems have the same failure with a different name: the boundary is no longer between customers but between departments, clearance levels and individual people, and the index flattens all of them the same way. A board pack, a disciplinary file and a salary review are all in the same wiki as everything else.

Chunk-level access control is the design answer: carry the source permissions onto every chunk, re-evaluate them against the asking user at query time, and reconcile revocations on a schedule short enough to matter. Where the source system’s model is too complex to mirror, the alternative is a narrower corpus rather than a hopeful filter.

Embedding leakage and inversion

Embeddings are not a hashing function and should not be treated as one. They retain enough of the source to support approximate reconstruction and to answer membership questions, so a vector store holding embeddings of confidential text is holding confidential data. Treating a vector database as a derived artifact of no sensitivity is the mistake: it typically has weaker access control, weaker backup handling and weaker retention discipline than the document store it was built from, while holding a representation of the same content.

The review covers who can read the store directly, whether its backups and snapshots are protected to the standard of the source, whether embeddings of regulated data are in scope of your retention and deletion processes, and whether deleting a source document removes its vectors.

Indirect injection through a poisoned corpus

A retrieval corpus is an instruction channel that nobody registers as one. If an attacker can get a document into the index — a support ticket, a submitted CV, a shared drive, a crawled web page, a wiki anyone can edit — they can place text the model will read as an instruction when it is retrieved. That is OWASP LLM01 Prompt Injection arriving indirectly, and it is the harder half of the category.

So the work enumerates every write path into the corpus and asks who can use it, what review stands between submission and indexing, whether retrieved content is delimited and marked as data when it reaches the prompt, and what the model is permitted to do if it obeys the instruction anyway. The last question is the one that decides the impact, which is why the retrieval design and the agent permission model have to be read together.

What you receive

  • A retrieval data-flow map from source document to prompt, with the identity at each hop and the boundary each crossing represents.
  • Isolation test results: what was attempted, what the system returned, and reproduction steps for anything that crossed a boundary.
  • A permission-inheritance review covering capture, storage, query-time evaluation and revocation.
  • Recommended design changes, separated into what closes a boundary now and what belongs in the next rebuild of the pipeline.

The sample report shows how a finding is written. Where the fix is architectural, it feeds secure AI environment establishment; where you need the whole application exercised rather than the retrieval layer, that is LLM application penetration testing. The pattern itself is set out in RAG tenant isolation.

How the work is bounded

The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.

Testing and adversary simulation are carried out only with signed authorization, to a scope agreed in writing.

Investigation and forensic work is delivered with appropriately licensed partners where the law requires it.

SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.

Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.

Questions we are asked

Does RAG security apply if we only have one tenant?

Single-tenant systems have the same failure with a different name: the boundary is no longer between customers but between departments, clearance levels and individual people, and the index flattens all of them the same way.

Can embeddings leak the original text?

Embeddings are not a hashing function and should not be treated as one. They retain enough of the source to support approximate reconstruction and to answer membership questions, so a vector store holding embeddings of confidential text is holding confidential data.

Do you need a copy of our documents?

A copy of your documents is not required and is usually declined. The work runs against your environment on a small, agreed sample, with representative test documents we supply where a negative case has to be proven.

How do we test retrieval isolation ourselves afterwards?

The repeatable check is a pair of test users and a canary document: index a document only one of them may see, then ask the assistant as the other. Wire it into your test suite and the boundary is verified on every release.

Check the boundary before someone else does

Describe the source systems you index, the vector store you use and how many tenants share it. The reply says what a review would cover and which parts would need authorization to test.

Discuss a scope