Permissions
Roles (see Authentication) are just named bundles of permissions. Every permission is a resource:action key, and the catalog is more granular than the five role names suggest.
The permission catalog
| Resource | Actions |
|---|---|
workflow | create, view, update, delete, manage |
execution | create, view, update, delete, manage, resume (HITL) |
agent | create, view, update, delete, manage |
workspace | create, view, update, delete, manage |
workbook | create, view, update, delete, manage |
assignment | create, view, update, delete, manage |
credential | view only |
auth-identity | create, view, update, delete |
role | create, view, update, delete, manage |
permission | create, view, update, delete, manage |
member | create, view, update, delete, manage, invite |
invitation | create, view, update, delete, manage |
organization | create, view, update, delete, manage |
tenant | create, view, update, delete, manage |
| singletons | billing:manage, owner:manage, dev-session:use, ui:view |
owner holds every key above, and viewer holds none of them explicitly. It gets read access through plain membership instead. The other three roles are where it's worth seeing exactly what's granted:
| Permission | admin | operator | developer |
|---|---|---|---|
workspace:view | yes | yes | yes |
workflow:view | yes | yes | yes |
workflow:update | yes | yes | yes |
execution:view | yes | yes | yes |
execution:create | yes | yes | yes |
execution:resume (HITL) | yes | yes | no |
agent:view | yes | yes | yes |
agent:create | yes | yes | yes |
agent:manage | yes | yes | yes |
credential:view | yes | no | yes |
auth-identity:view / create / update / delete | yes | no | yes |
dev-session:use | yes | no | yes |
ui:view | yes | yes | yes |
tenant:delete, billing:manage, owner:manage | no | no | no |
Everything else in the catalog (workflow:create/delete, member:*, role:*, permission:*, tenant:create/view/update, organization:*, ...) | yes | no | no |
The shape: admin is everything except the three owner-only keys at the bottom. operator is a run/approve slice. It can resume a paused execution but can't touch credentials or identities. developer is a build slice. It can manage credentials and identities but can't resume a HITL wait itself.
credential vs. auth-identity
They're not the same thing. An auth identity is a connection instance, a provider credential referenced by credentialId in an agent's AgentModelConfig, or an OAuth connection behind a Gmail/Slack/Outlook trigger. It carries a name, a provider, a scope (tenant, environment, or workspace), and the secret material itself (stored in AWS Parameter Store, never inlined in your workflow definition). auth-identity:create/update/delete is how those connections get made, changed, or removed, and credential:view never exposes the secret values themselves either way.
A credential entity is the provider definition behind those connections: "Anthropic authenticates with an API key," "Gmail is OAuth with these scopes," and so on. That's what credential:view actually gates: listing or reading the catalog of supported providers.
Grants are scoped, and they stack
A grant is (role, environment?, workspace?). Leave both empty and the role applies tenant-wide; set an environment and it applies only there; set a workspace too and it's scoped to just that one. The same person can hold different roles at different scopes at once, tenant-wide developer plus admin in one specific workspace, for example, and their effective permissions are the union of every grant they hold. You can't scope to a workspace without also pinning an environment.
Managing grants today
Grants are managed in the Console under Settings → Members, not the CLI. Custom roles and editable permission bundles are on the roadmap.