Roles and permissions

This catalogue helps tenant administrators and security reviewers choose roles and understand exactly what an operation permission allows. It covers 185 permission identifiers in 14 families, including 142 selectable in custom tenant roles and nine built-in functional roles.

Use the docs search for an exact identifier such as mcp.server.create, a role such as Data Builder, or a family such as Tenant. Each permission has a linkable entry with its meaning, scope, built-in grants, custom-role eligibility and implied permissions.

Permission families

How access is decided

A permission names an operation, such as data.ingestion.run. A role bundles permissions. A resource relationship determines whether a caller may perform that operation on a particular object.

For tenant-scoped operations, access combines:

1. Current tenant membership. A role assignment does not create membership.
2. Operation permission. This can come from baseline membership, an applicable administrator assignment, a functional system role or a custom role, including group-inherited assignments.
3. Resource and request checks. Ownership, sharing, workspace or namespace access, tenant boundaries and endpoint-specific prerequisites still apply.

For example: Data Builder → data.ingestion.run → invoker access on the ingestion → required source and destination access. The functional role alone does not authorize every ingestion in the tenant.

Platform-administration permissions apply at installation scope and are not granted through tenant custom roles. Shared catalogue permissions with a platform. prefix are explicitly marked as tenant-scoped in their entries.

Read a permission entry

“Baseline member” includes users with any of the nine system roles. “Yes” under custom role does not mean the permission is absent from baseline access. The catalogue is additive, not a deny-policy system.

Write implications are specific, not wildcard rules. For example, mcp.server.delete implies update, list and read. It does not imply server creation. An implication does not bypass an independent resource check.

The catalogue describes permission semantics, not a promise of a separate endpoint or portal control for every identifier. Entries that represent model authority without a dedicated operation say so. Use your deployment's BSQAI API reference for the available routes.

Define a custom role

Custom roles belong to one tenant and can be assigned to eligible tenant users or ordinary groups. They cannot grant platform administration, tenant-administrator status or resource ownership. They do not remove baseline access or access supplied by other roles.

For an MCP configuration editor, a minimal role definition is:

{
  "name": "MCP configuration editor",
  "description": "Update existing tenant MCP server registrations.",
  "permission_ids": ["mcp.server.update"]
}

This adds update authority, with list/read implied. It does not grant server creation or deletion. Current members already have the baseline server-use gate. Resource credentials remain personal.

Creating this role requires tenant.role.create; assigning it requires tenant.role.assign. Changes to custom roles synchronize asynchronously. A 202 response means the change was accepted, not that access or revocation has already taken effect. Updates and assignment changes to an existing custom role require its current expected_version; stale versions return 409.

Inspect your deployment

Authenticate to the BSQAI API and select the tenant as described in Access and tenant context. Reading the following endpoints requires tenant.role.list:

GET /v1/authz/roles without a filter returns both role kinds and the same baseline list. baseline_permissions describes tenant membership, not the caller's effective access, and is not an assignable role. Resource ownership and sharing checks still apply.

The live permission-catalogue endpoint reports permissions selectable in custom roles for your deployment, rather than the full reference shown here. Listing a role or permission does not grant it. These pages describe the 1.4.0 catalogue; compare with the deployed API when reviewing a different version.

Related pages

• System roles and baseline access
• Tenant settings
• Security model
• Multi-tenancy and tiered RBAC