Amazon Bedrock can filter AI search by document permissions. Your application must authenticate the user.

On July 16, 2026, AWS announced the general availability of Amazon Bedrock Managed Knowledge Base, including ACL-aware retrieval for enterprise sources. An access control list (ACL) records which users or groups may or may not access a document. Carrying those permissions into AI search matters because a useful answer can still become a data exposure if its source document was outside the requester’s access.

The managed service reduces the infrastructure that teams need to assemble for retrieval-augmented generation (RAG), a method that finds relevant source material and supplies it to a generative AI system. AWS says it manages ingestion, storage, indexing, retrieval infrastructure, and default embedding and reranking models. This article explains the permission boundary that remains: the application must establish who the user is, send the correct identity, account for connector freshness, and prove both allowed and denied access before rollout.

Managed retrieval can carry source permissions into search results

According to the AWS announcement and Managed Knowledge Base overview, the service handles the underlying ingestion pipeline and retrieval infrastructure. Teams can connect SharePoint, Confluence, OneDrive, Google Drive, Amazon S3, or a custom source without separately operating the managed knowledge base’s datastore and indexing components.

ACL awareness adds document permissions to that retrieval process. When the feature is enabled for a supported source, Bedrock ingests allow and deny information alongside the document. A retrieval request includes user context, and the service filters its results to documents that the supplied user or the user’s groups can access.

The service also includes Agentic Retrieval. AWS says this mode can divide a complex question into subqueries, search iteratively across one or more knowledge bases, and stream trace events as it works. Those capabilities describe retrieval behavior; they do not establish that an answer is correct, that the work is cheaper, or that employees will be more productive.

The application must supply a trusted user identity

The AWS ACL documentation is explicit about the boundary: ACL-aware retrieval filters results, but Bedrock does not authenticate the end user and cannot verify that the identity supplied by the application is authentic. If an application sends another employee’s email address, the knowledge base evaluates permissions for that email address. The filter has no independent way to know who is operating the application.

The application team therefore owns the path from sign-in to retrieval request. It must authenticate the person, derive identity context from a trusted session or token, and prevent a client from substituting an arbitrary identity. The team also needs to decide what happens after retrieval, including which excerpts reach a model, what appears in the interface, and what is retained in logs or downstream systems.

Document ACLs cover only one kind of access. An AI workflow that can query a live database still needs appropriately limited credentials and read or write scope, as discussed in our guide to limiting database access. A recurring analysis also needs identity and permission checks each time it runs, including when no person is present to sign in interactively; our Palm Pulse analysis explains why scheduled analysis deserves its own access review.

Email matching is another application responsibility. Bedrock uses email as its universal user identifier, and AWS says the value must match exactly across connected sources. There is no alias resolution or cross-identity-provider matching, so alex@example.com in the application will not automatically match a different address or alias in a source system. Identity lifecycle processes also need to prevent a reassigned email address from inheriting access assumptions associated with its previous owner.

ACL-aware retrieval applies permissions in two stages

The first stage is pre-retrieval filtering. During ingestion, Bedrock collects document permissions and group membership information from the connected source, or receives customer-provided ACL metadata for S3 and custom connectors. At query time, it compares the application-supplied user context with that stored permission data before returning results.

The evaluation includes both direct user access and group-based access. If the same user is allowed through one rule and denied through another, deny takes precedence. This rule matters when a person belongs to several groups or when a document has accumulated exceptions over time.

The second stage is real-time verification, available only for SharePoint, OneDrive, Google Drive, and Confluence. For candidate documents that pass the first filter, Bedrock checks the source at query time to confirm that the user still has access. AWS describes this as an additional check for permission changes that occurred after the last ingestion sync.

Real-time verification does not make ingestion freshness irrelevant. AWS says group memberships are as fresh as the last sync, while the query-time source check adds protection for supported connectors. Teams should set sync schedules according to how often users, groups, and document permissions change, then test the actual delay rather than treating “real time” as a description of the entire identity path.

Connector choice determines how quickly permission changes affect retrieval

The connector determines whether Bedrock can recheck access against a live permission system. This difference should be part of the source-selection and operating plan, especially for repositories where access changes frequently.

Scroll sideways to see all 4 columns.

Connector	Pre-retrieval ACL filter	Real-time source verification	Practical implication
SharePoint, OneDrive, Google Drive, Confluence	Yes	Yes	Stored permissions filter first; the source can then recheck document access at query time.
Amazon S3	Yes	No	Customer-provided ACL configuration is the source of truth; changes depend on updating and ingesting that data.
Custom	Yes	No	Customer-provided ACL metadata drives filtering; there is no live source recheck.
Web Crawler	No	No	The connector has no ACL awareness and should not be used for permission-sensitive content on that assumption.

For S3 and custom sources, the application and data pipeline cannot rely on a second source check to catch stale ACL metadata. They need a defined process for generating, validating, and refreshing that metadata. For mixed-source search, teams should also avoid presenting all connectors as if they have the same freshness properties simply because they sit behind one search interface.

Identity drift and stale permissions create predictable failure modes

A useful review begins with the ways the permission chain can break. The application may accept an identity value from the browser instead of deriving it from the authenticated session. The same person may have different email addresses across Microsoft, Google, Atlassian, and an internal directory. Group membership may change after the last sync, or an S3 ACL file may lag behind the business process that changed access.

Failure behavior also affects operations. AWS says ACL evaluation fails closed: a group-resolution error, verification timeout, or internal ACL error withholds the affected documents. That protects against an error returning unauthorized content, but it can produce zero or fewer results than expected. Monitoring and support procedures need to distinguish an ACL-resolution failure from a legitimate search with no matching documents.

These are application and operating concerns, even when the retrieval infrastructure is managed. AI workflow controls should connect sign-in, identity normalization, source syncs, retrieval errors, logging, and downstream use. A broader data security review can then examine whether the search interface, model calls, traces, and retained outputs preserve the restrictions enforced during retrieval.

A two-user document test reveals permission mistakes before rollout

Start with two test users and four small documents in one source. Give both users access to a shared document, give each user one private document that the other cannot open, and create a fourth document that both would otherwise be allowed to access but that explicitly denies one user. Use the exact email identities that the application will send in production, and record the source permissions and group memberships before syncing.

Run the same direct queries as each user and inspect the retrieved source chunks alongside the generated answer. Each user should retrieve the shared document and that user’s private document, never the other user’s private document, while the explicit deny should override any allow. Repeat the denied cases after a permission change, before and after ingestion sync, to observe the connector’s actual freshness. For a connector with real-time verification, confirm that the live source check blocks newly revoked access.

Finally, send a request with a mismatched email, trigger an ACL-resolution failure in a non-production environment where feasible, and verify that the application treats fewer results as a diagnosable access condition rather than inventing an answer from missing evidence. Teams extending this test across sources should keep the users and documents small until identity matching, sync behavior, errors, and denied access are predictable. BaristaLabs can help turn those findings into a production access design through data security work or a scoped process automation engagement.