Access Control (RBAC)

Teams and the built-in Admin, Member and Viewer roles work on every plan. Creating or editing a custom role requires Enterprise.

​

How access is structured

A permission is a resource:action pair, for example traces:view or datasets:manage. A role is a named set of permissions. A role binding gives a role to a person, a group or an API key at one scope: the organization, a team or a project. LangWatch has three scopes: Every member of the organization has an organization role. A role binding at the organization scope applies to every team and project in it, which is how an organization Admin reaches everything. Below that, access to a team or a project comes from a binding on that team or that project.

​

Organization roles

Set the organization role per member in Settings > Directory > People. The role decides what a person can do at the organization level and how their seat is counted. A Lite Member uses a Lite seat, which is counted separately from full seats. In the settings pages a Lite Member can only be given the Viewer role on a team or a project. A group binding above Viewer applies as Viewer for a Lite Member. Also check: Members and Teams for seats, invites and how to change a member’s role.

​

Team roles

A team role applies to one team and, through inheritance, to every project in it. A binding on a single project adds access on that project only, and never removes what the team role already grants. The built-in roles are Admin, Member and Viewer. A Viewer reads. A Member creates and edits project work, sees costs, and manages its own virtual keys. An Admin also manages the team, deletes projects, and manages the AI Gateway configuration.

​

Actions

share and viewOtherPersonal are never implied by manage. Grant them explicitly.

​

Resources

Each table lists the actions a resource accepts. Resources marked organization only can only be granted by an organization-scoped binding; a team or project binding never grants them, even through a custom role that lists them.

​

Core

​

Product

​

Platform

​

LangWatch AI Gateway

​

AI Governance

​

Custom roles

A custom role is a named permission set you define. Open Roles, choose the Roles tab and select New role. You need organization:manage. Custom roles are Enterprise. A custom role has: Expand a permission category and choose None, Read or Full access for each resource. Some resources only support Read. The preview explains what the role permits at the selected scope. Select Create role to save it. The permission picker groups resources by product area. The Roles API accepts every resource and action in the tables above. To assign a custom role directly, open Settings > Directory > People and edit the person’s access, or open Settings > Directory > Teams & projects and add access to a team or project. You can also choose a role while creating an invite, or assign the role to a group in Settings > Directory > Groups. A custom role can be assigned at organization, team or project scope. An organization Admin who also holds a custom team role keeps the Admin access.

​

Role assignments

The API calls this a role binding. In the product, a role assignment is one row: who, which role and which scope. You create role assignments for users from Settings > Directory > People and Settings > Directory > Teams & projects, and for groups from Settings > Directory > Groups. Open Roles, then choose Role assignments to list every assignment in the organization. Filter it by organization, team or project scope. This tab is read only. An API key can hold bindings too. A key with restricted permissions stores its scopes as bindings on the key, and LangWatch intersects them with the permissions of the user who owns the key on every request. A key never grants more than its owner holds at that moment. A service key with no owner has no such ceiling. Also check: API Keys for how to scope a key.

​

Groups

A group gives the same assignments to many people at once. Create a group at Settings > Directory > Groups (Enterprise), add members, and assign roles at any scope. An assignment on a group applies to every member of the group, and the People tab shows it as “via” the group. A group synced from your identity provider through SCIM keeps its name and membership under the identity provider’s control: you bind roles to it in LangWatch, and the identity provider decides who is in it. Also check: SCIM Groups.

​

How a request is authorized

LangWatch first checks that the caller is an active member of the organization; a disabled member is refused, and API keys skip this check. It then collects every binding on the scope chain of the request, the project, its team and the organization, including bindings held through groups. Any binding that grants the permission allows the request; a narrower binding never cancels a wider one. An organization-scoped Admin binding grants every permission. At organization scope, every active member holds the Member organization permissions. Organization-only resources need an organization-scoped binding.