Policies

Policies are declarative. Each one names the consequential actions it governs, the verifiers it runs, and the verdict every situation maps to, so a latch’s behavior is auditable before it ever fires.

Baseline vs. attached

Every workspace carries an enterprise baseline that sits under every agent and cannot be un-latched:

ID	Latch
`latch-0`	User Confirmation Policy
`latch-1`	Regulated Product & Substance Authorization
`latch-2`	High-Risk Recommendation Escalation
`latch-3`	Eligibility & Coverage Determination
`latch-4`	Refund & Billing Exception Authorization
`latch-5`	Payment & Funds Movement Authorization

On top of the baseline you attach domain packs per agent. The effective set the PDP evaluates is the union:

attachedPolicyIds = ENTERPRISE_BASELINE_POLICY_IDS ∪ agent.policyIds

Common packs: pci-0 (Cardholder Data Protection), reliability-3 (Human Escalation on Risk), reliability-4 (Fail-Closed Defaults), plus industry families such as healthcare-*, finance-*, and insurance-*. The cookbooks show the industry packs in context.

Attach policies

akhara policies attach support-ai pci-0 reliability-3

PUT /api/agents/support-ai/policies
Content-Type: application/json

{ "policyIds": ["pci-0", "reliability-3"] }

Policy IDs follow family-index (pci-0, healthcare-2) or custom_<slug> for org-authored packs.

From policy to verifier

A pack starts as policy prose (a regulation, a contract clause, an internal rule) and is crafted into machine-checkable parts:

Extract the conditions. Each obligation in the prose becomes one testable check, a verifier.
Map the verdicts. Decide ahead of time which situations ALLOW, WARN (with a rewrite), BLOCK, or ESCALATE.
Name the actions it governs. The pack latches only onto those consequential actions; everything else passes through untouched.

Anatomy of a policy pack

{
  "id": "pci-0",
  "name": "Cardholder Data Protection",
  "family": "pci",
  "blurb": "Masking and minimization of cardholder data on customer surfaces.",
  "tags": ["PCI", "cardholder-data", "context-egress"],
  "checks": [
    "PAN masked before display",
    "No CVV in output or logs",
    "Cardholder data minimized on context egress"
  ],
  "verdicts": [
    { "verdict": "BLOCK", "when": "output contains an unmasked PAN or any CVV" },
    { "verdict": "WARN",  "when": "context egress includes non-essential cardholder fields",
      "rewrite": "redact non-essential cardholder data" },
    { "verdict": "ALLOW", "when": "cardholder data is masked and scoped to the task" }
  ],
  "requirements": ["PCI DSS 3.3", "PCI DSS 3.4"]
}

Field	Purpose
`checks[]`	Each string becomes a runtime verifier in the registry. See Verifiers.
`verdicts[]`	The verdict-behavior mapping: what fires and when.
`requirements[]`	Source law/reg/contract, shown at the bottom of the pack in the console.

The verdict-behavior mapping

This is the part enterprises care most about: it makes the latch’s decision legible ahead of time. Each policy exposes its ALLOW / WARN / BLOCK / ESCALATE conditions so reviewers can see exactly when an agent will be stopped.

Baseline behavior by stage (reference deployment)

How the shipped policies decide at each stage:

Stage	Behavior
`input`	Requests for prohibited or regulated products → `BLOCK` (`latch-1`); otherwise `ALLOW`.
`context_egress`	With a privacy pack attached, minimize sensitive fields → `WARN` + rewritten content; otherwise `ALLOW`.
`output`	Cross-customer personal data → `BLOCK` (`latch-0`); high-risk recommendation language → `WARN` (`latch-2`); emergency language → `ESCALATE` (`reliability-3`); else `ALLOW`.
`delivery`	Empty content → `BLOCK`; otherwise `ALLOW`.
`action`	Only declared consequential tools are eligible; the governing latch’s checks → `BLOCK` / `ESCALATE` / `ALLOW` + permit.

Custom policies

Packs authored in the console are stored client-side (localStorage: akhara-custom-policies) for design and preview. To make a custom pack enforce at runtime, publish it so the PDP loads it server-side. See the publish flow.

Next: craft verifiers

Author the individual checks your policies run.

Get started

How it works

Enterprise onboarding

Cookbooks

SDK

Baseline vs. attached

Attach policies

From policy to verifier

Anatomy of a policy pack

The verdict-behavior mapping

Baseline behavior by stage (reference deployment)

Custom policies

Next: craft verifiers

​Baseline vs. attached

​Attach policies

​From policy to verifier

​Anatomy of a policy pack

​The verdict-behavior mapping

​Baseline behavior by stage (reference deployment)

​Custom policies

Next: craft verifiers

Baseline vs. attached

Attach policies

From policy to verifier

Anatomy of a policy pack

The verdict-behavior mapping

Baseline behavior by stage (reference deployment)

Custom policies