MLOps

RAG access control: checking permissions in real time

RAG access control: AWS now checks document permissions in real time at the source. Why replicated ACLs fall short, and what to change in your pipeline.

RAG access control: checking permissions in real time

RAG access control: checking permissions in real time

Most enterprise RAG assistants answer a question their builders rarely test: is this person allowed to see this answer right now? On October 7, 2026, AWS described how Amazon Quick and Amazon Bedrock Knowledge Bases now verify document permissions in real time, at query time, against the system that actually owns those permissions. RAG access control has quietly become the part of the stack that decides whether an AI assistant is safe to roll out company-wide.

The announcement itself is modest. What matters is the admission behind it: the default pattern of copying permissions into the index and filtering on them is not enough. This article walks through why, how the two-stage design works, what it costs, and what you should change in your own pipelines.

Background

A Retrieval Augmented Generation (RAG) system works in two steps. It first retrieves the passages closest to the user's question, usually through semantic search over a vector index. It then hands those passages to an LLM as context to write the answer.

The security problem is easy to state. The LLM knows nothing about permissions. If a passage from a restricted document lands in its context window, the model can summarize it, quote it or paraphrase it. Every access decision therefore has to happen before a passage reaches the model.

AWS puts the stakes plainly: a single unauthorized document surfaced in an AI response could expose confidential strategy documents, unreleased financial data or sensitive HR information. OWASP lists the same risk in its 2025 Top 10 for LLM applications as LLM08: Vector and Embedding Weaknesses, which explicitly calls out unauthorized access and cross-group leakage in shared vector databases.

Why replicated ACLs fall short for RAG access control

The common approach is to copy access control lists (ACLs) from each source into the index. Every chunk is stored with metadata such as "visible to group X", and retrieval filters on that metadata. It is fast, simple and supported by nearly every vector database.

AWS identifies three structural weaknesses.

The copy is not the source of truth

The index holds a replica of permissions, not the permissions themselves. Connectors must translate very different models faithfully: Google Drive sharing, SharePoint site inheritance and Confluence page restrictions follow different rules. Each translation is a chance to get it wrong.

Permissions go stale between syncs

ACLs arrive through periodic sync jobs, so the index always reflects some past state. As the AWS post notes, a user whose access was revoked might still receive AI answers from documents they should no longer see. Picture someone moving off a sensitive project: until the next sync, their assistant keeps drawing on documents from their old scope.

Connector logic is brittle

When a source introduces a new permission feature, the connector does not know about it yet. Until it is updated, there is an enforcement gap, and that gap is silent. Nothing breaks; answers keep flowing.

How the two-stage design works

AWS does not drop index-level filtering. It adds a second gate behind it.

Stage 1: pre-retrieval filtering

Amazon Quick first runs semantic search against a vector index that stores access control attributes. This produces a shortlist of candidate documents the user should be able to read, according to the last sync.

AWS keeps this stage for cost reasons: calling the source API in real time for every document in the index would be too expensive at scale. Pre-filtering shrinks the problem; it is not the security guarantee.

Stage 2: real-time verification at the source

For the candidates only, the system then queries the authoritative source. In the example AWS details, that means the Google Drive APIs, called with service account credentials and user impersonation, so the check asks Google Drive whether this specific person can open this specific file. Only authorized passages are passed to the LLM.

The stated outcome: permission revocations show up in AI responses "within moments, not hours or days". AWS cites Mondelēz International, where more than 35,000 employees across four regions use Amazon Quick.

The post says the real-time check sits on top of pre-retrieval filtering for both Amazon Quick and Amazon Bedrock Knowledge Bases. It only walks through the Google Drive case, though, and does not list supported connectors, describe behavior when a source API is down, or quantify the latency overhead. Check those details in your service's documentation before relying on them.

Real-time RAG access control: costs and blind spots

The second gate is not free. Every query now triggers extra calls to source APIs, with three practical consequences.

Latency. Each candidate check adds a network round trip, even when calls run in parallel. In a chat interface, every hundred milliseconds is noticeable.

Rate limits. Google Drive, Microsoft Graph and Confluence APIs are throttled. An assistant used by thousands of people can eat a real share of those quotas and starve your other integrations.

Availability. When the source API misbehaves, you have to choose between refusing to answer (security first) and falling back to cached permissions (availability first). AWS does not address this. Where leakage is the main risk, failing closed should be the default.

Two neighboring risks remain untouched. The first is content that is wrongly shared at the source: if a sensitive file is open to everyone in Drive, the real-time check will faithfully confirm that everyone can read it. The second is index poisoning, which OWASP files under the same LLM08 entry: a booby-trapped document the user is legitimately allowed to see can still inject instructions into the context.

What this means for AI teams

You may never touch Amazon Quick, but the pattern carries over to any RAG pipeline. Here is what we would check on a production system.

Treat the index as a cache, not an authority. ACLs in your vector store narrow the search space. The final decision belongs to the source, or to an authorization service that mirrors it closely and recently.

Measure your sync gap. How long does it take for a revocation in SharePoint to reach your assistant? If nobody knows, instrument that first. A simple test: remove a test account's access to a document and time how long the assistant keeps citing it.

Verify candidates only. Real-time checks are sustainable only on a handful of documents per query. Keep top-k reasonable before verification, and cache positive decisions for a short, explicit window such as a minute.

Decide what happens on failure. Document how the assistant behaves when the source API does not respond, and test it. A clear refusal ("I can't verify your access to these documents right now") beats a silent leak.

Log every decision. For each answer, keep the candidate list, what was filtered out and why. OWASP recommends immutable audit logs of retrieval activity, and they are what you will need when a DPO or auditor asks questions after an incident.

Evaluate with different identities. RAG evaluation sets almost always score relevance and almost never score permission compliance. Add test cases where the correct answer for a given profile is "I don't have access to that information".

Handled this way, RAG access control becomes a measurable property of the system, tracked alongside latency and cost per query in your MLOps dashboards.

Key takeaways

  • AWS now adds a real-time permission check against the source system on top of index-level ACL filtering, for Amazon Quick and Amazon Bedrock Knowledge Bases.
  • Replicated ACLs are still useful for performance, but they go stale between syncs and depend on brittle connectors.
  • The gain is revocations honored within moments. The cost is latency, API quotas and a failure policy you have to define.
  • OWASP files these risks under LLM08 and recommends permission-aware vector stores and audit logs.
  • In your own pipelines, RAG access control should be measured, tested with multiple identities and logged like any other production property.

Industrialising AI agents? SeedVision offers 3-5 day AI audits and 15-30 day production rollouts. See the packages or book a 30-min call.

Cover photo: Photo by Towfiqu barbhuiya on Unsplash.