A Guide to Implementing Granular Access Control in RAG Applications
Audience: Security Architects, AI/ML Engineers, Application Developers
Version: 1.0
Date: 11 September 2025
1. Overview
This document outlines the technical implementation for enforcing granular, “need-to-know” access controls within a Retrieval-Augmented Generation (RAG) application. The primary mechanism for achieving this is through metadata filtering at the vector database level, which allows for robust Attribute-Based Access Control (ABAC) or Role-Based Access Control (RBAC). This ensures that a user can only retrieve information they are explicitly authorised to access, even after the source documents have been chunked and embedded.
2. Core Architecture: Metadata-Driven Access Control
The solution architecture is based on attaching security attributes as metadata to every data chunk stored in the vector database. At query time, the system authenticates the user, retrieves their permissions, and constructs a filter to ensure that the vector search is performed only on the subset of data to which the user is permitted access.
3. Step-by-Step Implementation
3.1. Data Ingestion & Metadata Propagation
The integrity of the access control system is established during the data ingestion phase.
- Define a Metadata Schema: Standardise the security tags. This schema should be expressive enough to capture all required access controls.
- Example Schema:
- doc_id: (String) Unique identifier for the source document.
- classification: (String) e.g., ‘SECRET’.
- access_groups: (Array of Strings) e.g., [‘NTK_PROJECT_X’, ‘EYES_ONLY_LEADERSHIP’].
- authorized_users: (Array of Strings) e.g., [‘user_id_1’, ‘user_id_2’].
- Ensure Metadata Inheritance: During the document chunking process, it is critical that every resulting chunk inherits the complete metadata object of its parent document. This ensures consistent policy enforcement across all fragments of a sensitive document.
Conceptual Code:
Python
def process_document(doc_path, doc_metadata):
chunks = chunker.split(doc_path)
processed_chunks = []
for i, chunk_text in enumerate(chunks):
# Each chunk gets a copy of the parent metadata
chunk_metadata = doc_metadata.copy()
chunk_metadata[‘chunk_id’] = f”{doc_metadata[‘doc_id’]}-{i}”
processed_chunks.append({
“text”: chunk_text,
“metadata”: chunk_metadata
})
return processed_chunks
3.2. Vector Storage
Modern vector databases natively support metadata storage. This feature must be utilised to store the security context alongside the vector embedding.
- Generate Embeddings: Create a vector embedding for each chunk’s text.
- Upsert with Metadata: When writing to the vector database, store the embedding, a unique chunk ID, and the whole metadata object together.
Conceptual Code (using Pinecone SDK v3 syntax):Python
# 'vectors' is a list of embedding arrays
# 'processed_chunks' is from the previous step
vectors_to_upsert = []
for i, chunk in enumerate(processed_chunks):
vectors_to_upsert.append({
"id": chunk['metadata']['chunk_id'],
"values": vectors[i],
"metadata": chunk['metadata']
})
# Batch upsert for efficiency
index.upsert(vectors=vectors_to_upsert)
3.3. Query-Time Enforcement
Access control is enforced dynamically with every user query.
- User Authentication & Authorisation: The RAG application backend must integrate with an identity provider (e.g., Active Directory, LDAP, or OAuth provider) to securely authenticate the user and retrieve their group memberships or security attributes.
- Dynamic Filter Construction: Based on the user’s attributes, the application constructs a metadata filter that reflects their access rights.
- Filtered Vector Search: Execute the similarity search query against the vector database, applying the constructed filter. This fundamentally restricts the search space to only authorised data before the similarity comparison occurs.
Conceptual Code:Python
def execute_secure_query(user_id, query_text):
# Authenticate user and get their permissions
user_permissions = identity_provider.get_user_groups(user_id)
# Example: returns ['NTK_PROJECT_X', 'GENERAL_USER']
query_embedding = embedding_model.embed(query_text)
# Construct the filter
# This query will only match chunks where 'access_groups' contains AT LEAST ONE of the user's permissions
metadata_filter = {
"access_groups": {"$in": user_permissions}
}
# Execute the filtered search
search_results = index.query(
vector=query_embedding,
top_k=5,
filter=metadata_filter
)
# Context is now securely retrieved for the LLM
return build_context_for_llm(search_results)
4. Secondary Defence: LLM Guardrails
While metadata filtering is the primary control, output-level guardrails should be implemented as a defence-in-depth measure. These can be configured to:
- Block Metaprompting: Detect and block queries attempting to discover the security structure (e.g., “List all access groups”).
- Prevent Information Leakage: Scan the final LLM-generated response for sensitive keywords or patterns that may indicate a failure in the upstream filtering.
Will's Blog 