Secure Enterprise RAG: Enforcing User‑Level Access Controls for Safe AI Retrieval

In a Retrieval‑Augmented Generation (RAG) pipeline the first point at which data leaves the protected store is the retrieval step. Most security incidents arise because the retriever returns chunks that the caller is not authorized to see, even though the surrounding application may have performed authentication correctly. Authentication at the API or UI layer only answers “who are you?”; it does not enforce “what you may retrieve.” Authorization must be enforced inside the search tier before any candidate is passed to ranking, prompt assembly, or caching.

Typical leakage paths include:

• Shared vector indexes: without tenant‑aware filters, a similarity query can surface cross‑tenant documents.
• Cache keys lacking scope: if a cache is keyed only by query text, results from one tenant may be served to another.
• Re‑rankers: unauthorized chunks that enter the candidate set can influence the final ranking even if they are later removed.
• Logging and observability pipelines: raw prompts or retrieved passages written to logs without access controls can expose sensitive content.

To prevent these failures, the retriever must apply pre‑filtering based on explicit metadata attached to each chunk (e.g., tenant_id, user_id, group_id, classification). Row‑level security (RLS) rules are evaluated against the caller’s identity claims before any ranking occurs. This approach guarantees that unauthorized material never reaches downstream components such as re‑rankers, prompt templates, or model inference.

Practical implementation steps:

• Store permission attributes as queryable fields in the index schema.
• Propagate JWT or SAML claims (tenant, user, groups, policy version) from the application into the retrieval request.
• Apply RLS filters in the search engine query (e.g., tenant_id = :current_tenant AND allowed_group_ids CONTAINS :user_group).
• Isolate caches by including the same identity attributes in cache keys.
• Log request identity, applied filters, retrieved and rejected chunk IDs for auditability.

Compliance frameworks such as SOC 2, ISO 27001, NIST SP 800‑53, and the OWASP Application Security Verification Standard all require that access controls be enforced at the data source, not only at the application perimeter. Demonstrating that no unauthorized chunk reaches the model satisfies the “access control” and “audit logging” criteria of these standards.

In summary, secure enterprise RAG hinges on enforcing authorization at retrieval time, isolating shared resources, and providing verifiable logs that prove containment before any AI model processes the data.

In a Retrieval‑Augmented Generation (RAG) pipeline the moment data first enters the model path is the retrieval step. If authorization checks are applied only after the retriever has returned a candidate set, unauthorized chunks can already influence ranking, be written to intermediate caches, or appear in trace logs. This is the core risk that the containment principle addresses.

Pre‑filter retrieval means that tenant, user, group, and classification metadata are attached to every indexed chunk (e.g., tenant_id, user_id, group_id, policy_tags) and that the search service evaluates an access‑control list (ACL) before any ranking or vector similarity is performed. The result set therefore contains only chunks that the caller is permitted to see.

Post‑filter retrieval returns a broader candidate list, applies ranking, and then removes disallowed items. Although simpler to implement, this approach allows disallowed chunks to affect:

• Re‑ranking scores, potentially elevating authorized content that would otherwise be lower‑ranked.
• Cache keys that omit identity fields, creating cross‑tenant leakage.
• Observability payloads (traces, logs, prompt assembly records) that may expose sensitive text.

Practical implementation of pre‑filtering typically follows these steps:

1. During ingestion, store explicit ACL metadata with each chunk.
2. When a request arrives, extract identity claims from the JWT (tenant, user, groups, classification).
3. Pass those claims as filter parameters to the vector or hybrid search tier.
4. Enforce row‑level security in the query, e.g., WHERE tenant_id = :tenant AND allowed_group_ids && :user_groups.
5. Generate cache keys that include the same identity fields to guarantee isolation.
6. Log the request identity, applied filters, retrieved chunk IDs, and any rejected IDs for auditability.

Security standards such as SOC 2, ISO 27001, NIST SP 800‑53, and OWASP ASVS all require that access control be enforced at the point of data exposure. Pre‑filter retrieval satisfies this requirement by ensuring that unauthorized data never reaches the model, the cache, or the logging layer, thereby providing a verifiable containment boundary.

Consequently, the recommended default for enterprise RAG is pre‑filter retrieval. Post‑filtering should be treated as a fallback for non‑security‑critical use cases, not as a primary protection mechanism.

Before an enterprise RAG system can claim that it prevents data leakage, it must demonstrate that every retrieval decision is authorized and that no unauthorized chunk ever reaches the model. This proof consists of four observable artifacts: identity‑propagation logs, the set of filters applied at the search tier, a complete list of retrieved versus rejected chunk identifiers, and the results of adversarial query tests. Together they feed an audit‑ready access matrix that maps each request to the permissions that were evaluated.

Core evidence required

• Identity propagation logs: Capture the JWT claims (tenant_id, user_id, group memberships, policy version) that the application forwards to the retriever. Each log entry should record the request timestamp, the caller’s identity, and the exact filter payload sent to the search engine.
• Applied ACL filters: Store the row‑level security expression used for the request, e.g. tenant_id = current_tenant AND allowed_group_ids CONTAINS any(user_groups) AND policy_tags NOT IN blocked_tags. This proves that authorization occurs before ranking.
• Retrieved vs. rejected chunk IDs: Emit two immutable lists – one for chunk_id values that satisfied the filters and were passed to the prompt assembler, and another for chunk_id values that were filtered out. The lists must be signed or hashed to prevent tampering.
• Adversarial query tests: Periodically run synthetic queries that target known restricted documents. The test passes only if the rejected‑chunk list contains the targeted IDs and the retrieved‑chunk list does not.

Practical example

POST /retrieve
Headers: Authorization: Bearer <jwt>
Body:
{
  "tenant_id": "t-123",
  "user_id": "u-456",
  "filters": {
    "allowed_group_ids": ["g-finance","g-hr"],
    "policy_tags": {"exclude": ["confidential","export_controlled"]}
  }
}

The retrieval service logs the incoming claims, applies the filter expression, and returns two arrays:

{
  "retrieved_chunk_ids": ["c-789","c-101"],
  "rejected_chunk_ids": ["c-202","c-303"]
}

Audit‑ready access matrix

For each request, the matrix records:

• Request ID
• Caller identity (tenant, user, groups)
• Filter expression applied
• Retrieved chunk IDs
• Rejected chunk IDs
• Result of adversarial test (pass/fail)

This structure satisfies compliance frameworks such as SOC 2, ISO 27001, NIST 800‑53, and OWASP ASVS, which require demonstrable access control enforcement, immutable logging, and regular testing of security controls.