Amazon Web Services has published an engineering post on its Machine Learning blog, dated 7 October 2026, about a problem most internal RAG projects meet: the assistant must only answer from documents the person asking is allowed to see. It describes how Amazon Quick and Amazon Bedrock Knowledge Bases handle that. The post is vendor-published and by AWS product staff; we have not tested the feature.

The design AWS says falls short

AWS calls the usual approach "replicate and filter". A connector pulls access control lists (ACLs) from a source such as SharePoint, Google Drive or Confluence during a periodic sync, stores them as attributes in the index, and at query time maps the signed-in user to those attributes to filter results.

AWS lists three weaknesses:

  • The AI system is not the source of truth. Connectors must reproduce each source's inheritance, group, conditional-access and deny rules, which AWS calls error-prone.
  • The copy goes stale. ACLs are a snapshot from the last sync. AWS says some sources, Confluence among them, do not emit an event when group membership changes, so event-based updates do not work everywhere. Between syncs, a user whose access was revoked may still get answers from documents they should no longer see.
  • Sources change. A new permission feature in SharePoint or a change to Google Drive sharing can leave gaps in the mapping until the connector is updated.

The two-stage check

AWS says it added a real-time check on top of the existing pre-retrieval filtering. In stage one, Quick runs a semantic search over the vector index and applies the ACLs already stored there, producing candidate documents. AWS says real-time API calls for every document in the index would cost too much at scale, so this stage stays cached.

In stage two, Quick verifies the candidates against the source. In AWS's Google Drive example, it calls the Drive APIs using a service account credential that the administrator supplied, generating user-specific access tokens through impersonation. Drive holds the authoritative ACLs. Documents the user cannot open are dropped, and only the verified passages go to the large language model as context.

AWS says Bedrock Guardrails, grounding checks and configurable safety policies sit alongside this, but it gives no detail on how they interact with the ACL step.

What AWS claims, and the evidence offered

AWS claims that revoked access is reflected in answers "within moments, not hours or days" and that teams no longer need to think about sync frequency. The only customer evidence is a quote from Mondelēz International, which AWS says has deployed Amazon Quick to more than 35,000 employees across four regions. The quote is about confidence in the approach, not measured results.

What the post leaves out

There are no latency figures for the extra API calls, no cost, and no test showing how often stale permissions leaked before the change. It does not say how many candidates are checked per query, how rate limits at the source are handled, or what happens when the source API is down. The worked example is Google Drive only. It also depends on a broad service account that can impersonate users, which is its own access-control decision for your security team.

The design question carries over to any stack: whether permission enforcement lives in a copy or at the source, and how long the copy can be wrong. A cheap check is to revoke a test user's access to a document and see how long your assistant keeps quoting it.