docs: sync ADP changes from cloudv2 (2026-06-15)

[micheleRP]

Syncs user-facing AI Gateway changes merged to redpanda-data/cloudv2 main in the last 24 hours.

Deploy preview

• Bedrock provider config (most relevant changed page): https://deploy-preview-101--redpanda-agentic-data-plane.netlify.app/agentic-data-plane/gateway/configure-provider/

(404s until Netlify finishes the preview build.)

Source commits

• d0f2db9 — fix(adp-ui): support Bedrock AssumeRole credentials in the LLM provider form (PR #27127, @malinskibeniamin)
• 4e764fc — feat(adp-ui): expose more well-known OAuth provider presets (@malinskibeniamin)

What changed and why

Bedrock LLM provider credential modes

The LLM provider form now renders a Credential type selector for AWS Bedrock with three modes — Default chain, Static keys, and Assume IAM role — backed by the BedrockConfig.credentials oneof (static_credentials / assume_role / unset). Previously the form rendered static keys only, and assume-role was reachable only through the API or CLI. The form now defaults to Default chain (it no longer force-seeds static credentials).

• modules/gateway/pages/configure-provider.adoc — Added Credential type, Role ARN, External ID, and Session name rows to the Bedrock field table and replaced the stale "use the API or rpk ai llm CLI instead of the form" paragraph with a description of the three selectable modes. Field semantics (required Role ARN, optional external ID gated on the role's trust policy, optional CloudTrail session name) are grounded in proto/public/cloud/redpanda/api/adp/v1alpha1/llm_provider.proto (BedrockConfig.AssumeRole).
• modules/gateway/pages/bedrock-setup.adoc — Added a step to select Static keys as the credential type before entering the access keys, since the form now defaults to Default chain. Following the guide without this step would no longer wire up the keys it walks you through creating.

OAuth provider presets

• modules/connect/pages/oauth-providers.adoc — The visible preset allowlist widened from 5 to 12 (added GitLab, Atlassian/Jira, Bitbucket, Linear, Discord, Dropbox, HubSpot). Updated the example list of catalog presets to match.

Verification

npm run build (Antora) completed successfully with no AsciiDoc errors on the edited pages.

Out of scope / noted for human review

• cloudv2 also merged a new public redpanda.api.adp.v1alpha1.SystemPolicyService (RBAC-derived policies and action groups, PR #27024). It is a backend/API surface with no UI or rpk exposure I could confirm, so I did not document it. TODO (human review): decide whether and where this belongs in the permissions docs.
• Numerous adp-ui commits in the window are UI layout, testing, and CI changes with no documented behavior impact (guardrail list filtering, viewport tweaks, e2e/visual baselines); intentionally not documented.

Reviewers

Added @malinskibeniamin as an optional reviewer for a source-accuracy check on the Bedrock and OAuth changes. Their approval is not required to merge.

[netlify]

✅ Deploy Preview for redpanda-agentic-data-plane ready!

Name	Link
🔨 Latest commit	5ddad6e
🔍 Latest deploy log	https://app.netlify.com/projects/redpanda-agentic-data-plane/deploys/6a3011f274e69200080face1
😎 Deploy Preview	https://deploy-preview-101--redpanda-agentic-data-plane.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[malinskibeniamin]

I think the oauth providers still need due dilligence/vetting. We should not promote them too much, they are sometimes in the early stages/not verified

[micheleRP]

[adp-docs PR critic]

Verdict: mostly accurate — OAuth and the Bedrock field semantics check out — but one source-accuracy issue: the "Defaults to Default chain" claim is wrong for the create form.

I reviewed the diff against cloudv2 main (proto + adp-ui form code + the cited commit d0f2db9).

Critical

• modules/gateway/pages/configure-provider.adoc and the new step in modules/gateway/pages/bedrock-setup.adoc: "Defaults to Default chain" does not match the create-form source.
  The PR description says the form "now defaults to Default chain (it no longer force-seeds static credentials)." That is true only for the edit form. Commit d0f2db9 removed ensureBedrockCredsInit (which was applied in apps/adp-ui/src/routes/_authenticated/llm-providers/$name.edit.page.tsx), so editing a provider whose stored credentials oneof is unset now correctly shows Default chain.
  The create form was not changed by that commit. createProviderConfig('bedrockConfig') in apps/adp-ui/src/routes/_authenticated/llm-providers/create.page.utils.ts (current main) still seeds:

  credentials: { case: 'staticCredentials', value: { accessKeyIdRef: '', secretAccessKeyRef: '' } }
  

  and BedrockFields derives the selected card from that case (const selectedCase = credsCase ?? 'defaultChain', apps/adp-ui/src/components/llm-providers/renderers/field-renderers.tsx). So when a user picks AWS Bedrock on the create form, the credential type defaults to Static keys, not Default chain. (finalizeCreateMessage does strip empty static refs to default-chain on the wire, but the displayed default selection is Static keys.)
  Consequences:
  • configure-provider.adoc's Credential type row stating "Defaults to Default chain" is inaccurate for the create flow the table documents.
  • The added bedrock-setup.adoc step — "For Credential type, select Static keys. (The form defaults to Default chain…)" — rests on the same premise. In practice Static keys is already the selected default on the create form, so the parenthetical rationale is incorrect (though the instruction itself is harmless).
    Source checked: create.page.utils.ts (createProviderConfig), field-renderers.tsx (BedrockFields selectedCase), commit d0f2db9 (edit-form-only change). Recommend confirming the create-form default with @malinskibeniamin before asserting "Defaults to Default chain" — this looks like a create-form vs edit-form gap in cloudv2 rather than a deliberate UX, so the safest doc wording today is to describe the three modes without claiming a specific default, or to state that the create form preselects Static keys.

Minor

• configure-provider.adoc — the Default-chain source list ("environment variables, shared config, EKS Pod Identity, IRSA, or instance profile") adds "shared config" relative to the proto comment in llm_provider.proto (env vars, IRSA, EKS Pod Identity, instance profile). It matches the in-code card description (environment, shared config, instance profile, or pod identity) and the real AWS SDK chain, so it's accurate — just not verbatim from the proto. No change needed.

Verified accurate (no action)

• OAuth presets (modules/connect/pages/oauth-providers.adoc): the visible allowlist did widen from 5 to 12. VISIBLE_PROVIDER_IDS in apps/adp-ui/src/lib/oauth-provider-presets.ts is exactly {github, google, okta, microsoft, slack, gitlab, atlassian, bitbucket, linear, discord, dropbox, hubspot}, matching the new example list (GitHub, Google, Okta, Microsoft, Slack, GitLab, Atlassian/Jira+Confluence, Bitbucket, Linear, Discord, Dropbox, HubSpot). The 10 category-chip labels match oauth-catalog-categories.ts exactly and in order.
• Bedrock field table (configure-provider.adoc): Credential type, Role ARN (required; example arn:aws:iam::123456789012:role/BedrockRole), External ID (optional; "only when the role's trust policy mandates"), and Session name (optional; CloudTrail; example redpanda-adp) all match BedrockConfig.AssumeRole in proto/public/cloud/redpanda/api/adp/v1alpha1/llm_provider.proto and the form labels added in d0f2db9. The static-keys field gating ("Static keys only.") is correct.
• xrefs: xref:gateway:configure-provider.adoc[] and xref:gateway:bedrock-setup.adoc[] use correct module prefixes and resolve to existing pages.

Also noting the PR's own "Out of scope" call on SystemPolicyService (PR #27024) looks reasonable — it's a backend API surface with no UI/rpk exposure I could find either; leaving it for human review is the right call.

---

Generated by Claude Code