Document AWS Bedrock IAM role setup for BYOLLM, including Oz cloud runs#92
Conversation
Rewrite the BYOLLM auth section to describe the OIDC + role-assumption flow that Warp actually uses for AWS Bedrock inference, and extend the docs to cover Oz cloud agent runs in addition to interactive terminal agents. Highlights: - Replace the local AWS CLI session-credentials path with a trust policy + permissions policy + AWS CLI setup script that admins follow once per team. - Use scoped_principal:<team-uid>/* in the trust policy so a single role works for human-triggered interactive and cloud runs as well as named-agent service-account runs. Note the full sub claim shape so admins can scope further if they want. - Update prerequisites, troubleshooting, and FAQ to match the new auth model. Companion to the Oz Bedrock plumbing on iw/add-aws-region-to-oz-runs in warp-server. Co-Authored-By: Oz <oz-agent@warp.dev>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
…z section The team-wide trust policy (Step 2) is now scoped to scoped_principal:<team-uid>/user:* for human team members. Named-agent runs authenticate as service accounts, not users, so they need separate handling. Add a new top-level 'BYOLLM on Oz' section that covers the named-agent flow: - Explains the actor-type difference between human runs (user:<user-uid>) and named-agent runs (service_account:<service-account-uid>). - Provides two patterns for authorizing named agents: a wildcard service_account:* for all team agents, or per-UID conditions for a subset. - Documents how to find the team UID (Admin Panel) and named-agent UIDs (GET /api/v1/agent/identities or the Oz web app URL). - Documents the per-agent inference_providers.aws override in the public API, including role_arn / region / disabled and the trust-policy implications. Co-Authored-By: Oz <oz-agent@warp.dev>
- Split Step 3 into team-wide and per-agent paths - Reorder cloud agents steps so AWS setup precedes Admin Panel config - Add Step for setting up Warp as an OIDC identity provider in AWS - Use team-wide wildcard pattern as default trust policy - Link to Oz web app new agent docs and credit-buckets reference Co-Authored-By: Oz <oz-agent@warp.dev>
# Conflicts: # src/content/docs/enterprise/enterprise-features/bring-your-own-llm.mdx
|
I'm starting a first review of this pull request. You can view the conversation on Warp. I completed the review and no human review was requested for this pull request. Comment Powered by Oz |
There was a problem hiding this comment.
Overview
This PR updates the BYOLLM documentation to cover AWS Bedrock OIDC role assumption for cloud agent runs and revises billing, troubleshooting, and FAQ wording. The new cloud-agent flow is useful, but several parts need correction before merge because the IAM isolation guidance and data-retention wording can mislead enterprise admins, and the troubleshooting section now drops the still-documented local terminal credential path.
Concerns
- The per-agent setup presents a safety guarantee while the example trust policy still authorizes any cloud-hosted run from the team.
- The troubleshooting section removed local AWS credential guidance even though the page still documents interactive terminal BYOLLM using local AWS CLI credentials.
- The cloud-agent credential wording expands the page scope without correcting the existing no prompt/response retention claim for cloud run transcripts.
Security
- Narrow per-agent IAM trust policies to the intended
service_accountsubject when documenting per-agent role setup. - Clarify cloud-agent data retention separately from temporary AWS credential retention so the page does not overpromise what Warp stores for cloud runs.
Verdict
Found: 0 critical, 3 important, 0 suggestions
Request changes
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
hongyi-chen
left a comment
There was a problem hiding this comment.
Overall
Strong, useful update — the new cloud-agent section fills a real gap (the previous doc said BYOLLM didn't apply to cloud agents) and the trust-policy / CLI scaffolding is helpful for AWS admins. The page builds, and the internal link checker reports 0 broken links across the repo. All linked anchors in the new content resolve (#creating-a-new-agent, #the-three-credit-buckets, #step-2-provision-iam-roles-cloud-admin, the agents.mdx page).
Most of my notes are style-guide nits and consistency calls, plus one structural concern about how the two flows live on a single page. Inline comments below.
Found: 1 critical, 3 important, 5 suggestions, 2 nits.
Recommendation: Approve once the cross-reference fragility (#196), the now-half-true "Cloud-native credentials" bullet (line 22), and the named agent / agent identity terminology split are addressed. The rest are polish.
hongyi-chen
left a comment
There was a problem hiding this comment.
approving to unblock, left some minor nits - i think this is good to go out
Co-authored-by: Hong Yi Chen <hongyigma@gmail.com>
… into iw/docs-bedrock-oz-setup
Documents how enterprise AWS admins set up the IAM role + OIDC trust policy that lets Warp assume into their AWS account for AWS Bedrock inference. Companion to the Oz Bedrock plumbing on
iw/add-aws-region-to-oz-runsinwarp-server.The previous BYOLLM page described a local AWS CLI session-credentials flow (
aws login). This PR rewrites those sections to match how the warp client actually authenticates: short-lived credentials obtained via OIDC +sts:AssumeRoleWithWebIdentity. It also extends the docs to cover Oz cloud agent runs in addition to interactive terminal agents.What's covered
app.warp.devin prod,staging.warp.devin staging), restrictssubtoscoped_principal:<team-uid>/*, and requiresaudto equalsts.amazonaws.com. The/*wildcard matches both theuserandservice_accountactor types so a single role works for interactive terminal use, Oz cloud agent runs triggered by humans, and named-agent runs.bedrock:InvokeModel+bedrock:InvokeModelWithResponseStreamagainst foundation models and inference profiles.subshape —scoped_principal:<team-uid>/<actor-type>:<principal-uid>so admins who want to scope further (e.g./user:*or/service_account:*) know how.aws loginlocally" prerequisite/step/troubleshooting wording with the role-assumption flow. Removed the caveat that "Cloud agents do not yet support BYOLLM routing."Notes for reviewers
main(which had since been force-pushed and no longer contained those changes).Warp conversation