User OAuth or Service Accounts? Choosing Identity for Bedrock Knowledge Bases

A knowledge-base prototype can appear healthy for months while resting on one employee's consent. The connector signs in, synchronization completes, retrieval returns plausible passages, and the demo becomes a departmental dependency. Then the employee changes roles, loses access, resets credentials, hits a conditional-access policy, or leaves the company. The refresh token stops working and nobody can explain who owns the connection. The more serious failure is quieter: the knowledge base retrieves a document that the requesting employee cannot open in SharePoint, OneDrive, or Confluence because source permissions were never preserved in the retrieval path.

That is why Bedrock Knowledge Base OAuth is not merely a setup choice. Connector identity, ingestion authorization, stored-index access, application authentication, query-time filtering, token lifecycle, synchronization, deletion, and evidence form one control system. AWS added user-managed three-legged OAuth (3LO) for SharePoint, OneDrive, and Confluence on September 4, 2026. It makes bounded experimentation faster, but it does not turn a human OAuth grant into a durable production identity or automatically preserve document permissions.

This guide treats identity as a production design decision. It gives teams a rubric for 3LO versus service identity, an inventory for consent and secrets, source-specific access-control tests, freshness and deletion service-level objectives (SLOs), retrieval leakage tests, promotion gates, incident procedures, and an exit plan. The central acceptance test is simple: every retrieved item must be authorized, current, attributable, and removable.

What User-Managed 3LO Changes in Knowledge-Base Setup

AWS's September 4, 2026 announcement of user-managed setup for SharePoint, OneDrive, and Confluence positions 3LO as the faster path for users who cannot or do not want to provision service credentials. In the console flow, the user signs in to the source, grants delegated access, and Amazon Bedrock Managed Knowledge Base stores refresh-token material in AWS Secrets Manager. The setup removes some up-front administrator work, but it transfers operational dependency to the consenting user's identity and repository access.

The right mental model is not 'Bedrock can now log in for me.' It is 'the knowledge base can act within the delegated user's current authority, until that authority or consent changes.' That distinction matters because the source account defines what can be ingested, while the knowledge-base application defines who can query the resulting index. Unless document-level access control is explicitly supported and enabled for the chosen connector and authentication mode, those two populations are not equivalent.

Keep retrieval state separate from conversational or agent state. Refonte Learning's discussion of AI agent memory systems is useful for understanding persistent state boundaries, but connector authorization is a different control plane: a passage can be remembered or indexed correctly and still be unauthorized for the person asking the question.

Choose 3LO or a Service Identity With a Production Rubric

Do not choose an identity pattern by setup speed alone. Three-legged OAuth, an application identity such as Microsoft Entra app-only, and a source service account create different operational dependencies. The matrix below should be completed for each connector, not once for the whole knowledge base, because SharePoint, OneDrive, and Confluence do not expose identical authentication or access-control behavior.

Use 3LO for Bounded, Reversible Prototypes

3LO is appropriate when the purpose is discovery: validate connector reachability, document formats, chunk quality, retrieval relevance, and operational effort against a small, non-sensitive corpus. The prototype must be explicitly reversible. Use a named test user, a small set of approved source locations, a dedicated non-production knowledge base, and a secret-name prefix that can be identified and deleted. Do not let the prototype token become the production credential by inertia.

•         Time-box the authorization and record a planned teardown date.

•         Exclude regulated, privileged, personnel, customer, legal-hold, and executive content unless the pilot's authorization semantics can be proven.

•         Treat successful sync as a connectivity result, not a production security approval.

•         Require a negative retrieval test showing that content outside the approved corpus is not retrievable.

•         Define the migration target before the first pilot, especially when document-level permissions are a production requirement.

Use App-Only or Service Accounts for Durable Operations

