Roles and permissions (RBAC)
| Role | Typical person | Highlights |
|---|---|---|
admin | platform owner | all permissions |
agent-engineer | builds agents | write and publish agents, run and cancel runs, manage own API tokens |
integrator | connects systems | manage event sources and connections, read policies |
operator | runs the service | run, cancel and approve runs |
auditor | compliance, security | read, verify and export the audit trail; read policies, connections, users, settings |
viewer | everyone else | read agents, runs, events and costs |
Permissions
Section titled “Permissions”agents:read|write|publish, runs:read|execute|cancel|approve, events:read,
sources:read|write, connections:read|write, policies:read|write,
audit:read|verify|export, costs:read, users:read|write, tokens:read|write,
settings:read|write.
Nobody can change or delete audit entries; the audit trail is append-only by design.
A role binding is { role, teamId }. teamId: null grants the role globally; otherwise it
applies to the team’s agents, runs and connections. API tokens for machines can carry scopes
that narrow their permissions further. Tenants and per-agent bindings are described in
Tenants and per-agent access.
Sign-in
Section titled “Sign-in”Coming with the API OIDC (Keycloak, Entra ID, Okta and others), LDAP/AD bind with group-to-role mapping, a local admin bootstrap account and hashed, scoped, expiring API tokens. Every API route declares the permission it needs, and tests enforce it.