How It Works

Runtime enforcement model

HaltState does not wait until after an agent has moved money, exported data, or changed production state. The enforcement point is placed before the side effect. Every high-risk tool wrapper, worker, or service submits the action name, agent label, resource reference, risk context, and idempotency key to the guard path. The policy engine evaluates deterministic conditions such as amount thresholds, stale windows, duplicate attempts, suspicious reason codes, customer velocity, tool scope, and maintenance windows. The worker treats the guard result as authority: allow executes, approval-required pauses, and deny stops execution.

Decision outcomes

Human authority

The policy engine should remove routine review from humans, not remove human authority from the system. Low-risk actions can be allowed automatically. Medium-risk actions can require approval. Unsafe actions can be denied automatically. Human review should be reserved for actions where business context matters: an unusual refund, a sensitive customer message, a privileged data export, or an incident response decision. The agent should never be able to approve its own escalation.

Proof path

After the worker completes or refuses an action, HaltState records what was attempted, what policy decided, what the worker did, how long the decision took, which safe references identify the action, and which fields were redacted. The public surfaces show only safe labels and hashes. Internal evidence can support incident timelines, internal controls, and governance programs, while customer names, emails, payment data, raw payloads, API keys, tenant secrets, raw policy IDs, and approval IDs stay out of the public live board.

Why the refund agent matters

The retail refund agent is a concrete server-side example. It claims a ledger row, derives risk fields, calls HaltState, writes execution only when allowed or later approved, creates Proof Pack evidence, and emits a sanitized live event. That pattern generalizes to refunds, gift cards, loyalty credits, customer data exports, production writes, outbound messages, and payment actions.

Sequence in production

A production integration usually starts with a worker or backend service that already owns the real credential for the business system. That service receives or claims a unit of work, normalizes the action context, and calls HaltState. If the response is allow, the service performs the side effect and reports the result. If the response is approval-required, the service stores pending state and exits or pauses. If the response is deny, the service records the denial and does nothing further. If the response is unavailable or malformed, high-risk actions fail closed. This is deliberately boring engineering: no browser simulation, no agent self-approval, no hidden bypass path.

Where policies belong

Policies belong in the enforcement layer, not scattered across prompt text. Prompt instructions can describe desired behavior, but policy rules decide operational authority. A refund limit, a duplicate check, a stale-window rule, a PII export denial, or a production-write freeze should be expressed in machine-enforceable policy and supported by tests. The agent can explain why it wants an action; the policy engine decides whether that action is allowed.

What operators should expect

Operators should expect a system that makes safe behavior visible. The live board should show which agents are active, what type of action was attempted, whether policy allowed, denied, or required approval, whether a proof record exists, and whether redaction was applied. It should not require operators to read raw payloads to understand basic control outcomes. Protected tools can provide deeper investigation views, but the first public or executive-facing surface should prove the control loop without exposing the data behind it.

Boundary discipline

The control boundary should be reviewed whenever a new worker, integration, or emergency tool is added. A single unguarded path to the same business system can undermine the evidence story, so teams should treat guarded wrappers as owned production interfaces.

Implementation notes

Keep the HaltState call as close as possible to the side effect. The agent may plan and draft freely, but the wrapper around the actual action should be the place where authority is checked. That wrapper should send only the context required for policy evaluation: safe identifiers, normalized amounts, action names, risk flags, schedule windows, and redaction status. Raw customer payloads and secrets should stay in the business system or protected operator tooling.

Operational evidence

For each action, preserve the decision, the worker outcome, the idempotency key, safe resource references, latency, proof status, and redaction status. This evidence supports incident response and control narratives because it shows what the system did at runtime rather than only describing what the policy document intended. HaltState supports alignment work; it is not a substitute for legal advice or a compliance certification.