What Is Pre-Dispatch Governance for AI Agents?

The problem: post-hoc controls are late by design

Agent incidents usually do not start as model-quality issues. They start as action-control issues. A tool call runs with the wrong scope. A production write is executed without approval. A risky command is allowed because no deterministic gate exists before execution.

Post-hoc monitoring can detect that failure. It can page on-call. It can produce a strong incident report. It cannot reverse a side effect that already ran.

That is why pre-dispatch governance exists. It puts an enforceable decision boundary before execution so the control point can block, gate, or constrain an action while there is still something to prevent.

Research baseline: top-ranking guides and the implementation gap

On April 1, 2026, I reviewed high-ranking resources for AI agent governance to identify common guidance and missing implementation details. Rankings change by region and time, but the recurring gap is stable.

This guide focuses on that missing implementation layer: decision contracts, out-of-process enforcement, fail-mode defaults, and operation-ready rollout patterns.

Definition: what pre-dispatch governance actually means

Pre-dispatch governance means every proposed action is evaluated against policy before state mutation and before tool execution. The policy engine returns a typed decision. Execution behavior is then deterministic.

The contract is typed, not implied

If the policy input is vague, the outcome will be inconsistent. You need explicit action metadata: topic, capability, actor identity, risk tags, labels, and tenant scope.

{
  "job_id": "run_42:infra_apply@1",
  "tenant_id": "default",
  "topic": "job.infra.apply",
  "capability": "infra.mutate",
  "risk_tags": ["production", "write", "irreversible"],
  "labels": {
    "environment": "production",
    "service": "billing"
  }
}

Reference architecture: where the enforcement point lives

A practical control boundary for OpenClaw security looks like this: the plugin intercepts actions, forwards metadata to a local daemon, and the daemon calls the policy engine out of process.

How this maps to Cordum and CordClaw

Cordum enforces policy in two places. The gateway performs submit-time checks before persistence and bus publish. The scheduler performs pre-dispatch checks before worker execution.

CordClaw applies the same principle to OpenClaw tool execution. A TypeScript plugin intercepts action hooks, sends structured metadata to a local Go daemon, and the daemon evaluates policy through the Safety Kernel. Decision enforcement is outside the model runtime.

This is the operational point: model reasoning can be manipulated. The external enforcement boundary should not be.

Choosing deployment scope: local guardrail or full control plane

Teams often start with local OpenClaw security and later expand to organization-wide governance. Both paths are valid. The wrong move is forcing full centralization before proving that policy-before-execution improves safety outcomes in day-to-day workflows.

The practical strategy is staged adoption: prove pre-dispatch policy outcomes locally, then move to a shared control plane when approval volume, audit demand, or cross-team policy reuse becomes painful.

Runtime defaults that matter

Governance programs usually fail on defaults, not on principles. These implementation defaults drive real behavior during incident conditions.

Timing model: where prevention actually happens

The biggest confusion in agent safety is mixing up detection timing and prevention timing. Detection can be excellent and still be late. Pre-dispatch governance shifts control earlier in the lifecycle.

This is why security teams often describe pre-dispatch governance as moving from forensic control to operational control. You still investigate incidents, but fewer incidents begin with unrestricted execution.

A useful rule during design reviews: if a control cannot stop a risky action before it touches external state, classify it as detective, not preventive. Detective controls are still required. They are not a substitute for pre-dispatch policy enforcement when side effects are expensive or irreversible.

Fail-open vs fail-closed: choose your risk, do not inherit it

A production governance design must define behavior for policy dependency outages. If this is not explicit, the runtime will still choose for you, usually in the worst moment.

For most teams, production should be fail closed. If uptime pressure forces a temporary fail-open mode, treat it as an incident state with explicit alerts, narrowed scope, and an expiration window.

Evidence model: what to log so you can prove control

Governance without evidence is policy theater. Every pre-dispatch decision should produce a compact record tied to execution trace and policy snapshot.

