Skip to main content
Access to Akhara follows one rule: identity is established server-side from the credential, never from a field in a request body. A key, a session, or a permit tells the platform exactly who is acting and for which org, and nothing in the payload can widen that.

​
Single sign-on

Enterprise workspaces authenticate through your identity provider over SAML 2.0 or OIDC, including Okta and Microsoft Entra ID. Provisioning and deprovisioning follow your directory: when an employee leaves your IdP, their Akhara access ends with it.
  • MFA can be required for all users; if you enforce it in your IdP, it applies automatically
  • Session timeouts are configurable per workspace
  • Console and portal logins (Environments admin, control plane console, Evaluation app, Expert Review portal) all sit behind the same workspace identity
See OAuth 2.0 / SSO for protocol-level setup.

​
Role-based access control

Permissions are role-scoped, and roles are assigned per workspace and per project: Assign the minimum role that does the job, and prefer project-scoped roles over org-wide ones. The full matrix is in Role-based access control.

​
API credentials

API keys are org-scoped and never authorize cross-tenant reads: a credential binds to exactly one org, and the platform derives the tenant from the key, not from the request. For automation:
  • Create dedicated service accounts per pipeline instead of sharing user keys
  • Scope keys to specific projects and operations (scopes and permissions)
  • Restrict keys by source IP range where your network layout allows it
  • Rotate keys on a schedule; every use is written to the audit log

​
One-time permits for consequential actions

A long-lived API key is the wrong credential for an irreversible action. In the control plane, an ALLOW verdict on an action stage mints a one-time permitId: single-use, agent-scoped, and consumed when the action executes. A stolen or replayed permit authorizes nothing, and every side effect stays joinable to the exact verdict and policy that authorized it. This narrows the blast radius of any credential compromise: even a valid key cannot re-run a consequential action without passing verification again. See verdicts and audit and evidence.