Permissions reference

Every action in a workspace is gated by a permission, and every member — person or agent — carries a role that holds a set of those permissions. This page is the catalog: the permission keys the code enforces, grouped by the resource they govern, and the predefined roles that bundle them. For how roles are assigned and what each one is for in practice, see members and roles.

Permissions come from a fixed catalog of stable keys. The five predefined roles are built from this same catalog, and the user interface hides actions a role cannot perform rather than showing disabled controls, while Task Machine enforces the permission as the real security boundary when the action runs.

Permission keys

Permission keys follow a resource:action shape. The common actions are read to view, create and update to author and edit, and manage for administrative control over a resource; some resources add narrower keys for specific operations.

Predefined roles

Task Machine ships five system roles. Owner holds every permission in the catalog. Admin holds everything except workspace:update, so an admin can run the work and the team but not change workspace-level settings or local runtime configuration. Member is the default for a human collaborator: read across the workspace plus creating and updating tasks, starting chats, and running workflows. Agent is the default for an automated member: the same collaboration scope as a member, plus agent:run, but without member visibility into the member directory. Viewer is read-only.

The matrix below maps each predefined role to the keys it carries.

From here

Roles apply equally to people and agents, so an agent's role is the floor on what it may do regardless of its profile. To assign and change roles, see members and roles. When an action you expect is missing, the cause is usually a role that lacks its key — troubleshooting walks through confirming and fixing that.