A durable service identity is usually the better production choice when the knowledge base is expected to survive employee movement, run continuously, or enforce source-level permissions. For SharePoint, AWS documents Microsoft Entra ID App-Only authentication as the recommended method and the only SharePoint authentication method that supports document-level ACL behavior in the managed knowledge-base connector. The application uses certificate-based client credentials rather than an interactive user sign-in.

Service identity is not automatically least privilege. An app with tenant-wide read permissions can be more dangerous than a delegated user. Prefer per-site or otherwise bounded grants when the source supports them, assign an accountable owner and backup owner, set credential-expiry monitoring, and document who can change source permissions. Production readiness comes from durable identity plus bounded scope, not from replacing the word 'user' with 'service.'

Map Users, Tenants, Consent, and Administrator Prerequisites

Build an identity inventory before creating production connectors. The inventory is the control record that lets security, source owners, and platform teams answer who authorized the connector, where its authority comes from, and how it will be replaced. This is narrower than a general agent registry, although the ownership discipline aligns with AI agent sprawl governance.

Administrator prerequisites differ by source and tenant policy. Microsoft 365 may allow user consent or may require an administrator to pre-consent to the Bedrock application. Atlassian authorization controls can require a site administrator to approve the integration. A production record should capture both the technical consent and the policy decision that allowed it. Do not copy a SharePoint permission list into OneDrive or Confluence documentation; use the exact connector setup page for the authentication mode you actually deploy.

A practical acceptance gate is a consent review signed by the source owner and identity team. It should state the identity, tenant, requested scopes, content boundaries, document-level ACL mode, expected users, offboarding behavior, and emergency revocation method. If any field is unknown, the connector is still a prototype.

Own the Refresh-Token and Secret Lifecycle

With user-managed 3LO, the refresh token becomes a production credential even if Amazon Bedrock creates the Secrets Manager secret automatically. AWS documents that the generated secret lives in your AWS account and that the knowledge-base execution role needs access to it so tokens can be refreshed. That secret therefore belongs in your credential inventory, monitoring, incident response, and deletion process. Automatic creation is not automatic ownership.

The token can stop working for reasons outside the Bedrock configuration: user or administrator revocation, account disablement, source-side policy changes, tenant consent changes, security response, or provider-specific refresh-token rules. A resilient design assumes reauthorization will eventually be required. Track the last successful refresh indirectly through sync health and authentication errors, and set an alert before the business notices that the knowledge base has stopped changing.

Control Bedrock-Created Secrets, IAM, KMS, and Monitoring

Use a predictable secret-name prefix for each environment and connector where the 3LO flow supports it. Scope the setup operator and knowledge-base role to only the required secret paths. AWS's IAM guidance for user-managed 3LO setup separates permissions for the person initiating sign-in from permissions needed by the knowledge-base execution role. Preserve that separation so ordinary application operators cannot create new third-party grants or read unrelated credentials.

•         Secret naming: include environment, source type, owning service, and a non-sensitive identifier.

•         Encryption: document whether the secret uses the default Secrets Manager key or a customer-managed AWS Key Management Service (KMS) key; restrict key administrators separately from secret readers.

•         IAM: allow only the specific Secrets Manager actions and resource patterns required for setup, refresh, and incident handling.

•         Logging: retain AWS CloudTrail records for secret creation, update, access-policy changes, and deletion actions.

•         Recovery: document whether reauthorization creates a new secret or updates an existing one, then test the exact process in non-production.

•        Deletion: after connector retirement, delete the data source, revoke source authorization, delete unused secrets, and record evidence that the old credential can no longer be used.

The security mindset is similar to the one used for CI/CD secret leakage from AI coding agents, but the containment path is connector-specific: a leaked refresh token can expose source content, while a leaked application certificate or service-account token can expose the full scope assigned to the non-human identity.

Plan for Revocation, Password Changes, and Owner Departure

Create a lifecycle state model and assign an action to each transition. A user changing a password does not always produce the same result as an administrator revoking sessions, disabling the account, or changing conditional-access policy. Treat the source provider's actual token behavior as authoritative, and use authentication failures as a trigger for controlled reauthorization rather than repeated blind retries.

