Chat with us
  • Home
  • /
  • Blog
  • /
  • Private by Design: Permission-Aware, PII-Safe and Sovereign RAG for Regulated Industries
Private by Design: Permission-Aware, PII-Safe and Sovereign RAG for Regulated Industries

Private by Design: Permission-Aware, PII-Safe and Sovereign RAG for Regulated Industries

How to build RAG that respects permissions, keeps PII out of your vector store and can run air-gapped — with patterns for finance, healthcare, legal and government.

Key takeaways

  • A vector database is a database. It needs authentication, authorisation, isolation and deletion — and OWASP now lists vector and embedding weaknesses as a top-10 risk for LLM applications (LLM08:2025).
  • Embeddings can leak text. Morris et al. (EMNLP 2023) recovered 92% of 32-token inputs exactly from their embeddings, and most names in a clinical-notes dataset.
  • Apply permissions inside the retrieval query, not after it; tokenise PII before embedding; make deletion propagate to the vector store.
  • Regulated teams often also need sovereignty: your vector store, your embedding model, your keys — or no outbound requests at all.
  • troveGEN implements these patterns and is honest about its limits, including that no SOC 2 or ISO 27001 audit has been completed yet.

Why RAG changes your security model

Before RAG, an LLM answered from its training data and a prompt. With RAG, the application becomes a bridge between users and a corpus of documents — contracts, patient records, statements, internal memos. Whatever the retriever can reach, the model can quote. That makes retrieval the new access-control boundary. If the retrieval layer ignores who is asking, the model becomes an efficient tool for finding things a user was never meant to see.

The OWASP Top 10 for LLM Applications 2025 reflects this: LLM08:2025 Vector and Embedding Weaknesses was added in response to community requests for guidance on securing RAG and embedding-based systems. It overlaps with classic broken access control, and its concerns include unauthorised access across tenants, data leakage through embeddings and poisoned content in the index.

Pattern 1: permission-aware retrieval

There are two ways to enforce document-level permissions. Post-filtering retrieves the top-k results for the question and then removes the passages the user may not see. It is easy to bolt on — and it fails twice: the ranking has already been shaped by restricted content, and if the top ten results are all restricted you return nothing even though permitted answers exist at rank eleven. Pre-filtering applies the access rule inside the search itself, so only permitted passages compete for the top slots.

A sound implementation should:

  • Attach access metadata (owner, group, matter, region) to every chunk at ingestion.
  • Resolve the caller's identity from a signed assertion or identity-provider group membership, never from a field the browser can edit.
  • Apply the filter natively in the vector database query, and fail closed if the filter cannot be evaluated.
  • Keep an audit trail of who searched what and what was returned.

Pattern 2: tokenise PII before you embed it

Embeddings feel abstract, but they are not a safe encoding. In Text Embeddings Reveal (Almost) As Much As Text, Morris, Kuleshov, Shmatikov and Rush showed that Vec2Text, a multi-step method that repeatedly corrects a guess and re-embeds it, could recover 92% of 32-token text inputs exactly, and could extract a large share of first, last and full names from a dataset of clinical notes. The practical lesson is to treat a vector store as sensitive as the documents behind it.

The safest moment to handle a sensitive value is before it is embedded:

  1. Detect sensitive fields such as account numbers, national identifiers, phone numbers and patient names.
  2. Replace each with a reversible token.
  3. Store the originals in a separate, encrypted vault with its own access control.
  4. Index only the tokenised text, so raw values never reach the vector store or the prompt unless an authorised flow detokenises them.

Redacting after the fact is much harder: once a value has been embedded, removing it means re-embedding and purging the index.

Pattern 3: isolate tenants and make deletion real

  • Per-customer isolation. Separate schemas or namespaces per tenant so a bad filter cannot leak across customers.
  • Deletion that propagates. When a document is deleted at the source, the text, the chunks, the vectors and any cached answers should all go. If the vector purge fails, the delete should fail loudly rather than pretend to succeed.
  • Versioning with intent. Keeping earlier versions enables point-in-time questions ("what did the policy say last quarter?"), but delete must remove every version.
  • Secrets handling. Connector credentials should be encrypted at rest and write-only over the API.

Pattern 4: sovereignty — control the five boundaries

