Roles, permissions and security controls

Access is scoped per workspace. Every member holds exactly one role in each workspace they belong to, and the role travels inside the access token, so every service applies the same rules without asking the auth service on each request.

Roles

Role	Meant for
Owner	The person accountable for the workspace: billing, settings, security policy. There is always at least one.
Admin	Runs the team day to day: invites, roles, project access, the audit log.
Member	Does the work: projects, test plans, datasets, runs, credentials, connectors.
Viewer	Reads everything, changes nothing. For stakeholders, auditors and dashboards.

Platform operators (SUPER_ADMIN) act as an Owner in any workspace. That is a separate, platform-wide role and is not assignable from a workspace.

Permission matrix

Area	Owner	Admin	Member	Viewer
View projects, test plans, datasets, runs, reports, traces	yes	yes	yes	yes
Create and edit projects, test plans, datasets, custom metrics	yes	yes	yes	no
Start and stop evaluation runs	yes	yes	yes	no
Add, edit and delete credentials and connectors	yes	yes	yes	no
Create and revoke API tokens	yes	yes	yes	no
Restrict a project to specific members	yes	yes	no	no
Invite members, change roles, remove members	yes	yes	no	no
Read and export the workspace audit log	yes	yes	no	no
Rename the workspace, change its slug	yes	no	no	no
Require two-factor authentication for all members	yes	no	no	no
Billing: plan, payment method, invoices	yes	no	no	no

A request outside the role's column is refused by the API with 403, whatever the interface tried. The web app hides or disables the corresponding controls and shows viewers a read-only notice.

Your own account is always yours: profile, password, two-factor settings and the list of your sessions do not depend on any workspace role.

Two-factor authentication

Any member can turn on two-factor authentication under Settings → Two-factor auth. Scan the QR code with an authenticator app (1Password, Google Authenticator, Authy and the like), confirm with a code, and store the ten recovery codes somewhere safe: each signs you in once if the phone is gone, and they are shown only at that moment.

Once enabled, every sign-in asks for a code after the password. Signing in with Google or GitHub asks for it too.

Requiring it for the whole workspace

An Owner can switch on Require two-factor authentication under Settings → Workspace. The Owner has to have two-factor on their own account first.

From then on, a member without two-factor cannot open the workspace: signing in lands them on a page that explains why and links to the setup; switching to the workspace is refused; a session that was already open loses access at its next token refresh, within fifteen minutes. Their other workspaces are unaffected. Once they enable two-factor, access resumes on its own.

The policy change is written to the audit log as WORKSPACE_MFA_POLICY_CHANGED.

Sessions

Settings → Sessions lists every browser where your account is signed in, with the device, IP address and last activity. Sign out any you do not recognise, or all but the current one. Changing your password or email signs out every other session as well.

A refresh token that is presented again after it was already rotated is treated as a stolen copy: the whole session it belongs to is signed out and the event is recorded as SESSION_REUSE_DETECTED.

Audit log

Owners and Admins see the workspace's audit trail under Settings → Audit log: sign-ins, two-factor and session events, membership and role changes, credential and API-token changes, and exports of the log itself. Filter by event type or actor, and export the current view as CSV for an auditor. Events are kept for 180 days.