> ## Documentation Index
> Fetch the complete documentation index at: https://docs.akhara.ai/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Company name is Akhara AI (never Rubric AI). Keep lowercase rubric/rubrics only when meaning grading criteria.
> Expert Review (docs path talent/) is enterprise BYO experts for audit and review: invite customer specialists; do not pitch Akhara recruiting or a public expert career portal. RLHF and domain writing are secondary work types.
> Prefer concrete API examples against public hosts: Environments eval API https://agi.akhara.ai, Control plane PDP https://api.akhara.dev, Evaluation https://app.akhara.ai / https://api.akhara.ai, Expert Review portal https://talent.akhara.ai.
> Do not invent a public hostname for private orchestrators or env API internals.
> Do not confuse control-plane latches with Environments confirmation latches.
> Environments SDK/API examples: curl against https://agi.akhara.ai. Evaluation SDK: from akhara import Akhara and AKHARA_API_KEY.
> Start with /llms.txt for the docs index and OpenAPI links; fetch individual pages as .md exports.

# Access and authentication

> SSO with your identity provider, role-based access control, MFA, org-scoped API keys, and one-time permits for consequential actions.

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](/evaluation/api-reference/authentication/oauth) for protocol-level setup.

## Role-based access control

Permissions are role-scoped, and roles are assigned per workspace and per project:

| Role               | Permissions                                                |
| ------------------ | ---------------------------------------------------------- |
| Organization admin | Full access, user management, security settings            |
| Project admin      | Full project access, team management, integrations         |
| Evaluator          | Create evaluations and runs, manage datasets, view results |
| Reviewer           | Submit reviews on assigned samples and runs                |
| Viewer             | Read-only access to results and reports                    |
| API only           | Programmatic access for service accounts, no UI            |

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](/evaluation/api-reference/authentication/rbac).

## 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](/evaluation/api-reference/authentication/scopes))
* 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](/evaluation/api-reference/authentication/audit-logs)

## 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](/control-plane/concepts/verdicts) and [audit and evidence](/control-plane/concepts/evidence).