Limit Sites, Drives, Spaces, Folders, and Content Classes

Least privilege begins before the first crawl. A connector identity can be narrow while the configured source scope is broad, or vice versa. Record both. For SharePoint, enumerate exact site URLs and item-path or date filters supported by the connector. For OneDrive, define which users' personal drives are in scope and use supported email, path, MIME-type, and date filters. For Confluence, enumerate the site, spaces, entity types, URLs, attachments, archived content, and MIME-type filters that are actually configured.

Do not rely on retrieval prompts to exclude sensitive classes. Exclusion belongs as close to the source as the connector allows. If a source cannot express a required filter, either segregate the content into a dedicated site/space, use a different connector path, or do not ingest it. A semantic layer can improve meaning and consistency, as discussed in semantic layers for AI agents, but semantic organization does not replace source authorization or minimization.

Treat Document-Level ACL Support as a Design Constraint

Document-level access control must be an architecture input, not a feature you try to add after indexing. AWS explicitly warns in its SharePoint document-level access-control documentation that ACL awareness is filtering, not end-user authentication. Your application still has to authenticate the user, establish a trustworthy identity, and pass the correct identity context to retrieval. If the application can spoof or substitute that identity, connector-side filtering cannot create a secure boundary.

For SharePoint, ACL-enabled managed connectors require the documented app-only mode. OneDrive's 3LO documentation likewise states that user-managed setup does not support document-level ACLs, while the Microsoft Entra application mode is the documented path for ACL-aware retrieval. For Confluence, user-managed 3LO does not support document-level ACLs; AWS documents Basic authentication with additional Atlassian organization-admin credentials for ACL mode. These differences are not implementation trivia. They decide whether a shared knowledge base can safely serve users with different source permissions.

Do Not Assume OAuth Preserves Source Permissions

OAuth answers 'may this client act under this grant?' It does not, by itself, answer 'may the current end user see this indexed chunk?' In 3LO mode, the source sees the consenting user's delegated identity during crawl. If Bedrock indexes everything that identity can read and the knowledge base is queryable by a broader population, source permissions have been flattened unless a supported ACL feature adds query-time filtering.

Use a simple design rule: if two intended knowledge-base users have different rights to any document in the same source scope, require a connector/authentication combination with documented ACL behavior, or split the corpus into separately authorized knowledge bases. Do not depend on prompt instructions such as 'only answer with documents the user is allowed to see.' The model cannot infer source authorization from content safely.

Test Identity Matching and Query-Time Authorization

Build ACL tests from real permission structures, not only from synthetic public files. Test both positive access and denial. Run them before launch and after connector, identity-provider, group, or source-permission changes. The expected result for a denied document is no retrieval of its content, title, snippet, or revealing metadata.

Handle SharePoint, OneDrive, and Confluence Differences

The three Bedrock 3LO connectors share an interactive setup pattern, but their source models and production alternatives differ. Treat each as a separate integration. The connector-specific pages, including OneDrive user-managed 3LO and Confluence user-managed 3LO, explicitly warn that user-managed setup does not support document-level ACLs. That is the key production boundary for shared enterprise assistants.

Connector context also differs from tool invocation. Refonte Learning's article on no-code AI agents and MCP discusses tool and integration patterns; a repository connector is narrower. Its primary job here is to ingest and retrieve governed knowledge, not to give the model a general-purpose action channel.

Known limitations belong in the design record. Examples include OneDrive content-model limits such as unsupported notebook types, source-specific filter capabilities, and authentication modes that cannot be combined with ACLs. If a business requirement depends on an unsupported combination, choose another identity pattern or another ingestion architecture rather than documenting the limitation as an acceptable surprise.

Apply Data Minimization, Classification, and Retention

