A proof bundle is the artifact you keep when you need to prove what an agent did, under which policy, and which model calls happened. In Claw EA, proof bundles package gateway receipts (from clawproxy) plus run metadata so a verifier can fail-closed if anything is missing or tampered with.
OpenClaw is the baseline agent runtime, but prompts are not a permission system. If you want repeatable controls, you need permissioned execution using policy-as-code, with a WPC and a CST that binds the run to explicit, machine-enforced constraints.
Step-by-step runbook
-
Define the policy you want enforced as a WPC = Work Policy Contract (signed, hash-addressed policy artifact; served by clawcontrols). Treat the WPC hash as the stable identifier for what was allowed.
Keep the WPC small and explicit: allowed providers, tool boundaries, redaction expectations, and required proof outputs.
-
Issue a CST = scoped token (issued by clawscope) for the job. Use CST scope hash and optional policy hash pinning so the token is only valid for the intended scope, and optionally only for that WPC hash.
This is what turns “the agent should” into “the agent can only”. Prompts can be edited; token scope cannot.
-
Run the agent in OpenClaw with model traffic routed through clawproxy. The proxy emits gateway receipts for model calls, which become the cryptographic evidence for what was requested and returned at the model boundary.
If you need tool isolation, rely on OpenClaw sandbox and tool policy controls locally. The proof bundle is compatible with sandboxed execution, but sandboxing and policy are distinct concerns.
-
Collect receipts and run metadata into a proof bundle. The bundle should include the WPC reference (hash) and enough binding data to show the receipts came from the run that used the CST.
Do not “summarize” receipts into logs. Keep the raw receipt envelopes so verification can be deterministic.
-
Verify the proof bundle using a fail-closed verifier flow. Verification should check signatures, binding between run and receipts, and consistency with the pinned WPC hash when present.
If any required component is missing (for example, receipts for model calls), treat the bundle as unverifiable and downgrade or reject the run for audit purposes.
-
Optionally store the proof bundle as a Trust Pulse for later viewing and audit. Trust Pulse is the marketplace-stored artifact for audit/viewing.
For high-sensitivity environments, keep an offline copy of the proof bundle and verify it without relying on network availability.
Threat model
Proof bundles are designed for post-run verification: what happened, under what constraints, and whether the model boundary is intact. They do not prevent every failure mode in real time, but they make policy bypasses and missing evidence detectable.
The core operational goal is simple: if someone alters the story after the fact, verification fails.
| Threat | What happens | Control |
|---|---|---|
| Prompt-only “policy” gets ignored | The agent is instructed to behave, but it can still call tools or models outside intended boundaries when coerced. | Permissioned execution: WPC reference plus CST scope hash and optional policy hash pinning. Prompts guide behavior; CST constrains capability. |
| Receipts are removed or replaced | A run looks clean because the riskiest model calls are omitted from logs. | Gateway receipts are signed by clawproxy, then included in the proof bundle. Verification fails if required receipts are absent or signatures do not validate. |
| Replay of a previously authorized token | An attacker reuses a valid CST to run a different job and tries to pass it off as the original. | Marketplace anti-replay binding (job-scoped CST binding) makes tokens job-bound so they cannot be reused across runs without detection. |
| Policy drift between approval and execution | Teams approve “Policy A”, but the agent runs under “Policy B” due to config changes or operator error. | Pin the WPC hash and include the WPC hash reference inside the proof bundle. Verification checks the pinned hash matches the bundle’s declared policy. |
| Local tool blast radius in the runtime | Even with good model receipts, a misconfigured runtime could allow unsafe filesystem or process access. | Use OpenClaw sandbox and tool policy, and regularly run the OpenClaw security audit to catch common footguns. Proof bundles help detect model boundary behavior, not fix local OS hardening. |
Policy-as-code example
This example shows the minimum idea: a WPC hash that identifies the policy artifact, plus CST constraints that pin the policy and bind the run. Treat it like a contract between approvers, operators, and auditors.
Keep the fields explicit, and make verification requirements part of the policy so missing evidence becomes a hard failure.
{
"job": {
"id": "job_2026_02_11_001",
"runtime": "openclaw",
"purpose": "Generate weekly ops report from internal tickets"
},
"policy": {
"wpc_hash_b64u": "WPC_HASH_BASE64URL",
"require_gateway_receipts": true,
"require_proof_bundle": true
},
"auth": {
"cst_required": true,
"cst_scope_hash": "SCOPE_HASH",
"pin_wpc_hash": "WPC_HASH_BASE64URL",
"job_scoped_binding": true
},
"model_boundary": {
"proxy": "clawproxy",
"receipts": "gateway_receipts"
},
"verification": {
"fail_closed": true,
"min_acceptable_result": "verified_receipts_and_bindings"
}
}
Why this is not prompt-only: prompts can request “do not access X”, but the agent can still be induced to do it. A WPC plus CST turns approvals into enforceable constraints, and the proof bundle makes the run auditable.
What proof do you get?
A proof bundle is the unit you hand to an auditor or to your own incident response workflow. It is a harness artifact bundling receipts and related metadata for audit/verification.
In practice, you get four concrete things: a policy reference, an authorization binding, signed model-call receipts, and a verification outcome that can be repeated later.
-
WPC reference: the WPC hash that identifies the exact policy artifact that should have governed the run. This is how you avoid “we meant the other config file” debates.
-
CST binding: evidence that a CST was used, with CST scope hash and optional policy hash pinning. This is how you show capability was constrained, not merely requested.
-
Gateway receipts: signed receipts emitted by clawproxy for model calls. These are the cryptographic receipts for the model boundary, usable for verification after the run.
-
Proof bundle envelope: a single package that ties the above together with run identifiers and metadata so the bundle can be verified as a whole. If you store it in Trust Pulse, you also get a consistent artifact location for review.
Verification rules should be strict. If signatures do not validate, if receipt-to-run binding fails, or if the pinned WPC hash does not match, the correct outcome is “unverified” rather than “best effort”.
Rollback posture
Proof bundles do not automatically undo side effects, but they make rollback and containment operationally faster. They answer: what changed, which tools were invoked, and which model calls preceded each action, so you can triage with evidence.
Rollback should be planned as a playbook paired with the WPC. The WPC defines what actions are allowed; the rollback playbook defines what actions are taken when verification fails or output is incorrect.
| Action | Safe rollback | Evidence |
|---|---|---|
| Stop further runs under the same policy | Revoke or expire CSTs for the job scope, and rotate to a new job scope hash for the next attempt. | Proof bundle shows CST binding and scope hash; clawscope history supports why the run was blocked going forward. |
| Invalidate outputs generated under disputed constraints | Mark artifacts as non-authoritative if the proof bundle fails verification, or if required receipts are missing. | Verification report from the proof bundle, plus missing or invalid gateway receipts. |
| Re-run with tightened permissions | Issue a new CST with narrower scope and optionally pin to an updated WPC hash. Use OpenClaw tool policy and sandbox settings to reduce local blast radius. | New proof bundle references the new WPC hash; differences are mechanically comparable by policy hash. |
| Post-incident audit package | Export the proof bundle and store it as a Trust Pulse for shared review, while keeping an offline copy for incident response. | Trust Pulse artifact plus the underlying proof bundle and gateway receipts for independent verification. |
FAQ
What is the difference between gateway receipts and a proof bundle?
Gateway receipts are signed receipts emitted by clawproxy for model calls. A proof bundle collects those receipts plus run metadata and bindings so verification can be done on the whole run, not on individual calls.
Why is policy-as-code required instead of putting rules in the prompt?
A prompt is advisory: it can be changed, ignored, or overridden by injection. A WPC plus a CST is enforceable: the CST scope hash and optional policy hash pinning constrain what the runtime is allowed to do, and the proof bundle provides evidence that those constraints were in effect.
Can I verify a proof bundle offline?
Yes, that is the intent. Store the proof bundle and verify signatures and bindings without needing to rely on live access to the runtime environment.
Does a proof bundle prove tool actions on the host?
It proves the model boundary via gateway receipts, and it binds the run to a declared policy and token scope. Host and tool execution safety still relies on OpenClaw sandbox and tool policy controls, plus your OS and deployment hardening.
What happens if a receipt is missing?
Verification should fail-closed if the WPC requires receipts and the bundle cannot prove the model calls. Operationally, treat the run as unauditable and do not promote its outputs to authoritative status.