3LO no Bedrock Managed KB: 5 minutos de setup, 1 decisão irreversível

A página de setup do SharePoint é explícita e vale ler duas vezes: user-managed setup does not support document-level access control (ACL). Todo conteúdo indexado fica acessível a qualquer pessoa que possa consultar o knowledge base, e as permissões individuais do SharePoint não são aplicadas. A mesma frase aparece na página do Confluence, palavra por palavra.

Isso não é um bug nem uma lacuna temporária, é consequência direta do fluxo. No 3LO o Bedrock guarda um refresh token delegado, emitido para você, com quatro permissões: Sites.Read.All e User.Read no Microsoft Graph, offline_access para renovar o token, e AllSites.Read na API do SharePoint Online. São permissões delegated, herdadas do que a sua conta enxerga. O crawler entra no tenant vestindo a sua identidade e copia tudo o que ela alcança para um índice que não tem noção de quem é quem.

O caminho que suporta ACL é outro: ENTRA_ID_APP_ONLY no SharePoint, ENTRA_APP_ID no OneDrive, SERVICE_ACCOUNT no Google Drive, BASIC no Confluence. São permissões application, com admin consent, e no caso do SharePoint com ACL exigem Sites.FullControl.All, ou Sites.Selected com grant fullcontrol por site, porque Sites.Read.All não basta para ler permissão de item.

A troca, dita sem eufemismo: o 3LO substitui um ticket de duas semanas com o time de identidade por um índice sem fronteira interna. Para um protótipo de wiki pública de engenharia, é um bom negócio. Para o repositório de políticas de crédito, é um incidente esperando a data.

Chegar no caminho com ACL resolve menos coisas do que parece, e resolve de um jeito muito específico. O Bedrock Managed Knowledge Base usa e-mail como identificador universal: não há resolução de alias nem mapeamento entre provedores de identidade. O userId que você passa no Retrieve precisa bater exatamente com o e-mail associado àquele usuário em cada data source conectado. Se o seu IdP corporativo emite fernando.azevedo@empresa.com e o Confluence guarda fazevedo@empresa.com, o match falha em silêncio e o usuário simplesmente não recebe resultado daquela fonte. Silêncio é o pior modo de falha possível num sistema de busca: ninguém abre chamado por resposta incompleta, abre por resposta errada.

Grupos funcionam por outra régua. São identificados como a fonte os representa, nome, ID, o que for, e a associação usuário→grupo vem do crawl. A documentação é direta: a associação de grupos é tão fresca quanto o último sync. Mudou permissão entre syncs, o filtro pré-retrieval não sabe. O que salva é a segunda camada: para SharePoint, OneDrive, Google Drive e Confluence existe verificação em tempo real contra a fonte, que pega justamente essa janela. S3 e Custom não têm essa rede, porque o ACL deles vem de arquivo de metadados fornecido por você.

Duas notas que mudam o desenho da aplicação: credenciais do IdP terceiro ficam em cache por até 1 hora, e mudanças de permissão são eventualmente consistentes, tipicamente em poucos minutos. Então "revoguei o acesso agora" e "o RAG parou de mostrar" não são o mesmo instante. Em ambiente sob BACEN ou LGPD, essa diferença precisa estar escrita no desenho, não descoberta na auditoria.

O token tem dono, e dono pede demissão. O refresh token do 3LO pertence a uma pessoa. Quando ela sai da empresa e a conta é desabilitada, o sync para, e o índice continua lá, com o conteúdo que ela alcançava. O caminho de produção não tem esse acoplamento: a aplicação se autentica com certificado, sem login humano nem no crawl nem na consulta.

Fail closed é bom, mas parece bug. A retrieval com ACL falha fechada: erro de resolução de grupo, timeout na verificação em tempo real ou erro interno não devolvem o documento. A resposta pode vir com menos resultados que o maxResults pedido, e o Bedrock não completa com outros documentos. Sua aplicação precisa tratar resposta parcial como normal, e distinguir "zero por ACL" de "zero por relevância", a API sinaliza a falha de resolução justamente para isso.

Documento sem ACL é documento invisível. Em data source com ACL habilitado, documento cujas permissões não foram extraídas não vai para ninguém. Ausência é tratada como restrição, não como público. Depois da migração, espere uma queda de recall e investigue antes de culpar o embedding.

O prefixo do segredo é a sua única alavanca de IAM, e o default é ambíguo. A página de IAM do 3LO diz que sem prefixo o Bedrock usa default; as páginas de conector dizem que o segredo criado usa o prefixo bedrock-managedkb-oauth. Não construa policy em cima dessa suposição: informe um secret name prefix explícito no sign-in e escreva a policy com Resource escopado a ele antes de alguém rodar o fluxo. É a diferença entre secretsmanager:CreateSecret num caminho previsível e um Resource: "*" que ninguém vai revisar depois.

A tentação óbvia depois de ler tudo isso é bloquear o 3LO e pronto. Eu não faria. O atrito que ele remove é real: sem ele, todo experimento de RAG sobre a wiki interna vira um ticket de duas semanas com o time de identidade, e o resultado prático é que ninguém experimenta, ou pior, alguém exporta a wiki para um bucket e faz o RAG por fora, sem crawler, sem sync e sem nenhuma das verificações que a gente acabou de discutir.

O desenho que eu recomendo é topológico, não político. Uma conta de sandbox onde bedrock:GetDataSourceAuthorizationUrl e bedrock:CreateDataSourceToken são permitidas, sem dado classificado e com ciclo de vida curto, o índice inteiro morre em N dias por processo, não por lembrança. As contas de produção com essas duas ações negadas por SCP, o que faz o 3LO desaparecer do cardápio sem discussão caso a caso.

O que atravessa essa fronteira não é o data source; é o aprendizado. O protótipo responde as perguntas caras de verdade: quais espaços do Confluence têm conteúdo que resolve dúvida real, qual estratégia de chunking sobrevive a documento de política com 80 páginas, se a busca agêntica com maxAgentIteration acima do padrão de 5 muda a resposta o suficiente para pagar o custo. Nada disso depende de ACL. Quando a resposta for "vale", aí sim você abre o ticket com o time de Entra sabendo exatamente quais sites pedir no Sites.Selected, e o ticket fica mais curto porque você chega com escopo, não com intenção.