Built-in roles

The eleven roles Disco Parrot ships, who each is for, and the scopes each one carries. The role reference behind every permission decision.

A role is a named bundle of scopes. Disco Parrot ships eleven of them, covering the people a workspace actually has: the owner, the admins, the members who do the work, the planners who shape it, the operators who run the tooling, the finance contact who needs the bills, and the stakeholders who only watch. This page is the reference for all eleven: who each is for, how they stack, and what each one can reach. When you are deciding which role to give someone, or building a custom role and want to start from what a shipped role already does, this is where you confirm it.

The eleven roles cannot be edited. They are the platform's baseline, the same in every workspace, so a role name means the same thing everywhere. When the shipped set does not fit, you build a custom role from the scope catalog, and the built-ins are the reference you start from. The concept behind roles, assignment, and the permission check is on roles and permissions; this page is the flat reference it points back to.

Two kinds of role

The eleven split into two kinds, by where they are assigned.

Workspace roles are assigned to a person's membership in the workspace and govern what they can do across it. There are eight: Owner, Admin, Member, Viewer, Lead, Planner, Workspace Operator, and Billing Manager.

Resource roles are assigned on a single team, portfolio, or project, and govern only that resource. There are three: Membership Viewer, Membership Contributor, and Membership Planner.

The two kinds do not cross over. A workspace role cannot be granted on a single project, and a resource role cannot be granted workspace-wide. That separation is enforced, so a role always means the thing its kind implies.

The eight workspace roles and three resource roles, with what each one adds. Member, Admin, and Owner nest into one spine; Viewer and Planner are a separate read baseline; Lead and Workspace Operator build on Member; Billing Manager stands alone. The three resource roles nest the same way on a single resource.

A person can hold more than one

The two kinds are assigned in different places, so one person commonly holds both: a workspace role that sets their floor across the workspace, and a resource role on a specific team, portfolio, or project. When that happens, their reach is the union of every scope their roles carry. A Member who is also a Membership Planner on one project reads the workspace like any Member and plans that one project, and nothing about the second grant reaches any other project. Reach only ever adds; a role can widen what a person can do, never narrow what another role already granted. So the way to read a person's access is to read every role they hold together, not to pick the highest one.

One person, two grants. A workspace role sets the floor across the workspace; a resource role adds reach on one team, portfolio, or project. Effective reach is the union of both, and the resource grant never spills past its own resource.

How the workspace roles stack

Most of the workspace roles build on one another, which is the fastest way to hold the set in your head.

Member is the baseline for someone who does the work. Admin is Member plus the workspace management scopes. Owner is Admin plus the one scope that deletes the workspace. So Member sits inside Admin sits inside Owner.
Viewer is a separate, read-only baseline for someone who only watches. Planner is Viewer plus the scopes that manage the planning work, so a planner reads everywhere and manages the records.
Lead is Member plus the ability to see and cancel teammates' runs, for someone coaching a team.
Workspace Operator is Member plus the scopes that run the platform tooling, including the workspace secrets.
Billing Manager stands on its own: licensing, audit, and AI spend, with no access to the work itself.

What each workspace role can do

Role	Read the workspace	Run the agent	Manage the planning records	Manage platform tooling	Manage members and roles	See audit and AI spend	Delete the workspace
Member	Yes	Yes	No	No	No	No	No
Viewer	Yes	Read only	No	No	No	No	No
Lead	Yes	Yes	No	No	No	No	No
Planner	Yes	Limited	Yes	No	No	No	No
Workspace Operator	Yes	Yes	No	Yes	No	No	No
Billing Manager	Licensing and audit	No	No	No	No	Yes	No
Admin	Yes	Yes	Yes	Yes	Yes	Yes	No
Owner	Yes	Yes	Yes	Yes	Yes	Yes	Yes

Two columns need a word. "Run the agent" is Limited for a Planner because a Planner manages the planning work and can chat, but does not operate sandboxes or ship pull requests the way a Member does.

info

"Manage the planning records" means editing a record by hand. A Member still gets work done without it, because running the agent writes those records during a run. The column tracks manual edits, not what the agent produces on a Member's behalf.

Choosing a role

Most assignments come down to a few questions. If the person only watches, give them Viewer. If they do the work with the agent, Member, and add Lead if they also coach a team's runs or Workspace Operator if they keep the tooling configured. If they own the plan but not the platform, Planner. If they run the workspace, Admin, and Owner for the single person who can delete it. The finance contact who needs the bills and nothing else is Billing Manager. When none of these is the right floor, clone the closest one and adjust from the scope catalog.

The workspace roles in full

add_photo_alternate

Screenshot to capture

The Roles page in Settings: a single filled card with one row per role, built-in roles listed first. Each row shows a role icon, the role name such as Owner, Admin, Member, or Planner, a scope count like 130 scopes, a member count like 4 members, a small outline badge for where it can be assigned such as Tenant, and a Built-in badge with an Updated timestamp. A New custom role button sits in the page header.

save as: public/docs-media/roles-list.png

Caption when added: The eleven built-in roles in Settings, each showing its scope count and where it can be assigned.

Member

The default role every new member receives. A Member reads across the whole workspace and does the work: chatting with the agent, running flows, operating sandboxes, opening pull requests, and managing their own sessions and background tasks. A Member does not manage the workspace or edit the planning records by hand; that is what Planner and Admin are for. Member is the floor that Admin, Owner, Lead, and Workspace Operator all build on.

Admin

A workspace administrator. Admin is everything a Member can do, plus the management of the workspace: inviting and re-roling members, managing custom roles, configuring providers and integrations, managing sandbox profiles and hosts, rotating workspace secrets, managing the planning records, and reading and exporting the audit log and AI spend. Admin can do everything except delete the workspace.