Regulated organisations often ask a simple question: where does our data go? In a RAG system there are at least five places to answer it:

  1. Vector storage — in your own account (Qdrant, Pinecone, pgvector or Postgres) or a hosted one.
  2. Embeddings — a hosted API, an OpenAI-compatible endpoint you operate, or a local model.
  3. Reranking — a hosted service, a self-hosted reranker, or an LLM.
  4. Generation — off by default if you only need retrieval, or a model you host with vLLM, Ollama or TGI.
  5. Content sources — connectors that read from your stores and never pull in paywalled or third-party material you have no right to index.

With a local embedder, reranker and language model, an air-gapped deployment makes no outbound request at all. For governments, defence suppliers, banks and hospital groups, that is often the difference between a pilot and a production approval.

Industry-specific considerations

IndustryTypical sensitive contentRetrieval requirement
FinanceAccount numbers, statements, loan filesTokenise identifiers; row-level citations; per-client isolation
HealthcarePatient names, clinical notes, reportsTokenise before indexing; complete lists; staff-only access; no clinical advice
LegalPrivileged and matter-confidential filesMatter-level access control; audit trail; precise clause citations
GovernmentCitizen records, internal notificationsData residency; air-gapped option; multilingual retrieval
Software and engineeringSource docs, contracts, customer ticketsTeam-based ACLs; sync with deletions; agent access via MCP with read-only default

How troveGEN implements private-by-design RAG

troveGEN was designed around these patterns rather than retrofitting them:

  • Permissions inside every search, using signed end-user assertions and identity-provider group membership, applied natively in the vector query and failing closed.
  • Sensitive data protected first: account numbers, national IDs and similar values are replaced with tokens before indexing, with originals in a separate encrypted vault.
  • Per-customer isolation through dedicated schemas and namespaces, and deletion that really deletes — a failed vector purge aborts the delete.
  • Versioning and point-in-time retrieval so earlier document states can be queried when permitted.
  • Bring your own vector database (Qdrant, Pinecone, pgvector, Postgres), your own embedding and reranking models and keys, or a fully air-gapped deployment with local models.
  • Read-only agents by default: the MCP server is read-only unless writes are explicitly allowed.

Honesty matters in security. troveGEN does not claim certifications it does not hold: no SOC 2 or ISO 27001 audit has been completed, self-hosting is your operational responsibility, and encryption is at rest and in transit rather than homomorphic. If your procurement process needs independent attestations, plan for that. If it needs architectural control over where data lives, that is where troveGEN is strongest. Read more at trovegen.com/sovereignty, or talk to Intellara about a sovereign deployment.

A security checklist for your RAG system

  1. Is access control applied inside the retrieval query, and does it fail closed?
  2. Where does each sensitive value live: source, chunk, vector, prompt, cache, logs?
  3. Can you delete a document and prove it is gone from the vector store?
  4. Are tenants isolated at the schema or namespace level?
  5. Do you know which of your five boundaries leave your environment?
  6. Can an agent write to your corpus, and who approved that?
  7. Do you have an audit trail for queries and results?

Further reading

Frequently asked questions

What is permission-aware RAG?

Permission-aware RAG enforces document-level access control during retrieval, so each user only receives passages they are allowed to see. The filter is applied inside the search query rather than after results come back, which prevents leaks and keeps recall high.

Can embeddings leak sensitive information?

Yes. Research by Morris et al. (EMNLP 2023) showed that an iterative method called Vec2Text could recover 92% of 32-token inputs exactly from their dense embeddings, including names from clinical notes. Embeddings should therefore be treated as sensitive as the text they encode.

Why tokenise PII before embedding instead of redacting it afterwards?

Once a sensitive value has been embedded and stored, removing it means re-embedding and purging the index. Replacing values with reversible tokens before indexing keeps raw values out of the vector store entirely, with the originals held in a separate encrypted vault.

What does 'sovereign' or 'air-gapped' RAG mean?

It means every component — vector storage, embedding model, reranker and any generation model — runs inside the customer's own boundary, so the system makes no outbound request. troveGEN supports bring-your-own vector databases (Qdrant, Pinecone, pgvector, Postgres) and a fully air-gapped mode with local models.

Is troveGEN SOC 2 or ISO 27001 certified?

Not yet. troveGEN states plainly that no SOC 2 or ISO 27001 audit has been completed. Its security model relies on architecture: tokenised PII, permission-aware retrieval, per-customer isolation, deletion that propagates, and the option to keep everything in your own environment.

Intellara Team

Intellara Team

The Intellara engineering team builds RAG pipelines, semantic search and AI products, including troveGEN.

Ready to operationalize AI in your business? Let us design and deploy the right solution together.

Chat with us