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 refund latch

latch-4 (Refund & Billing Exception Authorization) governs the refund_payment tool. Watch it stay dormant, then latch:
1

Answering an order question, dormant

checkOutput("your order shipped Tuesday") matches no consequential action. Verdict: ALLOW. latch-4 never fires.
2

Refund requested, latch engages

authorizeAction("refund_payment", { orderId, amount }) matches latch-4. The PDP checks the amount against the auto-approval limit and the session’s verification state.
3

Verdict binds the action

  • Within limit, identity verified → ALLOW + permitId
  • Over the limit → ESCALATE (route to a supervisor)
  • Identity not verified → BLOCK
4

Permit gates the side effect

paymentService.submit(refund, permitId) refuses to run without the permit, so a blocked/escalated action can’t leak through.
For the same lifecycle applied to prescriptions, card cancellation, and claim payouts, see the cookbooks.

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