Owner

The single owner of the workspace. Owner is everything an Admin can do plus the one scope that permanently deletes the workspace. There is exactly one Owner, and the owner cannot be removed or re-roled without transferring ownership first.

Viewer

A read-only role for stakeholders, observers, and external reviewers. A Viewer reads across the workspace, can open chat to ask questions, and can view and export reports, but changes nothing. Viewer is the separate baseline that Planner builds on.

Lead

A Member with cross-actor visibility, for someone coaching a team on agent-assisted work. A Lead can do everything a Member can, and can also read teammates' conversations and background tasks and cancel any session or task. It is the role for a team lead who needs to see and unstick a teammate's run without holding full admin rights.

Planner

The planning-area lead. A Planner reads everywhere, like a Viewer, and manages the planning work: initiatives, plans, goals, bugs, test cases, documents, sprints, teams, projects, portfolios, and flows. A Planner shapes and manages the work without holding the workspace's administrative scopes, so it is the role for a program manager who owns the plan but not the platform settings or the member list.

Workspace Operator

The role that owns the workspace's tooling. A Workspace Operator is a Member plus the management of repositories, providers, MCP servers, SDK configs, integrations, sandbox profiles and hosts, agent instructions, commands, platform docs, onboarding, and the workspace secrets, which it can read and rotate by design. It does not manage members, roles, the audit log, or AI spend; those stay with Admin. It is the role for whoever keeps the platform configured.

Billing Manager

A narrow role for a finance or operations contact. A Billing Manager sees the plan and entitlements, the audit log, and AI spend, and can export the audit log and AI spend, with no access to the work itself. It is the role for the person who needs the bills and the records without needing the workspace.

Owner is a superset, not a special case

It is worth being precise about the Owner role, because it is the one most platforms get quietly wrong. An Owner can read and do everything in the workspace, but not because the Owner role is special-cased anywhere in the permission check. The check has no notion of who the owner is. Owner can do everything an Admin can and then delete the workspace, for the same reason Admin can do what it does: the role carries the scope for each action, listed out one by one. The power is in the list, not in the role's name. There is no read-bypass, no "owners see all" branch, no path where an owner is waved through a check that everyone else has to pass.

This matters for a security review, because it means the Owner role is auditable the same way every other role is: by reading its scope set. The thing that makes Owner powerful is visible in the catalog, not hidden in an exception. The same holds for the agent, which is bound by the scopes of the person it acts for and never inherits a bypass of its own.

add_photo_alternate

Screenshot to capture

The detail view of the built-in Owner role in Settings: a header with the role name Owner, a Built-in badge, and its scope count, above the scope list grouped into the same area sub-sections used in the catalog, with headings like Tenant, Planning, and Platform Admin. Each row shows a scope identifier in monospace, its plain-language label, and its danger badge, with destructive scopes such as tenant.delete and pr.merge present and badged. The list reads as a full enumeration rather than a summary.

save as: public/docs-media/owner-role-scope-detail.png

Caption when added: The Owner role opened to its scope list. Owner is powerful because it carries the scope for everything it can do, listed the same way Admin is, with nothing special-cased.

The resource roles

The three resource roles are assigned on a single team, portfolio, or project, and they stack the same way the membership scopes do.

Role	What it grants on the resource
Membership Viewer	Read-only access to the team, portfolio, or project.
Membership Contributor	Viewer, plus commenting on and editing existing content. Cannot delete or re-plan.
Membership Planner	Contributor, plus creating and editing the resource's content and settings. Cannot transfer ownership.

Custom roles

When the eleven shipped roles do not fit, you build a custom role from the scope catalog. A custom role is workspace-local, you choose its scopes one by one, and a few guardrails keep the result sound: the operator-only scope can never be added, a destructive scope has to be confirmed before it goes on, a custom role cannot take the name of a built-in, and cloning a built-in to start from gives you its scopes minus anything operator-only. The full how-to is on roles and permissions. The built-ins on this page are the reference you build against.

Why the roles are shaped this way

The shipped roles are not an arbitrary set of presets. They are the roles a real team already has, named, so that the common case needs no configuration at all. A workspace can run from day one with an owner, some admins, members doing the work, and a viewer or two, and never touch the scope catalog at all. The shipped roles are the configuration most teams will ever need. The roles being immutable is part of that: because Admin means the same scopes in every workspace, an answer to "what can an Admin do" is portable, so the only thing anyone has to study to understand a workspace's access is its custom roles. The built-ins already mean what their names say everywhere.

The split between the read baseline and the work baseline is the design decision worth noticing. Member and Viewer are not the same role with a switch flipped; they are two starting points, one for people who do the work and one for people who watch it, and Planner grows from the watcher while Lead and Workspace Operator grow from the worker. That is why so few roles cover the team a workspace actually has: each one starts from the right floor, and the floors were chosen to match how teams are actually shaped.

For an administrator, these eleven are the menu, and the matrix above is the fastest way to pick. When none fits, clone the closest built-in and adjust from the scope catalog rather than starting from nothing.

For a power user, your role is why a control is or is not in front of you. If you can read a record but not edit it, your role carries the read scope and not the manage scope, and this page names which role would.

For an enterprise reviewer, the design to weigh is that Owner is a superset with nothing special-cased, so an access review is a reading exercise with no exceptions to chase.

For a prospect, the takeaway is that the model is small enough to trust. Eleven named roles, each a visible bundle of leveled scopes, with the same agent bound by the same rules as the people, is a permission story you can hold in your head and hand to a security team.

key

Permission scope catalog

Every scope these roles draw from, by area and danger level.

shield_person

Roles and permissions

The concept behind roles, and how to build and assign a custom one.

group

Members and invitations

Assigning roles to the people in your workspace.