3LO in Bedrock Managed KB: 5-minute setup, 1 irreversible decision

The SharePoint setup page is explicit and worth reading twice: user-managed setup does not support document-level access control (ACL). All indexed content is accessible to anyone who can query the knowledge base, and individual SharePoint permissions are not enforced. The same sentence shows up on the Confluence page, word for word.

This isn't a bug or a temporary gap — it follows directly from the flow. In 3LO, Bedrock stores a delegated refresh token, issued to you, carrying four permissions: Sites.Read.All and User.Read on Microsoft Graph, offline_access to renew the token, and AllSites.Read on the SharePoint Online API. These are delegated permissions, inherited from what your account can see. The crawler walks into the tenant wearing your identity and copies everything it can reach into an index that has no notion of who is who.

The path that does support ACL is a different one: ENTRA_ID_APP_ONLY for SharePoint, ENTRA_APP_ID for OneDrive, SERVICE_ACCOUNT for Google Drive, BASIC for Confluence. Those are application permissions, with admin consent, and for SharePoint with ACLs they require Sites.FullControl.All — or Sites.Selected with a per-site fullcontrol grant — because Sites.Read.All is not enough to read item-level permissions.

The trade, stated plainly: 3LO swaps a two-week ticket with the identity team for an index with no internal border. For a prototype over a public engineering wiki, that's a good deal. For the credit policy repository, it's an incident waiting for a date.

Getting to the ACL path solves less than it looks, and it solves it in a very specific way. Bedrock Managed Knowledge Base uses email as the universal identifier — there is no alias resolution and no cross-identity-provider mapping. The userId you pass to Retrieve must match exactly the email associated with that user in each connected data source. If your corporate IdP issues fernando.azevedo@company.com and Confluence stores fazevedo@company.com, the match fails silently and the user simply gets no results from that source. Silence is the worst failure mode a search system can have: nobody files a ticket over an incomplete answer, they file over a wrong one.

Groups run on a different ruler. They're identified however the source represents them — name, ID, whatever — and user→group membership comes from the crawl. The docs are blunt: group memberships are as fresh as the last sync. If a permission changed between syncs, the pre-retrieval filter doesn't know. The saving grace is the second layer: for SharePoint, OneDrive, Google Drive and Confluence there's real-time verification against the source, which catches exactly that window. S3 and Custom have no such net, because their ACLs come from a metadata file you supply.

Two notes that change your application design: third-party IdP credentials are cached for up to 1 hour, and permission changes are eventually consistent, typically within a few minutes. So "I revoked access now" and "the RAG stopped showing it" are not the same instant. In a BACEN- or LGPD-bound environment, that gap belongs in the design document, not in the audit findings.

The token has an owner, and owners resign. The 3LO refresh token belongs to a person. When they leave and the account is disabled, the sync stops — and the index stays right there, holding whatever content they could reach. The production path has no such coupling: the application authenticates with a certificate, with no human sign-in at crawl time or query time.

Fail-closed is good, but it looks like a bug. ACL-aware retrieval fails closed: a group-resolution error, a real-time verification timeout or an internal error means the document is not returned. The response may carry fewer results than the requested maxResults, and Bedrock does not backfill. Your application must treat partial responses as normal, and tell "zero because of ACL" apart from "zero because of relevance" — the API signals resolution failures precisely for that.

A document without an ACL is an invisible document. In an ACL-enabled data source, a document whose permissions weren't extracted goes to nobody. Absence is treated as restricted, not public. After the migration, expect a recall drop and investigate that before blaming the embedding model.

The secret prefix is your only IAM lever, and the default is ambiguous. The 3LO IAM page says that without a prefix Bedrock uses default; the connector pages say the created secret uses the bedrock-managedkb-oauth prefix. Don't build a policy on that assumption: supply an explicit secret name prefix at sign-in and write the policy with Resource scoped to it before anyone runs the flow. That's the difference between secretsmanager:CreateSecret on a predictable path and a Resource: "*" nobody will review later.

The obvious temptation after reading all this is to block 3LO and be done. I wouldn't. The friction it removes is real: without it, every RAG experiment over the internal wiki turns into a two-week ticket with the identity team, and the practical outcome is that nobody experiments — or worse, somebody exports the wiki into a bucket and builds RAG on the side, with no crawler, no sync and none of the checks we just discussed.

The design I recommend is topological, not political. One sandbox account where bedrock:GetDataSourceAuthorizationUrl and bedrock:CreateDataSourceToken are allowed, with no classified data and a short lifecycle — the whole index dies in N days by process, not by memory. Production accounts with those two actions denied by SCP, which makes 3LO disappear from the menu without a case-by-case argument.

What crosses that border isn't the data source; it's the learning. The prototype answers the genuinely expensive questions: which Confluence spaces hold content that resolves real doubts, which chunking strategy survives an 80-page policy document, whether agentic retrieval with maxAgentIteration above the default of 5 changes the answer enough to justify the cost. None of that depends on ACLs. When the answer is "worth it", then you open the ticket with the Entra team knowing exactly which sites to request under Sites.Selected — and the ticket is shorter because you arrive with a scope, not an intention.