Amazon Bedrock adds live permission checks for enterprise RAG

Permissions move into the answer path

AWS has outlined a retrieval-augmented generation design that checks a user’s current document permissions before allowing retrieved material to reach a model. Published on 7 October, the official post focuses on Amazon Quick and Amazon Bedrock Knowledge Bases connected to enterprise repositories such as Microsoft SharePoint, Google Drive and Atlassian Confluence. The central problem is familiar: a knowledge assistant becomes useful only when it can search broadly, but that same reach creates a serious disclosure risk if its index contains documents a particular employee should no longer see.

The proposed architecture does not treat a periodically copied access-control list as the final authority. It first uses indexed access attributes to narrow the candidate set, then checks permissions with the original content system at query time. Only passages that pass both stages are sent to the large language model as context. That places authorisation inside the response pipeline instead of assuming that yesterday’s synchronisation still reflects today’s employment, team or project changes.

Why cached permissions are not enough

Many enterprise RAG systems copy both documents and their access-control lists into a search index. This is efficient, but it creates a window between synchronisations. A permission revoked in SharePoint may remain effective in the AI index until the next scheduled refresh, while a newly granted permission may take equally long to appear. The risk grows as organisations connect more repositories and expect assistants to answer across finance, human resources, strategy and legal material.

AWS describes its model as a dual-layer control. The indexed layer remains useful for fast filtering, while the real-time layer asks the authoritative source whether the current user may open each candidate document. The result is a smaller set of verified passages for generation. This design also keeps the model away from unauthorised text, which is materially safer than generating first and attempting to redact an answer afterwards.

A security boundary that can be audited

For governance teams, the important shift is that permission enforcement becomes an observable system action. Each query can be associated with an identity, the candidates retrieved, the live authorisation decisions and the context ultimately supplied to Bedrock. Those records can support investigation and policy testing without requiring reviewers to infer what an assistant might have seen. The approach is especially relevant where employees move between roles or where external collaborators receive temporary access.

AWS also points to Bedrock Guardrails for content filtering and grounding checks. These controls address different failure modes: access checks determine whether the user may see a source, while grounding controls test whether an answer is supported by the approved context. Neither replaces the other. An accurately grounded answer can still be an information leak if its source was unauthorised, and a correctly authorised source can still be misrepresented by a weak generation step.

What Australian buyers should test

Australian organisations assessing this pattern should test revocation speed, identity mapping and failure behaviour. A live authorisation service will sometimes be unavailable or slow. The safe default is to withhold uncertain content, but that choice has availability consequences that product owners need to communicate. Teams should also confirm how group membership, nested permissions, guest identities and repository-specific sharing links are resolved across every connected system.

The announcement is not a claim that every enterprise data-permission problem has disappeared. It is a useful architectural correction: access decisions belong close to retrieval and should be refreshed from the system that owns them. For Amazon Bedrock customers, the design offers a clearer path to expanding knowledge coverage without turning a generative assistant into a parallel, stale permissions database.

Deployment decisions still matter

Implementing the pattern will require more than enabling a connector. Identity attributes must map consistently between the assistant, the index and each source system. Organisations should define what happens when a repository returns a partial result, when a group service is slow or when one candidate document cannot be checked. They should also test indirect disclosure, where an answer reveals that a restricted document exists even if it does not quote the document. These are engineering and policy choices around the managed services, not settings a model can resolve on its own.

Performance is another design constraint. A live permission call for every retrieved item can add latency and load to enterprise systems, so teams may need batching, short-lived caching and limits on the number of candidates. Any cache must preserve the security goal that motivated the change. The useful measure is not simply answer speed, but the time required to enforce a revocation across the full response path. That gives security and product teams a shared service-level objective.

Procurement teams should ask vendors to demonstrate this control with a real revocation during evaluation. A user can open a permitted document, an administrator removes that access, and the same user immediately repeats the question. The resulting trace should show that the restricted passage was excluded before generation. That simple test connects a security promise to observable behaviour and exposes hidden synchronisation delays.