What should an AI agent policy include before go-live?

Write down the operating contract

• Scope and owner: registered agent, environment, tools, resources and policy owner. List unsupported or unconnected paths separately.
• Inputs: action name, tenant and resource identifiers, amount and currency, destination and relevant risk flags. Decide what happens when a required input is absent or malformed.
• Decisions: explicit permitted and prohibited cases, review thresholds and precedence when rules overlap. Test the unmatched-action case rather than assuming its default.
• Review: which requests may use council review, which require a named human authority, the expiry window and what the caller does while waiting. A pending request must not execute.
• Failure and retry handling: the selected SDK contract, network timeout behaviour, stable business-operation identity and destination safeguards. Do not turn an uncertain result into a second refund or send.
• Containment: who can pause the registered agent, the pause duration and the boundary that consumes the stop. A pause does not undo completed actions or guarantee remote-process termination.
• Evidence: recorded reason, historically bound policy version where available, outcome reports, external references, content capture and retention. Define who can investigate or export.
• Change ownership: who reviews a policy change, which representative cases must pass again and how the previous configuration can be restored.

Run concrete launch checks

The following are acceptance cases to configure for your workflow, not claims about universal HaltState defaults. Use harmless test operations and verify both the decision and what the application actually attempted.

1. Permitted: an authorised request inside your limit proceeds and records its reported outcome.
2. Prohibited: a forbidden destination or resource is denied; the business operation is not called.
3. Review required: a configured review case waits. Approval permits only the authorised operation; rejection and expiry do not execute it.
4. Uncertain: a missing required amount, an unmatched action and a policy-service timeout each follow the behaviour your team explicitly selected.
5. Repeated or delayed: a repeated request and a delayed outcome report do not accidentally repeat the business action. Verify the particular SDK/runtime contract and the destination's safeguards.
6. Paused: the selected agent's subsequent governed action is blocked through the tested boundary, while an unrelated agent remains unaffected.
7. Investigable: an operator can find the activity, reason, linked evidence and actual content availability. Verify signatures on signed packs and disclose missing policy versions or external confirmations.

If your limits depend on totals across many actions, check that the relevant state is actually supplied and evaluated. A per-request amount limit alone does not enforce an aggregate spending limit.

Apply the checklist with HaltState

Review and activate policies for the connected action, then follow the relevant SDK guide. Policy-resolved requests do not need council calls; eligible council reviews can resolve requests without human review. An unresolved council review escalates, while an explicit human-approval rule remains human-only.

Check the approval lifecycle, containment design guide and investigation guide against the integration you are deploying. New signed Proof Packs protect the recorded evidence's integrity; they do not fill in an unreported outcome or independently confirm an external effect.

Record the tested configuration, remaining coverage gaps and the responsible owner's launch decision. Start with one consequential action, then extend coverage deliberately. The production governance guide covers the broader operating model.

Related questions