To verify a Proof bundle, you check that every cryptographic envelope validates and that the bundle’s bindings are consistent: the Work Policy Contract (WPC), the CST = scoped token, and the Gateway receipts all point at the same job identity and the same policy hash. Then you fail closed if anything is missing, unsigned, unverifiable, or not bound to the expected scope.
OpenClaw is the baseline agent runtime, but prompt text alone is not a permission boundary. You need a permissioned execution layer enforced by policy-as-code so the runtime can prove what was allowed, what was called, and what cannot be replayed outside the original job.
Step-by-step runbook
-
Collect the Proof bundle and the verification inputs you expect to be true. At minimum: expected WPC policy hash (or an allowlist of acceptable hashes), the expected job identifier (if your pipeline assigns one), and the public keys or key-discovery references used to validate signatures.
If your workflow stores artifacts in Trust Pulse, pull the exact artifact you intend to verify and record its storage identifier for traceability.
-
Verify the WPC first, before looking at model traffic. The WPC = Work Policy Contract is a signed, hash-addressed policy artifact served by clawcontrols, so verification is: signature valid, hash matches the address, and the policy content matches what you intended to authorize.
Fail closed if the bundle references a WPC you cannot fetch and verify, or if it references multiple policies when you expect exactly one.
-
Verify the CST claims and bindings. A CST = scoped token is issued by clawscope; you should validate its signature, validate its scope hash, and confirm optional policy hash pinning when your job requires a specific WPC.
Then confirm the job-scoped binding is present when applicable, so a CST captured from one job cannot be replayed in another context.
-
Verify Gateway receipts for each model call. Gateway receipts are signed receipts emitted by clawproxy for model calls, so verification is: signature valid, receipt fields parse correctly, and each receipt binds to the same job identity and expected scope/policy references.
Fail closed if any model call in the run lacks a receipt when your policy requires full receipting coverage.
-
Check bundle integrity and cross-linking. A Proof bundle should be internally consistent: referenced receipt hashes exist, metadata hashes match their referenced payloads, and timestamps and nonces do not indicate copying or splicing from another run.
Do not accept “mostly valid” bundles for audit or incident response. Partial validity is a common way to launder unreceipted calls or inject an out-of-policy receipt set.
-
Confirm runtime posture constraints were actually enforceable. Prompt instructions like “do not exfiltrate secrets” do not prevent tool calls, network egress, or host execution; policy-as-code does because it can be checked and enforced by the runtime and proxy layer.
If the agent ran with elevated host execution or broad tool access, treat the proof as limited to what receipts can cover, not as a blanket safety guarantee.
Threat model
Proof verification is about resisting realistic failures: replay, splicing, partial logging, and “policy drift” between what was approved and what was executed. The table below lists common failure modes and what a fail-closed verifier should do.
| Threat | What happens | Control (what to verify) |
|---|---|---|
| Receipt replay across jobs | An attacker copies valid Gateway receipts from a prior run to make a new run look compliant. | Enforce marketplace anti-replay binding (job-scoped CST binding) and require receipts to bind to the same job identity and CST scope hash. |
| Policy drift (prompt-only “policy”) | The prompt claims restrictions, but the runtime or tools were not actually constrained. | Require a verified WPC and validate optional policy hash pinning in the CST when your workflow requires a specific policy. |
| Bundle splicing | A bundle mixes receipts and metadata from multiple runs to hide an out-of-policy call. | Verify internal hash linking across the Proof bundle and require a single, consistent job identity and policy reference set. |
| Partial coverage | Some model calls are receipted, but others bypass clawproxy and are missing receipts. | Fail closed on missing Gateway receipts when policy demands full coverage, and treat the verified subset as a partial attestation only. |
| Key substitution | A verifier accepts attacker-controlled signing keys. | Pin trusted key sources and rotate keys via controlled processes. Reject unknown issuers and unexpected key IDs. |
Policy-as-code example
This example shows the shape of an enforceable policy artifact and how you bind execution to it. The important point is not the exact schema, but that the WPC is signed and hash-addressed, and the CST can pin to that policy hash so the job cannot silently switch rules.
{
"wpc_ref": {
"policy_hash_b64u": "u6J...your_expected_policy_hash..."
},
"execution": {
"runtime": "openclaw",
"require_gateway_receipts": true,
"models": [
{ "provider": "openrouter_via_fal", "allow": true }
]
},
"auth": {
"cst": {
"require_scope_hash": true,
"pin_policy_hash": "u6J...your_expected_policy_hash..."
}
},
"audit": {
"require_proof_bundle": true,
"store_to_trust_pulse": true
}
}
Why this matters operationally: if you only instruct the agent in the prompt, you cannot later prove the instruction was enforced. With a WPC plus CST pinning, you can reject runs that do not match the approved policy hash.
What proof do you get?
A Proof bundle is the harness artifact bundling receipts and related metadata for audit/verification. In practice, you should expect: a reference to the WPC (by hash), a record of the CST scope or its hash, and a set of Gateway receipts for model calls emitted by clawproxy.
What is signed: the WPC is signed; the CST is signed (issued by clawscope); Gateway receipts are signed by clawproxy. What is hashed: the WPC is hash-addressed; the bundle should include hashes linking receipts and metadata so tampering is detectable.
What is replayable if you do it wrong: receipts and tokens can be copied if they are not bound to a job identity and policy hash. That is why you verify job-scoped CST binding and (when required) policy hash pinning, then reject bundles that cannot prove those bindings.
A minimal “shape” to look for during review is below. Treat it as an inspection checklist, not a wire contract.
{
"bundle": {
"job_id": "job_2026_02_11_001",
"wpc_policy_hash_b64u": "u6J...policy...",
"cst_scope_hash": "sH...scope...",
"receipts": [
{
"receipt_id": "rcpt_01",
"provider": "openrouter_via_fal",
"request_hash": "h_req_...",
"response_hash": "h_resp_...",
"signature": "sig_..."
}
]
}
}
Rollback posture
Verification should drive rollback actions that are easy to execute and easy to evidence. If you cannot prove a run is within policy, treat it as untrusted and roll forward by re-running under a stricter WPC, rather than trying to “patch” an unverifiable bundle.
| Action | Safe rollback | Evidence you should retain |
|---|---|---|
| Bundle fails WPC verification | Block acceptance, fetch WPC again from clawcontrols, and require a re-run with the correct WPC hash. | Failed verification report, expected policy hash, and the retrieved WPC used for comparison. |
| Bundle fails CST binding checks | Revoke the CST via official API (clawscope) and issue a new CST with the correct scope hash and optional policy hash pinning. | Revocation record, new CST issuance record, and the verifier output showing the mismatch. |
| Missing Gateway receipts | Treat as partial attestation; re-run with all model traffic routed through clawproxy so every call produces receipts. | List of missing receipt slots, run configuration showing proxy routing, and the new bundle with full coverage. |
| Suspected replay or splicing | Invalidate the run, require a fresh job identity, and enforce job-scoped CST binding for the next execution. | Comparison notes across job IDs, receipt IDs, and timestamps that indicate reuse. |
FAQ
Can I verify a Proof bundle offline?
Yes, if you already have the needed public keys or key-discovery material cached and you have the WPC content that the bundle references. The workflow is similar to offline verification patterns used for software attestations: download the bundle while online, then verify signatures and hashes offline.
Why is prompt-only policy not enough?
Because prompts do not constrain tools, network calls, or host execution, and they cannot produce enforceable, testable proofs. Policy-as-code works because the WPC can be verified, the CST can pin to the WPC hash, and Gateway receipts can prove what model calls actually happened.
What does “fail closed” mean in practice?
If any required signature, hash link, policy reference, or binding is missing or invalid, you do not accept the bundle as verified. You either treat it as a partial artifact (explicitly labeled) or require a re-run under a verified WPC with receipted traffic.
Do Gateway receipts prove what tools did on the machine?
No, Gateway receipts cover model calls routed through clawproxy. For tool execution risks, rely on the OpenClaw controls (sandbox, tool policy, elevated mode) and treat the Proof bundle as proof of model-call behavior and policy bindings, not as a complete host activity log.
Where should we store verified bundles?
Store the original Proof bundle plus the verifier output in an append-only location your audit team controls. If you use Trust Pulse, store the artifact there for consistent viewing and later review, and keep your internal case metadata alongside it.