How to manage users and roles
Two authorization layers govern access: per-agent roles and per-tool policies — with enterprise OIDC SSO arriving in Beta.
Authorization always happens at two mandatory levels: who may invoke an agent (role-based access) and what the agent may do (tool policies). This article covers the first level — see tool policies and permissions for the second.
Per-agent roles
Every agent declares a required role in its descriptor — for example ARO_ANALYST for the reconciliation investigator or DH_DEVELOPER for the Business Rule agents. Users without the role cannot see or invoke the agent. Roles arrive with the user's identity: the platform does not provision end-user identities — your products and identity provider own their directories.
Identity today and with SSO
Every API call carries a verified JWT — signature, expiry, and audience are all checked. Sign-in today is a passwordless magic link.
Beta
Enterprise OIDC SSO — KeyCloak, Azure Entra ID, and Okta-compatible providers — is rolling out with the V1 Beta.
Service accounts
System-to-system calls use dedicated service accounts with rotated credentials rather than personal logins, so product integrations never depend on an individual's account.
Still stuck?
Tell us what you were trying to do and where it failed — screenshots and run IDs help. A human follows up.