For change management, you want an agent workflow where the agent can draft and simulate, but cannot approve or close a change unless a permissioned execution policy allows it. Claw EA runs OpenClaw as the baseline agent runtime, then binds high-risk actions to a Work Policy Contract (WPC) and a CST so approvals are enforced by the execution layer, not by prompt instructions.
This matters because prompt-only controls fail under prompt injection and tool misuse. Policy-as-code gives you a signed, hash-addressed policy artifact that the runtime and proxy can verify before any irreversible change action is attempted.
Step-by-step runbook
-
Define the change boundaries and label irreversible actions. Treat “approve change” and “close change request” as high risk, and require a separate path from “draft”, “simulate”, or “comment”. Keep “read-only ticket context” and “write actions” as distinct tools or tool modes.
In OpenClaw, keep the agent’s tool policy tight so it can only call the minimum tools needed for drafting and evidence gathering. Use sandboxed tool execution where practical to limit local blast radius.
-
Publish a WPC that encodes who can do what, and when step-up is required. Store the WPC in the WPC registry, then configure your execution path to fetch and verify the WPC by its hash before running an approval or closure tool call.
Make “simulate-first” mandatory for any execution plan that would modify production configuration or ticket state. If simulation cannot be performed, fail closed and require an explicit exception in a new WPC revision.
-
Issue a CST for the job with scope hash and optional policy hash pinning. Use clawscope to mint a CST that is job-scoped and bound to the specific WPC hash for this run. This prevents a “valid token, wrong policy” scenario and supports marketplace anti-replay binding (job-scoped CST binding).
Keep CST TTL short for approvals and closures. If your identity layer is Microsoft Entra ID, you can gate the human approval step with Conditional Access and PIM, while still using the CST to gate machine execution.
-
Route all model calls through clawproxy and require receipts. For runs that can lead to a ticket transition or a production change, require gateway receipts for model calls emitted by clawproxy. Treat missing receipts as a verification failure for the run.
If you use OpenRouter via fal, route it through clawproxy so the receipt stream is consistent across models. This is how you later prove what the model saw and what it returned, within the limits of the receipt schema.
-
Enforce two-person rule and step-up approvals at the tool boundary. The agent can prepare a change plan, gather evidence, and draft the approval request, but the “approve” and “close” tools should require two distinct human approvers. Implement the approvals step via official API or via an MCP server, depending on your ticketing system and control plane.
Operationally, require one approver from the service owner group and one from the platform or security group. Record who approved, what was approved, and which WPC hash governed the action.
-
Run simulate-first, then execute under the same WPC. The agent runs a dry-run that produces artifacts: expected diffs, validation output, and rollback steps. Only after the approvals are collected does the execution step run, and only if the WPC permits the specific change type and target environment.
This prevents the common failure mode where “approval” is granted for a plan, but “execution” happens with a different plan. The execution layer checks that the approved plan fingerprint matches what is being applied.
-
Emit a proof bundle and store it for audit. Package the gateway receipts, policy hash, CST scope hash metadata, and run identifiers into a proof bundle. Store the resulting artifact in Trust Pulse so auditors can review what happened without rehydrating the whole runtime.
For ticket closure, require that the proof bundle exists and that the closure reason includes its identifier. That gives you a hard link between the ticket state and the execution evidence.
Threat model
| Threat | What happens | Control |
|---|---|---|
| Prompt injection in ticket comments | The agent is tricked into calling “approve” or “close”, or into expanding its tool usage beyond intent. | Tool boundary enforcement with WPC-gated actions, plus OpenClaw tool policy and sandboxing. Prompt text can influence planning, but cannot bypass the WPC and CST checks. |
| Single-user rubber stamping | A single operator approves and closes changes quickly, eliminating separation of duties. | Two-person rule in policy-as-code, enforced at execution time. Step-up approvals require two distinct identities before the irreversible tools unlock. |
| Replay of a prior approval token | An attacker reuses an approval artifact or token to approve a different change later. | Marketplace anti-replay binding (job-scoped CST binding) and short-lived CST issuance. The CST is tied to a job and optionally pinned to a WPC hash. |
| Drift between approved plan and executed action | The plan reviewed by humans differs from what was actually executed due to last-minute edits or model variability. | Forced simulate-first with plan fingerprinting, plus WPC rules that require the execution step to reference the same plan hash. Missing match fails closed. |
| Unverifiable model activity after incident | You cannot reconstruct which model calls influenced the approval request or change execution. | Gateway receipts for model calls via clawproxy, bundled into a proof bundle and retained as an audit artifact in Trust Pulse. |
Policy-as-code example
This is a compact, JSON-like sketch of what you encode in a WPC for change approvals. The goal is to make “approve” and “close” impossible unless the policy is verified and the approvals are present, even if the prompt tries to override it.
{
"wpc_version": "1",
"policy_name": "change_mgmt_prod_approval",
"policy_hash": "b64u:... (served by clawcontrols)",
"enforcement": {
"fail_closed": true,
"require_gateway_receipts": true,
"require_proof_bundle": true
},
"token_requirements": {
"require_cst": true,
"cst_scope_hash": "b64u:...",
"optional_policy_hash_pinning": true,
"job_scoped_binding": true
},
"tools": {
"ticket.read": { "allowed": true },
"ticket.comment": { "allowed": true },
"change.simulate": { "allowed": true, "required_before": ["change.execute", "ticket.approve", "ticket.close"] },
"ticket.approve": {
"allowed": true,
"step_up_approvals": 2,
"two_person_rule": true,
"approver_constraints": ["service_owner", "platform_security"]
},
"ticket.close": {
"allowed": true,
"step_up_approvals": 2,
"two_person_rule": true,
"requires_proof_bundle_reference": true
},
"change.execute": {
"allowed": true,
"requires_plan_fingerprint_match": true
}
}
}
In practice, you keep the approver identities and group membership checks in your enterprise identity system. If you are using Microsoft Entra ID, map approver roles to groups and use PIM and Conditional Access for step-up, then let the WPC decide whether the tool call can proceed.
What proof do you get?
Every model call routed through clawproxy produces gateway receipts, which are signed receipts emitted by clawproxy for model calls. Those receipts are what you point to when someone asks, “What did the model see and what did it output before the approval request was generated?”
At the end of the run, Claw EA produces a proof bundle, which is a harness artifact bundling receipts and related metadata for audit and verification. The proof bundle includes the WPC hash reference, CST-related binding metadata, and run identifiers so you can correlate the ticket, the plan, and the execution evidence.
For retention and review, store the proof bundle in Trust Pulse as a marketplace-stored artifact for audit/viewing. In change management terms, this becomes the attachment you can reference from the ticket and from post-incident reviews.
Rollback posture
| Action | Safe rollback | Evidence |
|---|---|---|
| Approval granted incorrectly | Revoke the CST, then require a new job-scoped CST and a new WPC-governed approval cycle. Treat the prior approval as invalid for future runs. | Proof bundle showing the original WPC hash, approver identities (as recorded by your approval system), and the gateway receipts for the decision support. |
| Execution diverged from the plan | Stop further runs by pinning to a revised WPC that disallows execute for the target system until corrected. Re-run simulate-first under the new policy and collect fresh approvals. | Mismatch evidence: plan fingerprint versus execution metadata within the proof bundle, plus gateway receipts for the model calls that produced the plan. |
| Ticket was closed without required artifacts | Reopen the ticket via official API and require proof bundle reference before closure. Tighten the WPC so closure fails unless the proof bundle identifier is supplied. | Absence is the signal: closure event without a corresponding proof bundle reference. The corrected run produces a new proof bundle and ties it to the ticket. |
| Suspected replay or token misuse | Invalidate the job context, rotate relevant secrets, and issue a fresh CST with job-scoped binding. Re-run with WPC hash pinning enabled. | Job-scoped CST binding metadata and timing correlation across receipts. The proof bundle provides a single package to hand to verification and audit teams. |
If you need network egress allowlists, implement them outside clawproxy as an optional control. Keep the rollback plan itself under change control so it is always available during an incident.
FAQ
Why is prompt-only approval not acceptable for enterprise change management?
Because the model can be convinced to ignore the instruction, especially when untrusted text enters the context. Policy-as-code moves the decision to a machine-enforced boundary where “approve” and “close” simply cannot run unless the WPC and CST conditions are satisfied.
How do two-person rule and step-up approvals work with Claw EA?
The WPC encodes that “approve” and “close” require two distinct approvals, then the execution layer checks that the approvals exist before calling the tool. The approvals themselves can be collected via official API or via an MCP server, depending on your ticketing system.
Can OpenClaw still be used if we already have a ticketing workflow?
Yes. OpenClaw runs the agent and tools, while Claw EA supplies the permissioned execution layer and proof artifacts, so you can keep your existing ticket states and approval roles.
What do gateway receipts and proof bundles help us do during an audit?
They let you verify that the agent run followed the policy you intended, and they provide a signed record of model calls. Instead of reconstructing events from logs and screenshots, you can hand an auditor the proof bundle and the associated WPC hash.
Do you enforce network egress allowlists and cost budgets?
Egress allowlists enforced outside clawproxy and automatic cost budget enforcement are optional or planned items, depending on your deployment. If you need them today, they can be implemented as an enterprise buildout alongside the shipped WPC, CST, receipts, and proof bundle controls.