> ## 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.
# Overview
> The four moving parts: PDP, PEP, latches, and permits.
Akhara has a deliberately small vocabulary. Learn these four terms and the rest
of the platform follows.
## Policy Decision Point (PDP)
The PDP is Akhara itself, the service that **decides**. It evaluates the
policies attached to an agent and returns a [verdict](/control-plane/concepts/verdicts). It
**never executes your tools** and never needs network access to them, so it can
govern agents it cannot see inside.
In the reference deployment the PDP is the console/API server on port `5599`.
## Policy Enforcement Point (PEP)
The PEP is the thin client you embed in your agent's runtime, it **enforces**.
For each risky step it makes a synchronous `authorize` call to the PDP and blocks
until a verdict comes back. Because the call sits *in front of* the side effect,
the PEP is where "you may not do that" actually takes effect.
The PEP is intentionally tiny: one HTTP call, one decision object, and a
[fail-closed](/control-plane/concepts/fail-closed) default.
## Latch
A **latch** is a policy that activates only when an agent attempts the exact
consequential action it governs. A refund latch is invisible while the agent
answers order questions, and snaps shut the moment the agent tries to move
money. See [Latching](/control-plane/concepts/latching).
## Permit
A **permit** (`permitId`) is a one-time authorization id the PDP mints **only**
for an `ALLOW` verdict on an `action` stage. Your side-effecting service should
refuse to run without one, that's what makes an authorized action
distinguishable from an unauthorized one at the point of execution.
***
## How they relate
```mermaid theme={null}
flowchart LR
subgraph RT["Your runtime (agent is a black box)"]
A["Agent step"] --> P["Akhara PEP
(SDK, in-process)"]
end
P -- "authorize(stage, content/tool)" --> D["Akhara PDP
decision point · api.akhara.dev"]
D -- "verdict + permitId" --> P
D -- "policy_decision event" --> F[("Evidence feed
events.jsonl")]
P -->|ALLOW / WARN| C["Continue"]
P -->|BLOCK| X["Stop"]
P -->|ESCALATE| H["Hold for human"]
subgraph POL["Attached policies"]
B["Enterprise baseline
latch-0 … latch-5"]
Dm["Domain packs
pci-*, healthcare-*, finance-*, …"]
end
POL -.governs.-> D
```
The agent proposes; the PDP disposes. The component that wants to act (the agent)
is never the component that authorizes it (the PDP): that separation of duties
is the whole point.
Deployment topology and the request lifecycle.
How the PEP intercepts steps and what context crosses to the PDP.
How and when a policy latches onto a step.
ALLOW, WARN, BLOCK, ESCALATE.
Why unreachable means blocked.
Signed records and full trajectories for every decision.