Workspace security

Roles, SAML SSO, and workspace MFA, plus how the API reports each policy failure.

Every dashboard read and every /api/* route resolves the caller's session to a workspace and role through a single helper, which also enforces the workspace's MFA and SSO policies in the same step. A session that fails a policy is stopped in one place: the dashboard redirects, the API returns a structured 403. (Gateway traffic is different: the hot path authenticates by agent or site API key, not a human session.)

Roles

Four roles, ranked. A route gated at a minimum role accepts that role and everything above it.

Role	Rank	Summary
`viewer`	0	Read-only: dashboards, audit log and exports, policy simulation and backtests.
`member`	1	The default minimum for API routes; day-to-day reads and writes.
`admin`	2	Operational configuration: API keys, webhooks, broker secrets, SIEM log streams, response rules, the evidence bundle.
`owner`	3	Workspace governance: SSO setup, the require-SSO toggle, workspace data export.

Where the line falls in practice:

Downloading an audit log export needs only viewer: GET /api/audit/export-download. (The export feature itself is plan-gated, available on Team and above; the role bar stays at viewer.)
Creating a webhook endpoint or rotating one is admin: POST /api/webhook-endpoints and POST /api/webhook-endpoints/{id}/rotate.
Configuring SAML SSO is owner (POST / PATCH / DELETE /api/sso/connection); admins may read the connection (GET).

An unauthenticated call gets 401 {"error":"unauthorized"}; an under-privileged one gets 403 {"error":"forbidden"}.

SAML SSO

SAML single sign-on (Okta, Entra ID, Google Workspace SAML) is a Team plan and above feature, and only the workspace owner can change it, from Settings → Security. Setup is a three-step lifecycle:

Claim a domain. Enter your company email domain (e.g. acme.com) and pick the default role for provisioned members: viewer, member, or admin.
Prove you own it. Add a DNS TXT record with the value axiorank-verify=<token> shown in the dashboard, then click Verify. The connection moves from pending_dns to verified.
Connect your IdP. Create a SAML app in your identity provider using the ACS URL and Entity ID (audience) shown in the dashboard, then paste the IdP's metadata URL (HTTPS only) to activate. The connection is now active.

Once active, sign-ins for the claimed domain route through your IdP, and the first SSO sign-in joins the workspace automatically at the default role (just-in-time provisioning).

Requiring SSO

With an active connection, the owner can turn on Require SSO for all members. Members who signed in with a password or Google are asked to come back through SSO; the dashboard redirects them, and API calls return 403 {"error":"sso_required"}.

Owner break-glass

Owners are exempt from the require-SSO policy, so the workspace stays recoverable if your IdP has an outage.

Disabling SSO returns sign-ins to password and Google. The domain stays verified, so re-activating later skips the DNS step.

MFA

Admins and above can require two-factor authentication for the whole workspace from Settings → Security. Turning the requirement on demands that the acting admin's own session has already verified a second factor, so an admin can never lock themselves out by flipping it on. The second factor is TOTP (an authenticator app such as 1Password, Google Authenticator, or Authy).

When the policy is on, a session is checked against it on every resolve. Two states fail the check, and /auth/mfa handles both:

Challenge: a factor is enrolled but this session has not presented it yet. The user enters the 6-digit code from their authenticator app.
Enroll: the user has no factor. The page walks through inline TOTP enrollment (a QR code, plus a manual setup key for devices that can't scan), then verifies the first code.

On success the session is upgraded. A step-up challenge sends the user back to the page they were originally headed for; a fresh enrollment lands on the dashboard. Until then, API calls from that session return 403 {"error":"mfa_required","mfa":"challenge"} (or "mfa":"enroll"), so a client can distinguish "go verify" from "go set up a factor".

Auditing this posture

The compliance evidence bundle snapshots all of the above in its access/access-review.json file: the MFA and require-SSO flags, the SSO connection (domain, status, default role), and the full member roster with each member's role. See Evidence bundle.

Next steps

Webhooks: the admin-gated delivery endpoints referenced above.
Audit integrity: the signed ledger that exports and the evidence bundle build on.