A retrieval index is a derived copy of source information, with its own exposure paths and deletion duties. Minimize before ingestion. For each approved source area, record the business purpose, data classification, expected user population, retention obligation, legal-hold status, and whether the content may be used in model prompts or generated responses. If the same site mixes public handbooks with investigations, payroll, legal advice, or customer records, do not crawl the entire site simply because the connector identity can read it.

•         Prefer allow-listed source containers over broad tenant or site roots.

•         Exclude obsolete, duplicated, draft, superseded, or out-of-policy content when the connector exposes a reliable filter.

•         Record unsupported minimization controls and compensate with source restructuring or a separate ingestion path.

•         Do not use index retention to extend the life of source records that should have been deleted.

•         Tag test corpora so security and legal reviewers can distinguish synthetic validation content from production records.

Acceptance gate: the source owner must be able to name every content class that can enter the index and every intended audience that can query it. If either answer is 'whatever the account can access,' the design is too broad.

Engineer Sync Freshness, Deletion, and Failure Recovery

Synchronization creates a temporal security boundary. A document can be created, modified, permissioned, or deleted in the source before the index reflects the change. AWS documents incremental synchronization for these managed connectors and provides scheduled synchronization options, but production teams still need measurable objectives. 'We sync daily' is a schedule, not evidence that deletion or permission changes converge within an acceptable time.

Measure four lags independently: create-to-retrievable, update-to-current, delete-to-not-retrievable, and permission-change-to-correct-access. Use canary documents with deterministic text and known permissions. Record source event time, sync start/end, first correct retrieval result, and any errors. For ACL-enabled connectors that perform real-time checks, permission-change behavior may differ from content-update behavior, so test it separately.

Failure recovery must be idempotent and observable. Repeated sync attempts should not become your only strategy. Define when to resync, when to rebuild a data source, when to quarantine a knowledge base, and when to fail closed at the application layer because freshness cannot be trusted. Deleted-content hits should be treated as a security or records-management incident, not only a search-quality defect.

Evaluate Retrieval, Citations, Omissions, and Leakage

A grounded answer with a citation can still be wrong in four ways: the cited source may no longer exist, the user may not be allowed to open it, the indexed passage may be stale, or the system may omit a more authoritative document. Retrieval evaluation therefore needs more than relevance metrics. Build a test set that combines answer correctness with source existence, permission state, recency, and expected no-answer behavior.

Run RAG data leakage tests with adversarial prompts such as requests for confidential titles, summaries of 'documents I cannot access,' names from private project spaces, or content previously retrieved before permission was removed. Include prompt variations and indirect questions. The test passes only when unauthorized source material is absent from both answer text and citations.

Keep a retrieval evidence record for high-risk applications: test-case identity, query, expected authorization outcome, retrieved source identifiers, source timestamps, answer result, and disposition. That evidence is what lets a team prove that a release improved authorization rather than only improving semantic relevance.

Promote Connectors Across Development and Production

Treat connectors as environment-specific infrastructure. Development and production should have separate identities, source scopes, secrets, knowledge bases or indexes, test corpora, and approval records. A user OAuth token from a successful prototype must never be copied forward as the production credential. Promotion should recreate the integration under the approved production identity and then rerun security and retrieval acceptance tests.

This fits the broader production discipline described in building AI agents in production, but the promotion gate here is connector-specific: the same prompt and model can be safe in a sandbox and unsafe in production if the production source scope or identity is broader.

Use change control for any production modification that can broaden access: app permission changes, new sites or spaces, new user-drive populations, ACL enablement decisions, source filters, secret policies, or application identity mapping. A retrieval-quality improvement does not waive an authorization review.

Monitor Incidents, Consent Drift, and Source Changes

Monitoring must combine AWS, source-platform, and application signals. A green knowledge-base endpoint says nothing about whether the source token still refreshes, whether the owner still exists, whether item counts collapsed, or whether sensitive content became retrievable. Build dashboards and alerts around the control objectives rather than only service availability.

