> ## 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.

# Tenancy and isolation

> Hard org boundaries, isolation defaults, and quotas across Environments, the Control plane, Evaluation, and Expert Review.

Enterprise customers get hard tenancy boundaries across Environments, the Control plane, Evaluation, and Expert Review. Isolation is enforced in the control planes, not left to agent or expert goodwill.

## How isolation is enforced

Every credential binds to exactly one org, and identity is set server-side from that credential, never from a request body. A shared control layer resolves each request to its org before anything else runs, and all resources behind it (environment sessions, policy packs, permits, evidence feeds) are partitioned per org. Your agents can only reach your tenant, because there is no request shape that names another one.

```mermaid theme={null}
flowchart TB
  A0["Org A agents and experts"] -->|"org A credentials"| CTRL
  B0["Org B agents and experts"] -->|"org B credentials"| CTRL
  subgraph AKH ["Akhara platform"]
    CTRL["Shared control layer<br/>authentication, RBAC, PDP<br/>org scope set from the credential"]
    SRC["Akhara maintained<br/>shared policy bank, environments, verifiers"]
    subgraph OA ["Org A tenant"]
      A1["Pinned shared baseline<br/>plus private policies and verifiers"]
      A2["Org-scoped keys, permits, runs, evidence"]
    end
    subgraph OB ["Org B tenant"]
      B1["Pinned shared baseline<br/>plus private policies and verifiers"]
      B2["Org-scoped keys, permits, runs, evidence"]
    end
    CTRL -->|"org A scope only"| OA
    CTRL -->|"org B scope only"| OB
    SRC -.->|"versioned copy, one way"| A1
    SRC -.->|"versioned copy, one way"| B1
  end
  style AKH fill:none,stroke:#0F0F0F,stroke-width:1px
  style OA fill:none,stroke:#0F0F0F,stroke-width:1px
  style OB fill:none,stroke:#0F0F0F,stroke-width:1px
```

This is logical isolation with scoped credentials and per-org partitions. When a regulator or data classification requires a physical boundary instead, the [self-hosted deployment model](/security/deployment-models) moves the gateway and evidence store inside your own network.

### Shared assets

Akhara maintains central, versioned repos of reusable assets: a policy bank of baseline packs (for example `pci-0`), shared environments, and shared VU-\* verifiers. Your tenant imports a pinned version of what it needs, and that copy runs entirely under your org's scope, alongside any private policies, environments, and verifiers you layer on top. Distribution is one way: definitions flow from the shared bank into tenants, but runtime state, evidence, and data never flow back into the bank or across to another tenant. Upgrading to a newer baseline version is an explicit change in your tenant, not something the shared repo pushes into a running workspace.

## Isolation bar

| Expectation                                                    | Behavior                                             |
| -------------------------------------------------------------- | ---------------------------------------------------- |
| Cross-org data (runs, trajectories, datasets, evidence)        | Denied                                               |
| Cross-workspace API access                                     | Denied: credentials bind to one org                  |
| Cross-episode state leakage in Environments                    | Denied: fresh seed on each `reset`                   |
| Cross-agent policy / permit reuse (Control plane)              | Denied: permits are single-use and agent-scoped      |
| Expert access to other orgs’ tasks or fixtures (Expert Review) | Denied                                               |
| Spoofed tenant, agent, or reviewer identity                    | Denied: identity set server-side from the credential |
| Host / orchestrator filesystem from a guest episode            | Denied: private network only                         |
| Noisy-neighbor resource exhaustion                             | Bounded queues and soft quotas                       |

## Soft quotas (illustrative)

| Quota                            | Trial (typical) | Enterprise (typical)    |
| -------------------------------- | --------------- | ----------------------- |
| Concurrent environment sessions  | 2               | 32+                     |
| Evaluations / day (Environments) | 50              | Contract                |
| Control plane `authorize` RPS    | 10              | Contract                |
| Evidence / audit retention       | 30 days         | 1 to 7 years (contract) |
| Expert seats (Expert Review)     | n/a             | Contract                |
| Dataset storage (Evaluation)     | 10 GiB          | Contract                |

Exact numbers come from your workspace contract and live usage meters. Soft quotas throttle and queue; they do not silently share capacity across orgs.

## Defaults

* **Public surface**: Eval API (`agi.akhara.ai`), Control plane PDP (`api.akhara.dev`), and documented consoles only. Orchestrators, workers, and device pools stay on the private network.
* **Auth**: Org-scoped API keys (and SSO/SAML for enterprise). Keys never authorize cross-tenant reads.
* **Episode isolation**: Each Environments run gets an isolated backend session and device assignment for that episode; teardown drops state.
* **Control plane**: Fail-closed PEP; PDP never executes customer tools; evidence feed is org-partitioned.
* **Expert Review**: Experts see only assigned packs; briefs and fixtures stay in-org; no export of other customers’ content.
* **Egress**: Environment and sandbox egress follow an allowlist on enterprise plans; trial may be open for bring-up.
* **Residency**: Enterprise can pin region (for example US or EU). Trial defaults to the primary US region.
* **Audit**: Admin and policy decisions are attributable to an org + principal; retention follows the table above.

## What we do not do

* Share device pools or catalogs across orgs in a way that exposes another tenant’s state
* Return another org’s trajectories, permits, or expert labels from any public API
* Let agents or experts choose their own tenant id in a request body

## Related

* [Security overview](/security/overview): the rest of the enterprise security story
* [Deployment models](/security/deployment-models): dedicated VPC and on-prem options when shared tenancy is not enough
* [Environments architecture](/environments/architecture): private orchestrator and workers
* [Control plane architecture](/control-plane/concepts/architecture): PDP / PEP boundary
* [Control plane fail-closed](/control-plane/concepts/fail-closed): unreachable means blocked
* [Expert Review policies](/talent/policies/overview): expert confidentiality