Skip to main content
Dust gives you three workspace roles and a set of granular permissions. Together, they control what people can manage, create, publish, and access in your workspace.

​
Roles

​
Admin

Admins have full workspace administration access. They can configure workspace settings, manage members and groups, and control permissions. Admins always retain access to capabilities set to Admin only. By default, Admins can:
  • Manage billing and subscriptions
  • Manage security settings, user access, identity verification, and provisioning
  • Configure governance permissions
  • Enable or disable the policy for sharing Frames externally
  • Enable or disable audit logs

​
Manager

Managers are delegated workspace administrators. They can:
  • Invite and remove members
  • Change the roles of non-admin members
  • Assign the Manager and Member roles
  • View workspace analytics and usage page
  • Access the Groups tab and set group spend limits
  • Review and act on credit upgrade requests from members
  • Choose which groups can create and publish agents and skills
Managers do not receive billing or security access by default. Admins can grant these permissions to groups when needed. Managers cannot manage the policy for sharing Frames externally or audit logs. When the external Frame sharing policy is enabled, Managers can configure which groups may invite users to Frames and make them public.

​
Member

Members use Dust according to their seat, group memberships, resource access, and granted permissions. Members do not have administrative access by default. Admins can grant Members additional permissions through groups.

​
Groups and permissions

Dust supports two types of groups:
  • Provisioned groups, synchronized from your identity provider through SCIM
  • Manual groups, created and managed in Dust
Permissions are granted to groups rather than directly to individual people. To grant a permission to one person, create a manual group, add that person to it, and grant the permission to the group. Permissions are additive. If a person belongs to several groups, they receive the combined permissions granted by those groups. A group grant adds access and does not remove access granted elsewhere. Each permission uses one of three modes:

​
Managing groups with the workspace management MCP server

Admins and Managers can also manage groups programmatically through the workspace management MCP server, using four tools:
  • list_groups: list workspace groups, optionally filtered by kind
  • get_group_members: list a group’s current members
  • create_group: create a new manual group with an initial member list
  • update_group_members: add or remove members from an existing manual group
These tools only see and manage provisioned (SCIM) and manually-created groups. Internal group kinds used by Dust are not exposed, even to a caller who knows their ID.

​
Permission matrix

The following permissions are available in the workspace governance settings. Making a skill discoverable to agents, or changing the availability of an already discoverable skill, requires the Make skills discoverable to agents permission (Settings & Governance → Skills). It’s Admin only by default; users without it cannot enable or change auto-discoverability. Granting it without also granting Manage skill availability has no effect: a group needs both to act on it.

​
Workspace governance settings

Workspace settings and permission controls are managed under Settings & Governance. Billing and security are permissions, not separate roles. Admins receive access by default. Admins can delegate either permission to selected groups without changing those members’ workspace roles.

​
The Builder role

The Builder role is being replaced by separate permissions for creating and publishing agents and skills. During the transition, workspaces that used the Builder role receive a Builders group. Existing builders are added to that group, which preserves their agent and skill creation access without preserving a broad Builder role. API keys using the builder role receive the legacy Builders group instead. The API key role is removed in the end state. Admins can move those permissions to other manual or provisioned groups as their workspace model evolves.

​
How access is determined

A person’s effective access combines:
  1. Their workspace role
  2. The permissions granted to their groups
  3. Their access to specific resources, such as spaces, agents, skills, and other workspace content
These sources of access are additive. A permission granted through one group does not remove access granted through another group or through the person’s workspace role.