Roles and access
Every member of an organization has one role. A role is a set of permissions. The server checks the permission on every request. The user interface only hides what a person may not use.
System roles
Section titled “System roles”| Permission | Admin | Operator | Viewer | Agent builder | Approver |
|---|---|---|---|---|---|
| Organization, users, roles (read and write) | yes | ||||
| Read the organization (base membership) | yes | yes | yes | yes | yes |
Audit log (audit:read) | yes | ||||
API keys (api_keys:read, api_keys:write) | yes | yes | yes | ||
| Activity, agents and knowledge (read) | yes | yes | yes | yes | yes |
| Manage agents and skills | yes | yes | |||
| Use workspaces | yes | yes | yes | yes | |
| Decide approvals | yes | yes | yes | ||
| Write knowledge | yes | yes | |||
| Approve knowledge | yes | yes | |||
| Read integrations | yes | yes | yes | ||
| Manage tools and integrations | yes |
Admins hold every permission. Support staff hold the admin set inside an open tenant switch.
Audit log
Section titled “Audit log”The audit log is the security record of the administrators. Only admins can open it. Other members still see the egress audit of their own sandboxes.
API keys
Section titled “API keys”- A key never has more permissions than the person who created it holds now. The server computes the effective permissions of a key on every request. When you demote the creator, the key loses the extra permissions at once. When the creator leaves the organization, the key has none.
- A person can only give a key permissions that they hold themselves. The permission picker offers only your own permissions.
- Admins see and manage all keys of the organization. Everyone else sees only
the keys they created. A key of another person answers
404.
Custom roles
Section titled “Custom roles”Admins can create custom roles from the permissions above. Custom roles that
still list audit:read keep it. Review them on the Roles page.