aigw
Use case

Role-based access control (RBAC) for AI

One shared key and all-or-nothing access does not survive an audit. aigw ties every AI call to a role and a scope, so people and services get only the models and controls they should.

The problem

Most teams start with one provider key everyone shares. There is no way to say “this team can use these models,” “this service is read-only,” or “only admins change policy.” Access is all or nothing, and no one can prove otherwise.

How it works

Give each person or service a role, and each key a model allow-list. Roles grant a level per resource, from view to full, so a viewer can watch spend but not change a policy. If you use SSO, map identity-provider groups to roles, so access follows your directory instead of a spreadsheet.

What you get

  • Roles with a permission level per resource (keys, providers, policies, logs, billing, and the rest), defaulting to deny for anything not granted.
  • Built-in owner, admin, editor, and viewer roles, plus custom roles.
  • A per-key model allow-list, enforced at the gateway on every call.
  • SSO group-to-role mapping, so joiners and leavers are handled by your IdP.

See governance and keys.