Receipt binding is how you prove that a specific agent run happened under a specific policy artifact, and that its model calls were not replayed, swapped, or mixed from another run. In Claw EA, the binding links a WPC, a job-scoped CST, and gateway receipts into a proof bundle that can be verified later, fail-closed.
This matters because OpenClaw is the baseline agent runtime, and prompt-only controls do not constrain tools, network paths, or model providers in a way you can audit. Permissioned execution approvals require policy-as-code plus cryptographic linkage, not “the model promised to behave.”
Step-by-step runbook
Use this runbook when you need approvals for a run and an audit trail you can replay in verification tooling. The goal is to make every model call and decision traceable to the WPC and the job identity.
-
Define and publish the policy artifact as a WPC. Treat the WPC as the machine-readable approval boundary: tool profile, allowed providers, and any required human gates live here.
Store the signed, hash-addressed WPC in the WPC registry (served by clawcontrols), and record the policy hash in your change ticket.
-
Issue a job-scoped CST for the run. The CST is issued by clawscope and should include a scope hash that reflects the job identity and the intended permissions.
Optionally pin the WPC hash in the CST so a token minted for Policy A cannot be used to execute under Policy B.
-
Start the OpenClaw agent run with the policy selected and the CST attached to the execution context. Keep the agent’s tool configuration aligned with the WPC so local allow/deny lists and sandboxing match the contract.
Run OpenClaw’s security audit regularly to reduce operator footguns before you rely on receipts for approvals.
-
Route model traffic through clawproxy. Each model call produces gateway receipts that are signed and include the metadata needed to bind the call to the job identity.
If you use OpenRouter via fal, keep the provider route consistent so receipts describe the actual provider path used.
-
Collect the proof bundle at the end of the run. The proof bundle is the harness artifact that packages gateway receipts plus run metadata (run id, agent id, policy hash, scope hash, timestamps, and relevant config fingerprints).
Store the proof bundle for audit, and optionally publish the result into a Trust Pulse artifact for viewing.
-
Verify before approval. Verification should check WPC authenticity, CST binding, and receipt signatures and linkage; if any check fails, the run should not be marked approved or used to justify downstream actions.
Keep verification outputs attached to your ticket so approvals are tied to evidence, not screenshots.
Threat model
Receipt binding is designed for operational failure modes: replayed receipts, policy swapping, and cross-run mixing. The controls below assume an attacker can influence prompts and can attempt to reuse artifacts from other runs.
| Threat | What happens | Control (what to verify) |
|---|---|---|
| Receipt replay from a prior job | An attacker tries to attach old gateway receipts to a new approval request. | Marketplace anti-replay binding using job-scoped CST binding; verify job id and CST binding claims match the proof bundle run metadata. |
| Policy substitution | A run is executed under a looser policy, but presented as if it ran under a stricter one. | Verify WPC signature and policy hash, then check optional policy hash pinning in the CST and match it to the proof bundle policy hash. |
| Cross-run receipt mixing | Receipts from multiple runs are merged to fabricate an execution story. | Verify all gateway receipts share the same run id, job id, and scope hash, and that receipt timestamps and sequence metadata are consistent. |
| Out-of-band model calls | The agent calls a model directly, bypassing clawproxy, so no receipts exist. | Fail approvals if required receipt coverage is incomplete; enforce “receipts required” in the WPC and verify the provider path is routed through clawproxy. |
| Tool escalation through local misconfig | OpenClaw tools run with broader access than the policy intended (for example elevated exec on host). | Bind proof metadata to the effective tool policy and sandbox mode; verify OpenClaw configuration fingerprints match the WPC expectations and reject mismatches. |
Policy-as-code example
This is a minimal, schema-style example showing what you want bound together. The exact field names vary by enterprise buildout, but the semantics should be stable: hash-addressed policy, scoped token identity, and receipts that reference both.
{
"wpc": {
"policy_hash_b64u": "WPC_HASH",
"issuer": "clawcontrols",
"version": "v1",
"intent": "permissioned execution approvals"
},
"approval_requirements": {
"receipts_required": true,
"min_receipt_count": 1,
"deny_if_policy_mismatch": true
},
"execution_binding": {
"job_id": "job_2026_02_11_001",
"run_id": "run_7f1c...",
"agent_id": "agent_finops_bot",
"scope_hash": "SCOPE_HASH",
"cst_policy_hash_pinning": "WPC_HASH"
},
"model_routing": {
"must_use_clawproxy": true,
"allowed_model_routes": [
{ "provider": "openrouter_via_fal", "models": ["allowed-prefix/*"] }
]
}
}
Validation should be fail-closed. If a proof bundle claims policy hash X but the CST is pinned to policy hash Y, the run is not “partially valid”; it is not eligible for approval.
Similarly, if receipts exist but do not cover the required portion of model calls (for example missing the calls that generated the final decision), treat it as an incomplete record. If you need completeness guarantees, make “receipts required” part of the WPC and enforce it consistently.
What proof do you get?
You get three layers of evidence that are meant to be checked together. Each layer limits a different kind of tampering, and the full chain is what supports permissioned execution approvals.
First, the WPC is the signed policy artifact: a Work Policy Contract (WPC) served by clawcontrols and addressed by its hash. This is the “what was allowed” statement, and the hash is what you pin and reference everywhere else.
Second, the CST is the per-job authorization artifact: a scoped token (CST) issued by clawscope. Its scope hash describes the authorized context, and optional policy hash pinning prevents token reuse under a different WPC.
Third, gateway receipts are the per-call evidence emitted by clawproxy for model calls. A proof bundle packages these receipts with run metadata so you can verify that the model traffic for this run was mediated and that the receipts belong to this job.
Operationally, you should treat the proof bundle as the approval packet. If you publish a Trust Pulse artifact, it becomes the convenient viewing surface, but your audit decision should still be anchored on verifying the proof bundle contents and signatures.
Rollback posture
Receipt binding supports safe rollback because you can quickly distinguish “policy changed,” “token scope changed,” and “provider path changed.” The table below is a practical set of rollback actions and what evidence to check before resuming execution.
| Action | Safe rollback | Evidence to check |
|---|---|---|
| Revert to prior policy | Re-select the prior WPC by its policy hash and re-issue a new CST for the new job. | WPC hash matches the approved version; CST policy hash pinning matches; new proof bundle references the reverted WPC. |
| Invalidate a compromised token | Revoke the CST and mint a new job-scoped CST; do not reuse proof bundles from the compromised job. | CST identity changes; receipts for the new run bind to the new job id; anti-replay binding rejects reuse of old receipts. |
| Switch model route | Update the WPC to allow the new route and require clawproxy mediation, then re-run with a new CST. | Proof bundle shows the new provider path in receipts; no gaps in receipt coverage for the decision-critical calls. |
| Quarantine a suspect run | Stop approvals for that run id, keep artifacts immutable, and re-run under the same WPC with a new job id. | Verification output flags the mismatch (policy hash, scope hash, or receipt signatures); quarantined proof bundle is preserved for audit. |
FAQ
Why is policy-as-code required instead of prompt-only instructions?
Prompt-only controls do not bind tools, model routes, or token scope to an enforceable contract, and they are easy to bypass via injection or operator error. A WPC provides a hash-addressed, signed artifact that can be pinned in a CST and checked against gateway receipts.
What exactly is “receipt binding” in Claw EA terms?
It is the linkage between a WPC (policy hash), a job-scoped CST (scope hash and optional policy hash pinning), and gateway receipts (signed call records). The proof bundle packages these so a verifier can reject replays, policy swaps, and cross-run mixing.
Can I approve a run if some model calls have receipts and others do not?
You can, but you should treat it as a different approval class because the unreceipted calls are not verifiable. If your process requires permissioned execution approvals, make receipt coverage a WPC requirement and fail approvals when coverage is incomplete.
How does this relate to OpenClaw’s local sandbox and tool policy?
OpenClaw controls local execution through sandboxing, tool policy, and elevated mode, which reduces blast radius at runtime. Receipt binding complements that by proving which policy and route were used, and by producing artifacts you can verify after the run.
Is this similar to cloud compliance attestations?
Conceptually, yes: you are producing an attestation-like record that a system operated under declared policy. The difference is that receipt binding is centered on model call mediation and job-scoped authorization, rather than only marking a resource as compliant.