Roles & permissions

Settings → Roles renders the live matrix: every permission Clarion knows about, crossed with every role, derived from the same function the API authorizes with. It cannot drift from what is actually enforced. This page explains the shape of it.

​

The four roles

​

Permission categories

The matrix is grouped the same way the permission catalog is:

​

Why authoring is Admin-only

Creating or editing an agent, a skill, or a schedule is Admin-only, and that is a security decision rather than a convenience one. An agent definition decides what runs, with which tools, against your production systems — and it runs with permissions inherited from its creator. If a Member could author agents, the effective privilege of the Member role would be “whatever an agent can be told to do.” Keeping authorship with Admins preserves the invariant that every agent traces back to an Admin who approved what it can reach. The same logic covers the other Admin-only permissions:

• Manage tool policies and manage agent pausers — these are the controls that decide which tools require approval and which agents may run at all.
• Manage escalation routing — otherwise a non-admin could reroute another agent’s pages to a destination they control.
• Retrigger issues and run issue remediation — audited, but the audit trail is not a substitute for a gate.
• View all members’ API tokens and manage all members’ API tokens — every role gets the :own variant for self-service; only Admin sees everyone’s.

​

Responding to human input

Every role holds Respond to open human input requests, but it is only consumed when Anyone can respond to human input is enabled in Workspace settings.

• Off (default): tool approvals and clarifications require Approve triage actions — Admin and Member only.
• On: any member, including read-only ones, and any teammate in the linked Slack or Teams channel, can unblock the agent. The audit log still records who did.

​

Read-only is not “Member minus writes”

Almost, but Read-only cannot View members. Neither role has workspace-wide View bounty submissions: Members instead read, triage, and decide only findings an Admin or Bounty triager assigns to them. Read-only is the posture used for shared evaluation workspaces, where the member list would tell each prospect who else is in the room.

​

Platform permissions

A few permissions in the catalog — the benchmark-scenario surface — are held by no workspace role, not even Admin. They are carried only by a Cantina platform credential. The Roles matrix omits them, because a row of empty cells in a table about workspace roles would only mislead.