Permission scope catalog

A scope is the unit of permission. Every action a person or an agent can take is gated by one, and a role is a bundle of scopes. This page is the complete list: more than 140 scopes, grouped by the area they govern, each one marked with its danger level and a plain description of what it grants. When you are building a custom role and need to know exactly which scope gates an action, or you are reviewing what a role can reach, this is where you confirm it.

The roles and permissions guide explains how scopes work and how to assemble a role; this page is the flat list it points back to. Every entry here is read from the product, so a scope id, its danger level, and its area are the exact values the role editor and the permission check use.

How to read a scope

Every scope shares one shape and carries one danger level, and a few carry a flag worth knowing.

The id. A scope id is lowercase and dot separated, naming a subject and an action. plans.manage is the manage action on plans; audit.export is the export action on the audit log. Some ids qualify the subject further, like secrets.tenant.read or conversations.read.own. The shape is consistent, so once you can read one scope you can read all of them.

The area. Every scope belongs to one of nine areas, which is how this catalog and the role editor group them. The area is a property of the scope, not always a part of its id, so members.read and audit.export both sit in the Tenant area even though neither id begins with the word tenant.

The danger level. Every scope is marked with one of four levels, which the role editor uses to show you the weight of what you are granting.

• low covers reading and self-service. Listing plans, viewing the plan and entitlements, managing your own sessions. The blast radius is small.
• elevated covers privileged writes. Creating and editing records, managing members, running flows, rotating secrets. Most management scopes sit here.
• destructive covers the irreversible. Exactly three scopes carry it: tenant.delete deletes the workspace, members.remove revokes a member's access, and pr.merge merges straight to the default branch. The role editor asks you to confirm these before they go onto a custom role.
• platform-only is operator territory. Exactly one scope carries it, and it can never be granted to a workspace role.

The flags. Three optional markers change how a scope is checked, and the flag reference at the end lists exactly which scopes carry each one.

• A scope that needs an entitlement is inert unless your commercial plan includes it, even when a role grants it.
• A self-only scope acts only on your own records. Your sessions, your notifications, your conversations.
• A resource-scoped scope is checked against a specific project, portfolio, team, or profile rather than the whole workspace, so a grant reaches only the resources you have access to.

The nine areas

Scopes are grouped into nine areas, which is also how the role editor lays them out.

Tenant

Workspace identity, the people in it, and the records that govern it.

Auth

Your own identity and account, always self-only.

Platform

The admin surface: providers, repositories, MCP, SDK configs, secrets, sandbox profiles and hosts, and the workspace's agent instructions, commands, and docs. The read scopes are low; the manage scopes that change shared configuration are elevated.

Planning

The work model and everything that acts on it. Project, portfolio, and sprint scopes are checked against the resource you are reaching.

Membership

The per-resource grant tiers for a single team, portfolio, or project, each checked against that resource. They stack: view, then contribute, then plan.

Chat and sandbox

Working with the agent, and the sandboxes and pull requests that work produces.

Notifications

Your own notifications and what you watch.

Events

The real-time channel.

Operator

The one operator-only scope. It can never be assigned to a workspace role.

Scopes with a flag

Most scopes are plain workspace-wide grants. These carry a flag that changes how they are checked.

Need an entitlement. These four are inert unless your plan includes the matching entitlement, even when a role grants them: audit.export, ai-spend.export, mcp.manage, status-skills.manage.

Act on your own records only. These self-only scopes are satisfied automatically for your own records and reach no one else's: every me.* scope, members.leave.own, mcp.auth.user.manage, secrets.user.manage, integrations.user-credential.manage, conversations.read.own, conversations.manage.own, sessions.cancel.own, tasks.cancel.own, notifications.read.own, notifications.watch.manage, and events.stream.read.

Checked against a resource. These are checked against the specific project, portfolio, team, or profile you are reaching rather than the whole workspace: sandbox-profile.use, projects.read, projects.manage, portfolios.read, portfolios.manage, sprints.manage, and all nine membership scopes (team.*, portfolio.*, project.*). Of these, sandbox-profile.use is the one checked against a list on the profile record itself; the rest are checked against your access to the resource.

One question the catalog answers

A reviewer is handed a custom role called Release Captain and asked a single question: can someone holding it push code straight to the default branch without a pull request? The role lists about forty scopes, and the answer has to come from the catalog, not from trust.

They scan the Chat and sandbox area for the branch-affecting scopes and find three. pr.submit, elevated, opens a pull request from sandbox changes. pr.merge, destructive, merges a branch directly into the default branch, with no review step in between. sandbox.ide.access, elevated, opens an IDE on a sandbox. The Release Captain role carries pr.submit and sandbox.ide.access but not pr.merge. The question is answered: this role can open a pull request and work in a sandbox, but the one scope that bypasses review is absent, and its destructive level is why it stood out on the list in the first place.

That is the catalog working as a review surface. The danger level draws the eye to the scope that matters, the description says exactly what it grants, and a role's reach is a reading of its scope set rather than a judgment call.

Why the catalog is shaped this way

The model is legible because there is no hidden layer. Every action the product or an agent can take resolves to one of the scopes on this page, the same scope the route checks and the role editor shows, with no separate rulebook behind it. That is why the catalog can be exhaustive: there is nothing to leave out, because a capability that is not a scope is not a capability. When you read that a role grants bugs.manage and not pr.merge, you know exactly what it can do with a bug and what it cannot do to a branch.

The danger levels are the other half of the design, and they exist so a permission decision is a reading task rather than a guess. A scope marked destructive is destructive whoever holds it, and the role editor surfaces that weight at the moment you grant it rather than leaving you to find out later. The same agent that does your work is bound by the same scopes a person is, so the catalog is not only how you reason about your teammates' access. It is how you reason about the agent's.

For an administrator, this is the working surface behind every custom role. When you are deciding what a role should reach, the scope is the unit you grant, and the danger level is how you weigh it. The built-in roles page shows how the eleven shipped roles draw from this same list.

For a power user, the catalog explains why an action is or is not available to you. A control you cannot see is a scope your roles do not carry, and this page names which one.

For an enterprise reviewer, the value is the completeness. A claim about least privilege is checkable only against a full list of what privilege there is, and this is that list: every gateable action, its blast radius, and whether it is gated by a license, your own ownership, or a single resource.

For a prospect, the takeaway is the shape. A platform that lets agents act on your work has to answer one question: what exactly can act, and on what. A model where every capability is one named, leveled scope answers that with a list you can check, not a reassurance you have to take on faith.