{
  "job_id": "run_42:infra_apply@1",
  "decision": "REQUIRE_APPROVAL",
  "rule_id": "require-approval-prod-write",
  "policy_snapshot": "sha256:8d1f...",
  "approval_ref": "run_42:infra_apply@1",
  "actor_id": "svc-agent-prod",
  "trace_id": "trace_01HZZ...",
  "created_at": "2026-04-01T10:22:14Z"
}

This single record is enough to answer four audit questions fast: who initiated the action, what rule matched, which policy version decided, and where in the run timeline the decision happened.

Why post-hoc monitoring fails as the primary safety layer

Monitoring is still required. You need it for detection, triage, and learning. It is just the wrong primary layer for preventing high-impact actions.

The short version: post-hoc is forensic control. Pre-dispatch is preventive control. Use both, but do not pretend they solve the same timing window.

Pre-dispatch vs sandboxing vs in-context rules

Teams often ask whether one layer can replace the others. It cannot. Each layer handles a different class of failure.

Working implementation examples

1) Policy-as-code for deny, approval, and constrained allow

version: v1
default_decision: deny

rules:
  - id: deny-destructive-shell
    match:
      topics: ["job.openclaw.exec"]
      labels:
        command_class: destructive
    decision: deny
    reason: "Destructive shell commands are blocked by default"

  - id: require-approval-prod-write
    match:
      risk_tags: ["production", "write"]
    decision: require_approval
    reason: "Production write actions require explicit human approval"

  - id: constrain-package-install
    match:
      topics: ["job.openclaw.exec"]
      labels:
        command_class: package_install
    decision: allow_with_constraints
    constraints:
      budgets:
        max_runtime_ms: 15000
        max_retries: 1

2) OpenClaw interception path (plugin shape)

// OpenClaw plugin hook (shape)
export async function before_tool_execution(ctx: ToolExecutionContext) {
  const request = {
    job_id: ctx.actionId,
    topic: `job.openclaw.${ctx.toolName}`,
    capability: ctx.capability,
    risk_tags: ctx.riskTags,
    labels: ctx.labels,
  };

  const response = await fetch("http://127.0.0.1:19090/check", {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify(request),
  }).then((r) => r.json());

  if (response.decision === "DENY") {
    throw new Error(response.reason ?? "Blocked by policy");
  }

  if (response.decision === "REQUIRE_HUMAN") {
    return { blocked: true, approvalRef: response.approval_ref };
  }

  return { allowed: true, constraints: response.constraints };
}

3) Validate policy behavior without executing risky actions

# Validate governance path without executing risky actions
openclaw cordclaw status
openclaw cordclaw simulate --tool exec --command "echo hello"
openclaw cordclaw simulate --tool exec --command "rm -rf /"

4) Set fail modes explicitly by environment

# Gateway submit-time policy fallback (default: closed)
GATEWAY_POLICY_FAIL_MODE=closed

# Scheduler pre-dispatch policy fallback (default: closed)
POLICY_CHECK_FAIL_MODE=closed

Common rollout mistakes (and faster fixes)

Most governance rollouts fail for operational reasons, not because policy engines are unavailable. These are the issues that repeatedly stall teams in production adoption.

The practical shortcut is to enforce one high-risk action family end to end first. Teams that start with a broad all-action policy set usually drown in false positives and approval queue noise.

Operational metrics to track from day one

You cannot run governance by opinion. Measure it like any other production control path.

Limitations and tradeoffs

• Every policy check adds latency. Keep checks bounded and cached where safe.
• Approval-heavy designs create queue drag. Risk-tier aggressively to avoid reviewer fatigue.
• Fail-open modes preserve throughput but reduce safety guarantees during outages.
• Structured pre-dispatch policy is strong for action envelopes, weaker for hidden intent in freeform content. Pair it with output scanning.
• Good policies still need operational ownership. Without on-call runbooks, governance devolves into stale YAML files.

30-day rollout plan for production teams

Next step

Ship one irreversible action family behind pre-dispatch governance this week:

1. Choose a high-impact action (for example production infra mutation).
2. Set default decision to deny, then add explicit approval and constraint exceptions.
3. Run simulation commands and chaos-test safety unavailability behavior before broad rollout.

Continue with pre-dispatch vs post-hoc timing patterns and how to add governance to OpenClaw.