Executive Summary
- Vector similarity search has zero built-in understanding of document permissions, Google Drive ACLs, or Active Directory groups.
- Relying on system prompts ('Only answer if authorized') is completely ineffective and trivial to bypass with prompt injection.
- Permission-aware RAG attaches document ACL group IDs to vector chunk metadata during the ingestion process.
- User JWT tokens are unpacked at query time to inject authorized group IDs into the vector search boolean pre-filter.
- Hardware bitset masks guarantee that unauthorized documents are mathematically excluded from nearest-neighbor search.
The internal data leakage vulnerability in enterprise RAG
When an organization indexes internal wikis, Google Drive folders, and Jira tickets into a vector database, it creates a consolidated semantic index.
However, in traditional corporate IT, an intern cannot access the board meeting minutes, and an engineer cannot read executive compensation sheets. If the vector search engine operates across the global index without checking permissions, an intern asking 'What are our planned layoffs for next quarter?' will receive an accurate, grounded answer containing confidential board transcripts.
Attempting to solve this by instructing the LLM: 'Do not reveal confidential info to non-executives' is completely futile. Security boundaries must be enforced at the retrieval layer, ensuring confidential chunks never reach the model's prompt.
The Ingestion Blindspot
When you vectorize a document, its SQL permissions and Google Drive ACLs do not follow it automatically into high-dimensional vector space. You must explicitly model and enforce access control.
How permission-aware RAG works: Ingestion ACLs & Query Tokens
A robust permission-aware RAG pipeline operates across two interconnected phases:
1. Ingestion Phase: When documents are parsed, the connector reads the file's access control lists (e.g. `allowed_groups: ['EXEC_BOARD', 'HR_LEADERSHIP']`, `allowed_users: ['sarah@acme.com']`) and tags these arrays as indexed metadata fields on every child chunk vector.
2. Query Phase: When a user submits a prompt, the gateway extracts the user's verified groups from their OIDC/SAML token and injects an intersection clause into the vector search filter (`allowed_groups $in user_groups`).
Prompt-Based Security vs Separate Indexes vs Query-Time ACL Filtering
Evaluating security guarantees, index maintenance overhead, and scalability across access control models.
Access control models compared
| Feature | Dimension | Prompt-Based Guardrails | Physical Index Per Group | Query-Time Metadata ACL Filtering |
|---|---|---|---|---|
| Security Guarantee | Zero (Easily bypassed via prompt injection) | High (Physical separation) | Absolute (Mathematical bitset exclusion) | |
| Maintenance Overhead | Low | Extreme (Managing 500+ distinct vector indexes) | Minimal (Single index with metadata tags) | |
| Support for User Group Changes | Immediate | Nightmare (Requires re-indexing across stores) | Instant (Changes reflected in next JWT token) | |
| Handling of Multi-Group Documents | Poor | Duplicate storage costs | Flawless (Array contains multiple group tags) | |
| Enterprise Compliance (SOC-2/ISO) | Rejected by auditors | Acceptable | Industry Best Practice |
Query-time ACL vector search TypeScript implementation
Below is a TypeScript implementation of a permission-aware vector search service extracting user claims from an authenticated context.
Synchronizing with Okta, Active Directory, and Google Workspace
When an employee transfers departments or leaves the company, their access changes immediately in Okta or Azure AD.
Because permission-aware RAG relies on dynamic query-time token evaluation rather than static hardcoded embeddings, an employee who loses access to the `FINANCE` group in Okta instantly loses the ability to retrieve finance chunks without requiring any vector re-indexing.
Handling complex nested folder and inherited file permissions
In platforms like SharePoint and Google Drive, permissions are frequently inherited from parent folder hierarchies.
Ingestion connectors resolve effective permissions recursively before vectorizing documents, flattening the inheritance tree into explicit array tags stored on each vector record.
Enterprise permission-aware RAG checklist
Audit your enterprise AI knowledge base against these security and access control standards.
Permission-aware RAG readiness checklist
1Access Control & Ingestion
- Document connectors extract explicit user and group ACLs during ingestion
- Recursive folder inheritance is flattened and tagged on every vector chunk
- Prompt-level security instructions are discarded in favor of deterministic query filters
2Query & Identity Governance
- Query-time ACL filters evaluate user claims extracted from verified JWT tokens
- Group membership changes in Okta/Active Directory reflect immediately in search results
- Automated penetration tests verify zero unauthorized retrieval across permission tiers