Chunk-Level Authorization

Unlike document-level security, which gates entire files, chunk-level authorization operates on the smallest retrievable units of text. This is critical because a single document often contains a mix of public and highly restricted information. By enforcing permissions at the chunk level, a system can safely retrieve the non-sensitive introduction of a report while completely blocking the classified financial projections in the next paragraph, maximizing data utility without compromising security.

Authorization decisions are typically enforced through metadata filtering on vector stores. Each chunk is indexed with key-value attributes (e.g., classification: 'internal', department: 'legal'). Before or during a similarity search, the user's authenticated context is translated into a boolean filter. The vector database then restricts its nearest-neighbor search to only those chunks whose metadata matches the filter, ensuring unauthorized content is never even considered for retrieval.

Two primary architectural patterns exist:

• Pre-Retrieval Filtering: The search scope is narrowed before the vector search executes. This is highly secure and performant but can cause recall issues if filters are too strict.
• Post-Retrieval Filtering: The system performs an unrestricted search first, then redacts or removes unauthorized chunks from the results. This preserves maximum recall but risks leaking sensitive information into the model's context window if the filtering logic fails. A robust system often uses a hybrid approach.

For chunk-level authorization to work, the end-user's identity must be securely propagated through the entire RAG pipeline. This process, known as identity propagation, ensures that the retrieval engine—not the application server—applies the user's specific permissions. Without this, a system might default to a service account with broad access, completely bypassing the fine-grained controls and leaking data across user privilege boundaries.

Chunk-level authorization is often paired with data masking and redaction. If a chunk is partially authorized, the system might not block the entire chunk but instead use a PII detection model to mask specific spans like names or credit card numbers before the text is sent to the LLM. This creates a dynamic, just-in-time sanitization layer that operates on the specific text segment, preserving the surrounding context for the model.

Implementing chunk-level authorization is a cornerstone of a zero-trust retrieval architecture. It assumes no implicit trust and requires explicit verification for every single chunk access request. This aligns with the principle of least privilege retrieval, granting the system access only to the minimum necessary text fragments required to answer a specific query, thereby minimizing the blast radius of a potential prompt injection or data exfiltration attack.

A coarse-grained authorization strategy that controls whether an entire document can be retrieved and injected into a prompt. Unlike chunk-level authorization, this approach treats the document as an atomic unit—either all chunks are accessible or none are.

• Mechanism: Access control lists (ACLs) or classification labels applied at the document metadata level
• Limitation: Fails when a single document contains both public and restricted information
• Use case: Highly classified repositories where documents are uniformly sensitive

A technique used in vector databases to restrict search results by applying boolean conditions to the key-value attributes associated with each document chunk. This is the primary enforcement mechanism for chunk-level authorization.

• Pre-filtering: Apply metadata constraints before the vector similarity search executes
• Post-filtering: Apply constraints after retrieving top-k results
• Common operators: eq, neq, in, exists, contains
• Example: filter: { "clearance": { "$lte": "SECRET" }, "department": "Engineering" }

A mechanism for attaching access control lists directly to vector embeddings or their chunk metadata. Each chunk inherits permissions from its source document but can be further restricted independently.

• Structure: Each vector entry carries a permissions field listing authorized user groups or roles
• Enforcement: The vector database engine intersects the user's identity with chunk ACLs during query execution
• Challenge: ACL explosion when millions of chunks have unique permission sets
• Optimization: Use role-based grouping to reduce the cardinality of permission entries

The secure transmission of the end-user's authenticated identity context through every layer of the RAG pipeline. Without this, the retrieval engine cannot apply user-specific chunk-level permissions.

• Flow: Identity Provider → Application → Retrieval Service → Vector Database
• Formats: JWT claims, SAML assertions, or opaque tokens passed via request headers
• Critical requirement: The vector database must trust the propagated identity without re-authentication
• Risk: Identity spoofing if intermediate services can forge user context

An authorization technique where initial search results are re-ranked or redacted after the vector similarity search completes. This acts as a safety net when pre-retrieval filtering is incomplete.

• Process: Retrieve top-k chunks → Evaluate each chunk's permissions → Strip unauthorized chunks → Pass remaining to LLM
• Advantage: Simpler to implement; doesn't require modifying the vector index
• Disadvantage: May return fewer than k results, degrading answer quality
• Hybrid approach: Combine with pre-filtering for defense-in-depth

The principle of granting a RAG system or user only the minimum necessary data access required to answer a specific query. At the chunk level, this means exposing only the fragments directly relevant and authorized.

• Implementation: Dynamic permission scoping based on query intent and user role
• Benefit: Reduces the blast radius of potential data leaks
• Challenge: Overly restrictive policies may prevent the retriever from finding sufficient context
• Best practice: Start with minimal access and expand based on observed retrieval quality metrics