A retrieval-augmented AI assistant can answer a confidential question using the exact document that contains the answer. That is a success for semantic search and a security failure if the person asking was not authorised to read the document. Relevance and permission are different predicates, and both must be true before a passage reaches the model.
Amazon describes a common architecture in which connectors copy document access-control lists into an AI index during synchronisation. The index can then filter search results by user or group. The weakness is timing and translation: permissions may change after the last sync, and each source has its own inheritance, group, deny and sharing rules.[1]
Where a permission-aware assistant can fail
| Measure | Value | Context |
|---|---|---|
| Stale membership | Access was revoked after the last sync | The indexed ACL still reflects an earlier state.Source 1 |
| Mapping error | A source-specific rule is simplified incorrectly | Inheritance, groups or deny rules may not survive translation.Source 1 |
| New source feature | The connector does not understand a changed permission model | Content can become exposed until the connector is updated.Source 1 |
| Weak caller identity | The application supplies an untrusted or incomplete user context | Correct document rules are applied to the wrong identity.Source 2Source 3 |
| Mixed sources | Different connectors enforce different controls | One permissive source can undermine the combined answer.Source 3 |
Two stages solve different problems
Amazon’s approach uses the copied ACL first because checking the source system for every item in a large index would be too expensive. That stage produces a small set of semantically relevant candidates. A second stage asks the authoritative system—such as Google Drive—whether the current user may access each candidate now. Only passages that pass the live check become context for the model. This is not an instantaneous revocation guarantee: the Bedrock retrieval documentation says permission updates are eventually consistent, typically taking a few minutes, and third-party identity-provider credentials may remain cached for up to one hour, during which access may continue. Deployments must test the effective revocation delay for their connector and identity setup.[1][3]
This is a useful pattern beyond one product. Cached policy can provide speed; the source of truth provides freshness. The final authorisation decision should be as close as practical to the protected action or disclosure, particularly when group membership and sharing links can change independently of content indexing.
Retrieval and authorisation answer different questions
| Layer | Primary question | Failure if omitted |
|---|---|---|
| Authentication | Who is making the request? | Permissions are evaluated for an invented or mistaken identitySource 2 |
| Semantic retrieval | Which passages are relevant? | The assistant cannot find useful evidenceSource 1 |
| Pre-filtered ACL | Which candidates appear allowed from cached metadata? | Every indexed passage must be checked liveSource 1 |
| Real-time verification | Does the source allow this user now? | Revoked or mistranslated access may leak contentSource 1 |
| Generation and citation | What can the model say from the authorised evidence? | The answer may invent claims or conceal its sourceSource 1 |
The identity must survive the whole path
A secure front end cannot simply attach an email address to the query and assume the knowledge service will trust it. The user identity should be authenticated, bound to the retrieval request and preserved when the system calls the original repository. Service accounts and impersonation flows need narrow scopes, auditable delegation and protection against an agent changing the user context.
Fail-closed behaviour is equally important. If the live permission check times out, the safe response is to withhold the passage or explain that access could not be verified. Returning the cached result because the authorisation service is unavailable turns an operational failure into a data leak.
Deny rules deserve first-class tests
Enterprise permissions are not always a list of people who may read a file. A document may inherit access from a parent, exclude a subgroup, depend on a domain restriction or be shared through a link. The test suite should include explicit denials, revoked users, changed groups, moved documents and mixed-source queries. A user who can access nine of ten documents must not receive a summary that reveals the tenth.
- Create known allowed, denied and recently revoked test identities.
- Change group membership without re-indexing and verify the live decision.
- Simulate source outages and confirm the system withholds unverified passages.
- Inspect citations to ensure every quoted claim comes from an authorised document.
- Log the identity, source decision and document identifier without exposing document contents in security logs.
The most trustworthy enterprise assistant is not the one that can search the largest archive. It is the one that can prove which identity asked, which evidence was relevant, which source allowed access at that moment and which authorised passages supported the final answer. That chain turns retrieval from a convenience into a governed information system.
Sources & further reading
- Rethinking access control for RAG with Amazon Quick and Amazon Bedrock AWS Artificial Intelligence Blog · 7 Oct 2026 · Accessed 9 Oct 2026
- Knowledge Bases access control list awareness Amazon Bedrock User Guide · Accessed 9 Oct 2026
- Test and retrieve from an ACL-aware knowledge base Amazon Bedrock User Guide · Accessed 9 Oct 2026