Roles and permissions

Organization roles control team management. Product roles control operations inside one product. The same role name does not make those two scopes interchangeable.

Organization roles

Role	Authority
Owner	Organization management, renaming, security policy, billing summary, deletion, and member role changes.
Admin	Manage invitations, product shares, and role definitions; create products. Cannot change organization security, access billing, or change member organization roles.
Member	No organization-management authority; sees products explicitly shared with them.

Owners and admins receive concrete grants on the organization’s products. Members do not receive product access just by joining.

Product roles

Role	Allowed operations
Owner	All operations.
Admin	All except billing and product deletion.
Member	Everyday create, update, list, get, me, and select operations; excludes role-management changes.
Viewer	Read operations: list, get, me, and select; excludes role-management changes.

System roles are immutable. Member and Viewer permissions follow operation verbs rather than a fixed list of features.

Assignment rule	Limit
One role per product member	Define combined permissions instead of stacking roles.
Owner assigns product roles	Owner itself is not assignable with `organization_product_set-access`.
Admin assigns product roles	Can assign admin, member, or viewer.
Self-demotion	Refused.
Organization role change	`organization_member_set-role` accepts only admin or member and requires an owner.

Custom role definitions

Operation	Tool
List	`organization_roles_list`
Read	`organization_roles_get`
Create	`organization_roles_create`
Update	`organization_roles_update`
Delete	`organization_roles_delete`

Every organization member can read definitions. Owners and admins can create, edit, and delete custom definitions; system roles remain read-only.

A definition has a name and allow/deny pattern lists. Assign it with roleId, or supply an ad-hoc permissions object on an invitation or share. Those are alternatives to a preset role: choose exactly one. Permissions are copied at assignment, so later edits or deletion of the definition do not change existing grants. Identical permission sets can share the same underlying role.

Pattern matching

A permission key identifies an operation, such as organization_product_create. For MCP, the key is the tool name.

Pattern	Match
Exact key	That operation only.
`organization_*_list`	`*` matches one underscore-separated segment.
`organization_*`	A trailing `*` matches one or more remaining segments.
`*`	All keys.

An operation must match an allow pattern and no deny pattern. A deny match wins; no allow match means denied.

Permission catalog

organization_permission_catalog returns key, display_name, group, level, and scope. Read the catalog when composing a role rather than assuming an operation’s level from its name.

Scope	Meaning
`product`	Grantable in product roles and permission pickers. The call needs a product context; over MCP that is the tool’s product argument, `product_id` or `productId`.
`user`	Informational for role composition. The operation checks identity and its own membership or organization-role requirements.

A user-scoped write operation is not automatically allowed to every user. For example, an integration access request checks product membership; approving it checks organization owner/admin status.

Two-factor policy

Owner-controlled setting	Effect across several organizations
Require two-factor authentication	Required if any organization requires it; unenrolled members enroll at their next sign-in.
Allow remembered devices	The 30-day skip is available only if every organization allows it.

See two-factor authentication for enrollment and recovery behavior.

Was this page helpful?