Proof bundles let you verify what an agent run actually did by packaging gateway receipts, policy references, and run metadata into one artifact you can re-check later. In Claw EA, the proof bundle is built around Work Policy Contracts (WPC), CST (scoped token), and gateway receipts, so verification can fail closed when any binding is missing or mismatched.
OpenClaw is the baseline agent runtime, but prompt-only guardrails are not sufficient because prompts can be overridden at runtime by user input, tool output, or injection. For enterprise runs, the execution layer must be permissioned with policy-as-code so the harness enforces what tools and model routes are allowed, regardless of what the model “decides.”
Step-by-step runbook
-
Write a WPC for the job. Define allowed model routing (for example OpenRouter via fal routed through clawproxy), tool allow/deny, and any run bindings you care about (job id, environment, dataset identifiers). Store and serve the signed, hash-addressed WPC from clawcontrols.
-
Issue a CST scoped to that WPC. Use clawscope to issue a CST (scoped token) that includes a scope hash and, optionally, policy hash pinning to the WPC hash. This makes the token useless outside the intended permission envelope.
-
Run the agent through clawproxy. Configure the OpenClaw provider to route model calls through clawproxy so each call emits gateway receipts. If a model call is made outside the proxy, you should treat the run as “unproven” for model-IO coverage.
-
Collect the proof bundle. At the end of the run, gather the proof bundle (the harness artifact bundling receipts and related metadata for audit/verification). Store it in your retention system and optionally publish the artifact to Trust Pulse for viewing.
-
Verify the bundle before acting on results. Submit the proof bundle to your verifier workflow (for example, clawverify via official API) and fail closed on signature failures, missing bindings, or token replay indicators. Record the verification result alongside the business output (PR merge, ticket update, deployment artifact).
-
Set retention and access rules. Keep the full bundle for high-risk runs, and keep a reduced bundle (hashes plus minimal metadata) for routine runs. Separate “audit material” from “secret material” so you can retain proofs without retaining plaintext secrets.
Threat model
Proof bundles do not prevent unsafe behavior by themselves. They help you detect when a run stepped outside approved routes, when receipts were tampered with, or when a token was replayed.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection pushes the agent to use broader tools | The model tries to call tools that were not intended for the job (filesystem, shell, browser control, or external HTTP). | Policy-as-code in a WPC plus OpenClaw tool policy and sandboxing limit what is callable and where it executes. Verification checks that the WPC hash referenced by the run matches what you approved. |
| Model traffic bypasses the proxy | The run “works,” but you have no gateway receipts for some model calls, so you cannot prove what was sent or received. | Route model providers via clawproxy so gateway receipts are emitted for each call. Treat missing receipts as an incomplete proof bundle and gate downstream actions on verification. |
| Receipt or bundle tampering after the run | An operator edits logs or swaps model outputs to make the run appear compliant. | Gateway receipts are signed by clawproxy; the proof bundle includes hashes that bind payloads, timestamps, and policy references. Verification fails if signatures or hashes do not match. |
| CST replay across jobs | A valid token is reused to run a different job under the same identity, causing unauthorized work that still “looks authenticated.” | Marketplace anti-replay binding (job-scoped CST binding) reduces replay risk. Additionally, scope hash and optional policy hash pinning constrain where the token is accepted. |
| Local execution escape | A tool runs on the host unexpectedly (for example via an “elevated” escape hatch) and accesses local credentials or files. | Use OpenClaw sandboxing and avoid elevated execution unless explicitly required. Pair local hardening (audit) with WPC restrictions so the intended execution mode is reviewable and enforceable. |
Policy-as-code example
A WPC should be specific enough that reviewers can reason about it and verifiers can bind runs to it. The key is that policy lives outside the prompt and is enforced by the harness, not “suggested” to the model.
Example shape (JSON-like) that teams commonly version-control before registering it as a WPC in clawcontrols:
{
"wpc_version": "v1",
"policy_name": "support-triage-agent",
"intent": "Classify tickets and draft replies. No external posting.",
"model_routing": {
"must_use_proxy": true,
"allowed": [
{ "provider": "openrouter_via_fal", "via": "clawproxy" }
]
},
"tools": {
"allow": ["read", "search_repo", "create_draft"],
"deny": ["exec", "write", "browser_control", "webhook_post"]
},
"data_handling": {
"log_payloads": "hash_only",
"retain_days": 30
},
"bindings": {
"job_scope_required": true
}
}
Then issue a CST (from clawscope) that is scoped to the run and optionally pins the WPC hash. This is what turns “policy text” into a permission boundary that survives prompt injection and operator error.
What proof do you get?
A proof bundle is the container you hand to audit, security, or a verifier service. It typically includes: the WPC hash reference (and often the fetched WPC itself), the CST scope hash context, and gateway receipts for each model call routed via clawproxy.
What is signed: gateway receipts are signed by clawproxy, and the WPC is a signed artifact served by clawcontrols. What is hashed: the bundle includes hashes that bind the run metadata and receipt set, so post-run edits can be detected. What is replayable: raw receipts can be copied, so you mitigate replay by binding CST to a job scope and by verifying bundle bindings against the job you expected.
Example (abridged) bundle shape you can expect to retain and re-verify:
{
"bundle_version": "v1",
"run": {
"run_id": "run_2026_02_11_001",
"agent_runtime": "OpenClaw",
"started_at": "2026-02-11T10:12:05Z"
},
"policy": {
"wpc_hash": "b64u:...",
"wpc_source": "clawcontrols"
},
"auth": {
"cst_scope_hash": "b64u:...",
"job_binding": "job_7f3c..."
},
"receipts": [
{
"type": "gateway_receipt",
"issuer": "clawproxy",
"model": "openrouter/...",
"request_hash": "b64u:...",
"response_hash": "b64u:...",
"signature": "b64u:..."
}
]
}
Verification workflow: check WPC signature and hash-addressing, check CST scope hash and (if present) policy hash pinning, verify each gateway receipt signature, and confirm the job-scoped binding matches the job context you are approving. If you publish to Trust Pulse, you get a consistent place to store and view the artifact, but you should still keep your own retention copy if policy requires it.
Common pitfalls: allowing multiple model routes “temporarily,” not failing closed on missing receipts, and storing plaintext prompts in the same place as proof artifacts. Keep proofs verifiable, but keep secrets compartmentalized.
Rollback posture
Rollback is about stopping further damage and preserving evidence. Proof bundles help because you can quickly answer “what was called, under what policy, using which token scope,” then revoke or tighten accordingly.
| Action | Safe rollback | Evidence to capture |
|---|---|---|
| Suspect CST misuse | Revoke the CST in clawscope, then re-issue a new CST with tighter scope hash and shorter TTL for the replacement run. | Proof bundle plus the CST scope hash and job binding referenced by the run. |
| Policy too permissive | Register a new WPC (new hash) with reduced tools or restricted model routing, and require policy hash pinning in the next CST issuance. | Old and new WPC hashes, plus verifier results showing which runs used which policy. |
| Missing receipts for some model calls | Stop accepting the run output for high-impact actions until routing is corrected to clawproxy. Re-run with proxy-only model routing. | Bundle showing receipt gaps, and OpenClaw configuration evidence showing provider routing for the rerun. |
| Local tool execution incident | Tighten OpenClaw sandbox mode and tool allowlists, and remove elevated execution paths unless explicitly required. | OpenClaw audit results plus the proof bundle metadata showing execution mode expectations. |
FAQ
How is a proof bundle different from “logs”?
Logs are easy to edit and hard to verify. A proof bundle is structured for verification: it binds gateway receipts, policy references (WPC hash), and run metadata so tampering is detectable.
Do proof bundles prove what tools did on the host?
They prove what is included in the bundle, especially model calls via gateway receipts and the policy bindings around the run. Host-side tool execution is primarily controlled by OpenClaw tool policy and sandboxing, so you should treat the bundle as part of a broader execution posture.
What should we retain, and for how long?
Retain full bundles for high-risk runs (production changes, external comms, security-sensitive actions). For routine runs, many teams retain hashes plus minimal metadata and keep plaintext prompts or outputs in a separate encrypted system with stricter access.
Can we verify bundles automatically in CI or a gatekeeper?
Yes, if your workflow can submit the bundle to a verifier (for example, clawverify via official API) and fail closed. Gate on “verified receipts present,” “WPC hash matches,” and “job-scoped CST binding matches the job being approved.”
What makes policy-as-code necessary if we already have good prompts?
Prompts are instructions, not enforcement, and they are vulnerable to injection and tool output manipulation. Policy-as-code in a WPC is enforced by the harness and is cryptographically referenceable, so reviewers can approve a specific policy hash and verifiers can check it later.