feat: add organization-ai-gateway-access role and enforce it at the AI Gateway#27280
Draft
jscottmiller wants to merge 2 commits into
Draft
feat: add organization-ai-gateway-access role and enforce it at the AI Gateway#27280jscottmiller wants to merge 2 commits into
jscottmiller wants to merge 2 commits into
Conversation
…I Gateway Extracts the aibridge_interception create/update grants out of the site member role and the organization-member/service-account floors into a new built-in org role, organization-ai-gateway-access. The role is appended to organizations.default_org_member_roles by migration and to rbac.DefaultOrgMemberRoles() for new organizations, so existing members keep AI Gateway access. Interception RBAC objects are now scoped to any organization so the member-scoped perms of the new role authorize holders in any org they belong to. Org admins are explicitly excluded from the org-level aibridge grant to preserve the existing invariant that only site-wide auditors and owners can read interceptions. The AI Gateway enforces the permission at authentication time. aibridgedserver.IsAuthorized previously validated only the API key and user status; interception recording happens under the aibridged system subject, so the initiator's own permissions were never consulted. Now the initiator must be authorized to create an AI Bridge interception (granted by the new role) or the request is rejected with ErrNoAIGatewayAccess, which the HTTP layer surfaces as 403. The check expands the user's roles (including custom roles) and evaluates with the API key's scope set, so restricted-scope tokens cannot route AI traffic unless their scope carries the interception create permission. rolestore.Expand now accepts a narrow store interface so the aibridged server's store can satisfy it. The default-roles preset cards map Gateway to the new role and Workspace to workspace-access plus ai-gateway-access, and the Edit Roles UI gains descriptions for both organization-workspace-access and organization-ai-gateway-access.
…e under permission-based licensing Under permission-based licensing, AI Gateway access is licensed by the AI Governance addon and gated by the organization-ai-gateway-access role rather than per seat. RecordInterception therefore no longer records ai_seat_state usage for the initiator when the permission-based-licensing experiment is enabled; task workspace builds still claim seats. Existing aibridge-reason seat rows are left in place and age out when users are suspended or deleted.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Extracts the
aibridge_interceptioncreate/update grants out of the sitememberrole and the organization-member/service-account floors into a new built-in org role,organization-ai-gateway-access, and enforces it at the AI Gateway.Role extraction
aibridge_interception: create, update. It is appended toorganizations.default_org_member_rolesby migration (idempotent) and torbac.DefaultOrgMemberRoles()for new organizations, so existing members keep AI Gateway access with no behavior change by default.AnyOrganization().WithOwner(initiator)) so the member-scoped perms authorize holders in any org they belong to. Org admins are explicitly excluded from the org-level aibridge grant, preserving the invariant that only site-wide auditors and owners can read interceptions.organization-workspace-accessandorganization-ai-gateway-access.Enforcement
aibridgedserver.IsAuthorizedpreviously validated only the API key and user status; interception recording happens under the aibridged system subject, so the initiator's own permissions were never consulted. Now the initiator must be authorized to create an AI Bridge interception or the request is rejected withErrNoAIGatewayAccess(HTTP 403). The check expands the user's roles (including custom roles) and evaluates with the API key's scope set, so restricted-scope tokens cannot route AI traffic unless their scope carries the interception create permission.rolestore.Expandnow accepts a narrow store interface so the aibridged server's store can satisfy it.Seat recording
Under the
permission-based-licensingexperiment (introduced in #27279),RecordInterceptionno longer recordsai_seat_stateusage for the initiator: AI Gateway access is licensed by the AI Governance add-on and gated by the role rather than per seat. Task workspace builds still claim AI Governance seats.Part of the gateway-accounts exploration.
Stack
Part 2 of the gateway-accounts stack. Each PR builds on the previous:
permission-based-licensingexperiment and gated on the AI Governance add-on,user_limitcounts only users the RBAC engine authorizes to create workspaces.organization-ai-gateway-accessorg role carrying the AI Bridge interception permissions (extracted from the member floors, backfilled into org default roles by migration) and enforces it at AI Gateway authentication; bridge usage stops claiming AI Governance seats under the experiment.use_sharedcapability precondition for workspace ACL grants, so workspace sharing is ineffective for (and rejected toward) users without workspace capabilities, evaluated live on every authorization.Related but independent: #27278 hides the Workspaces page create CTAs for users without workspace-create permission.