CommandChain checks two different kinds of permission, and knowing which one an error is about saves a lot of hunting.
Kind Looks like Decides Registry key tasks:editWhat a person may do. Held per person, ticked in the roles grid, and named in API errors Route gate manage_integrationsWhether a page renders at all. Read by the app before it draws a route
Registry keys are the ones you assign. Route gates follow from whether someone is a workspace admin, so they are not separately assignable: see create a role for how the two meet in practice.
These are the rows of the permission grid on the Roles page. The three columns on the right are the starting bundles the grid offers: Administrator , Team Member , and Viewer . They are templates you tick and untick from, not roles. The workspace owner holds every key regardless.
The Agent column marks a key an agent may hold only with human approval behind it.
Key Grants Agent Admin Member Viewer agent:runExecute agent tasks yes yes agent:view_metricsView agent execution metrics and statistics yes yes yes agent:approve_high_riskApprove high-risk agent operations approval yes agent:approve_low_riskApprove low-risk agent operations yes yes agent:view_tasksView agent task history and status yes yes yes agent:cancel_tasksCancel running agent tasks approval yes
Key Grants Agent Admin Member Viewer agents:viewView agent profiles and configurations yes yes yes agents:manageCreate, update, and delete agent profiles approval yes
Key Grants Agent Admin Member Viewer org:manage_rolesCreate and modify roles approval yes org:manage_membersInvite, remove, and manage members approval yes org:view_membersView the member list yes yes yes org:view_settingsView workspace settings yes yes yes org:edit_settingsModify workspace settings approval yes
Key Grants Agent Admin Member Viewer models:viewView available AI models yes yes yes models:editConfigure AI model settings approval yes models:view_usageView AI model usage statistics yes yes yes
Key Grants Agent Admin Member Viewer teams:manageCreate, update, and delete teams approval yes teams:viewView team information yes yes yes teams:assign_membersAdd or remove team members approval yes
Key Grants Agent Admin Member Viewer governance:view_auditView the audit trail yes yes governance:manage_policiesCreate and modify governance policies approval yes governance:manage_tokensCreate and revoke permission tokens approval
Key Grants Agent Admin Member Viewer meetings:createCreate new meetings yes yes meetings:manageUpdate and delete meetings approval yes meetings:viewView meeting details and history yes yes yes meetings:chatSend messages in meetings yes yes
Key Grants Agent Admin Member Viewer tasks:createCreate new tasks yes yes tasks:viewView task details and status yes yes yes tasks:editUpdate task details yes
Key Grants Agent Admin Member Viewer mcp:servers:viewView MCP server configurations yes yes yes mcp:servers:createRegister new MCP servers approval yes mcp:servers:updateModify MCP server configurations approval yes mcp:servers:deleteRemove MCP servers approval yes mcp:servers:discoverRun tool discovery on an MCP server yes mcp:usage:viewView MCP usage metrics and audit logs yes yes
Key Grants Agent Admin Member Viewer tenant.profile.readView the company profile , its versions, proposals, references, and audit yes yes yes tenant.profile.editApprove or reject proposals, restore versions, edit directly, approve references approval yes
Key Grants Agent Admin Member Viewer marketing:manage_campaignsCreate and manage campaigns , content assets, and workflows marketing:publish_approveApprove externally visible publish actions approval marketing:manage_autonomyView and change autonomy levels per action class approval integrations:manage_bindingsPropose, verify, activate, and disable integration category bindings approval
The marketing keys and governance:manage_tokens belong to none of the three
bundles, so a role seeded from a preset does not get them. Tick them yourself
after picking a preset, or the person you seated will find those pages refuse
to act.
These decide whether a page draws. They are not ticked anywhere: everyone gets the first group, and workspace admins get the second.
Key Held by Gates view_tasksEveryone Nothing today. Task pages are open to every member create_taskEveryone Nothing today view_meetingsEveryone Nothing today view_personal_assistantEveryone The Eva assistant page view_reviewsEveryone Nothing today view_approvalsEveryone Nothing today view_notificationsEveryone The notifications page view_agentsEveryone Nothing today manage_org_rolesWorkspace admins Roles , users , rubrics manage_integrationsWorkspace admins Integrations , GitHub , Slack , MCP servers , agents, the runner fleet , and runner pairing manage_tokensWorkspace admins Permission tokens manage_router_policyWorkspace admins Router policy manage_model_policyWorkspace admins AI runtime , model catalog , budgets manage_tool_policyWorkspace admins Nothing today manage_skill_graphsWorkspace admins Skill Graph Studio and skill authoring with Eva manage_task_gatesWorkspace admins The Approve and Deny buttons on a paused run, rather than a page view_policy_learningWorkspace admins Policy learning view_audit_logWorkspace admins The audit log
“Nothing today” means exactly that: the key exists and always answers yes for the group that holds it, and no page consults it. It is listed so that finding it in a stack trace does not send you looking for a screen it hides.
An API answer names the registry key it wanted:
{ "code" : " FORBIDDEN " , "message" : " Missing required permission: tasks:edit " }
That string is a row in the grid above. Find it on the Roles page, tick it for the role in question, and the same request succeeds. A missing route gate never produces this: the page redirects to the access-denied screen before a request is made.