Consent drift deserves its own review. An administrator may change tenant-wide user-consent settings, block third-party applications, rotate organization API keys, alter site access, or change group membership rules. Keep a quarterly or risk-based reconciliation between the connector inventory and the identity/source systems, with faster checks for high-sensitivity corpora.

Design Migration, Reauthorization, and Data Exit

Production design is incomplete until you can replace the identity and remove the data. The most common migration is from a 3LO prototype to a durable service identity. Create the new connector in parallel where possible, ingest the same bounded corpus, compare item counts and retrieval behavior, rerun ACL and freshness tests, switch application traffic, then revoke and delete the old 3LO grant and secret. Avoid an in-place credential swap when it would obscure which identity produced which evidence.

1.        Inventory the current connector: source scope, identity, secret ARN, last successful sync, ACL mode, and dependent applications.

2.        Provision the target identity with the smallest source permissions that meet the requirement.

3.        Create a parallel non-production or shadow data source and ingest a controlled validation corpus.

4.        Compare source coverage, metadata, permission behavior, citations, freshness, and deletion propagation.

5.        Run the full negative leakage suite using identities from different permission groups.

6.        Approve cutover, switch the application to the target knowledge base or data source, and observe for a defined period.

7.        Revoke the old source authorization, disable/delete the old connector, remove unused secrets/certificates/tokens, and preserve deletion evidence.

For source-to-source migration, map document identifiers, owners, permissions, and retention state before re-ingestion. For platform exit, export the source inventory and evaluation corpus, rebuild retrieval on the alternate platform, compare authorization and deletion behavior, and then delete Bedrock data sources and credentials according to your retention policy. 'We stopped querying it' is not proof of data exit.

Run a 60-Day Identity-Aware Knowledge-Base Pilot

A good pilot is not an eight-week relevance demo. It is a controlled attempt to falsify the production design. Use bounded, representative content; named owners; a small set of test users with deliberately different permissions; and a known migration target. The timeline below assumes the team can obtain identity and source-owner participation. If those owners are unavailable, that itself is a no-go signal for production.

Go to production only if all critical controls have an owner and evidence. The minimum gate is: identity and consent are durable enough for the service; source scope is explicit; the selected connector/authentication mode provides the authorization semantics the application needs; negative ACL tests pass; freshness and deletion SLOs are measured; token or credential failure produces an alert; unauthorized retrieval has a containment path; and the team has rehearsed reauthorization or migration.

A pilot should end with one of three decisions: approve the production identity pattern, approve only a restricted corpus with compensating controls, or reject the connector design and choose a different ingestion/authorization architecture. Do not label a successful demo as a production approval when document permissions cannot be proven.

The production threshold for a managed knowledge base is higher than successful ingestion. Every source item needs a justified ingestion identity, a known source-authorization path, a current synchronization state, retrieval evidence for the requesting user, and a removal path. Three-legged OAuth can shorten the path to a bounded prototype, but convenience must not become an implicit security model. When continuity or document-level permissions matter, use the durable authentication mode that the source connector actually documents, then test it under real positive and negative identities.

Bedrock knowledge base identity governance is therefore an operating discipline: inventory identity and consent, minimize source scope, treat refresh tokens and service credentials as production secrets, measure deletion and permission-change lag, validate citations and leakage, separate development from production, and rehearse reauthorization and exit. If any layer is unverifiable, fail closed or reduce the corpus until it is.

Teams building these controls also need transferable skills in AI-system design, data engineering, scaling, evaluation, ethics, and governance. The Refonte Learning AI Engineering Program covers those foundations over a three-month program with an indicated 12-14 hour weekly commitment. The live curriculum does not explicitly list Bedrock Managed Knowledge Bases, 3LO connectors, or source ACL operations, so use it for the underlying engineering and governance skills rather than as a product-specific Bedrock certification path.