Skip to main content
Latching is the behavior that distinguishes Akhara from a prompt guardrail. A policy is dormant by default and carries no cost until an agent attempts the specific consequential action it governs. At that moment it latches onto the step and the agent cannot proceed without a verdict.

​
The effective policy set

For any authorize call, the PDP evaluates the union of the always-on baseline and the policies attached to that agent:

​
When a latch fires

Evaluation happens at the five enforcement stages. The engine matches the stage, the content, and (for actions) the normalized tool name against each attached policy.

​
Worked example: the renewal latch

latch-1 (Prescription & Controlled Substance Authorization) governs the renew_meds tool. Watch it stay dormant, then latch:
1

Chatting about labs, dormant

checkOutput("your LDL improved to 142") matches no consequential action. Verdict: ALLOW. latch-1 never fires.
2

Renewal requested, latch engages

authorizeAction("renew_meds", { medication: "atorvastatin" }) matches latch-1. The PDP checks medication identity and prescriber authority.
3

Verdict binds the action

  • Eligible, non-controlled → ALLOW + permitId
  • Missing authority → ESCALATE (route to a clinician)
  • Controlled substance → BLOCK
4

Permit gates the side effect

MedicationRenewalService.submit(medication, permitId) refuses to run without the permit, so a blocked/escalated action can’t leak through.

​
Tool normalization

Latches match on a canonical tool name, so your agent’s naming doesn’t have to match the catalog. The PDP trims, lowercases, and applies aliases before matching: Declare tools with whatever names your agent already uses. See Agents.