Policies

Latch domain policies onto an agent on top of the always-on enterprise baseline.

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

CLI

akhara policies attach support-ai 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:

1. Extract the conditions. Each obligation in the prose becomes one testable check, a verifier.
2. Map the verdicts. Decide ahead of time which situations ALLOW, WARN (with a rewrite), BLOCK, or ESCALATE.
3. 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.