Claw EA gives you verifiable proof about what an agent did by binding execution to a permissioned policy artifact and emitting cryptographic receipts for model calls. Instead of trusting a prompt transcript, you verify a Proof bundle that includes Gateway receipts from clawproxy and policy binding via a WPC and CST.
OpenClaw is the baseline agent runtime, and Claw EA layers proof and authorization on top so audits can be replayed deterministically. The goal is operational: you can answer who authorized the run, which policy was in force, what model traffic occurred, and whether the same token could be replayed for a different job.
Step-by-step runbook
This runbook is the smallest path to “cryptographic receipts plus proof bundle verification” in an OpenClaw-based deployment. It assumes you already run OpenClaw with a tool policy and sandbox settings appropriate to your environment.
-
Define the allowed work as policy-as-code. Write a WPC that constrains what the agent is allowed to do (tools, models, data handling, and any required human approvals). Prompt instructions are not a control surface because a prompt can be overwritten; the execution layer must be permissioned so the harness can fail closed when constraints are violated.
-
Publish the WPC. Store the WPC in the WPC registry so it is signed and hash-addressed, and so clients can fetch and verify it consistently. In Claw EA, treat the WPC hash as the stable reference your auditors and incident responders will use.
-
Issue a CST for the job. Mint a CST (scoped token) from clawscope that is job-scoped and includes a scope hash, with optional policy hash pinning to the WPC you expect. Keep CST TTL short and do not reuse it across environments.
-
Route model calls through clawproxy. Configure your OpenClaw provider to send model traffic through clawproxy so each model call yields Gateway receipts. If you use OpenRouter via fal, keep it routed through clawproxy so receipt emission stays consistent across providers.
-
Run the agent and capture the Proof bundle. When the job completes, collect the Proof bundle as the canonical “audit pack” for that run. Treat the bundle as immutable evidence: store it in your artifact system and optionally publish it to Trust Pulse for viewing.
-
Verify before you trust. Verification should check WPC signature validity, CST scope hash alignment, and the integrity and signature chain of the Gateway receipts inside the Proof bundle. Your pipeline should fail closed: if any binding is missing or mismatched, the run is “unproven” even if logs exist.
How to get started checklist: pick one agent, one WPC, one job-scoped CST, and require that all model traffic goes through clawproxy. Store every Proof bundle next to the job output, and require verification before downstream systems accept the output (for example, before applying a patch or sending customer email).
Taxonomy of proof and attestation topics: Gateway receipts (signed per-call evidence), Proof bundles (run-level audit pack), WPC binding (policy identity and constraints), CST binding (who and what is authorized), anti-replay binding (job-scoped CST cannot be reused), verification gates (fail-closed checks before accepting results), Trust Pulse (artifact storage and viewer), and sandbox/tool policy alignment (matching OpenClaw local controls with remote proof expectations).
Threat model
Agent proof fails in predictable ways: missing bindings, token reuse, policy drift, and unproxied model traffic. Treat proof as a security control only when the verification path is automated and blocks unsafe promotion.
| Threat | What happens | Control in Claw EA |
|---|---|---|
| Prompt-only “policy” is bypassed | Injection or tool output changes the agent’s instructions and it performs actions outside intent. | Use a WPC as policy-as-code and enforce it via verification and token binding, not via prompt text. |
| Unproxied model calls | Some calls bypass clawproxy so there are no Gateway receipts, leaving gaps in evidence. | Route model traffic through clawproxy and verify that receipts cover the required model activity for the job. |
| Replay of credentials or job tokens | A CST is reused for a different job to “borrow” authorization scope. | Marketplace anti-replay binding with job-scoped CST binding, plus short TTL and optional WPC hash pinning. |
| Policy drift between run and audit | The “current” policy differs from the policy that was in force, so an audit cannot establish what was permitted. | WPC is hash-addressed; verification uses the referenced WPC hash, not a mutable policy name. |
| Receipt tampering or partial log export | Logs are edited to remove risky actions or to fabricate calls. | Gateway receipts are signed by clawproxy and bundled into a Proof bundle; verification rejects altered receipts. |
Policy-as-code example
This is a minimal, JSON-like sketch of what teams typically put into a WPC to make proof meaningful. The exact fields vary by enterprise buildout, but the pattern is stable: bind identity, scope, allowed models, and tool blast radius to a signed, hash-addressed contract.
{
"wpc_version": "1",
"policy_name": "agent-prod-change-window",
"allow": {
"models": [
{ "provider": "openrouter_via_fal", "route": "via_clawproxy", "model": "approved-list" }
],
"tools": {
"openclaw": {
"sandbox_mode": "all",
"tool_profile": "prod-safe",
"deny": ["exec_elevated", "write:/etc/*", "network:raw"]
}
}
},
"require": {
"cst": {
"job_scoped": true,
"scope_hash": "required",
"policy_hash_pinning": "optional"
},
"proof": {
"gateway_receipts": "required",
"proof_bundle": "required"
}
},
"handling": {
"logging": { "redact_sensitive": "tools" },
"retention_days": 90
}
}
The key point is that the WPC is not advice to the model. It is an externally verifiable constraint that your execution and verification pipeline can enforce even when the agent is confused, manipulated, or simply wrong.
What proof do you get?
At the call level, you get Gateway receipts emitted by clawproxy for model calls. These receipts let you prove that a specific request and response flowed through the gateway under a specific authorization context, rather than being manually copied into logs after the fact.
At the run level, you get a Proof bundle that bundles receipts and related metadata for audit and verification. The Proof bundle is designed to be stored alongside job outputs so reviewers can verify: (1) which WPC was in force, (2) that the CST scope hash matches the intended authorization, and (3) that the set of Gateway receipts is intact and signed.
For sharing and review, you can store and view artifacts in Trust Pulse. Treat Trust Pulse as the place to look at what was proven, while your internal pipeline still performs independent verification before promoting results to production systems.
Rollback posture
Proof helps most when rollback is planned and practiced. Your rollback plan should map actions to safe reversal steps and to the evidence you will require before and after the rollback.
| Action | Safe rollback | Evidence you should require |
|---|---|---|
| Agent-generated code change | Revert commit, re-run tests, and block auto-merge until a verified Proof bundle exists for the change-producing run. | Proof bundle with complete Gateway receipts; WPC hash matches the approved change window policy. |
| Outbound communication (email, ticket update) | Send correction via the official API and disable the tool path until policy review is complete. | Proof bundle showing which tool was invoked and under which CST; receipts show the model context used to draft content. |
| Credential or secret exposure suspicion | Rotate secrets, revoke tokens, and quarantine the agent configuration until verification passes on a clean rerun. | WPC confirms redaction expectations; Proof bundle supports incident review of what the model saw and what was emitted. |
| Unexpected model provider usage | Disable the provider route and re-run with a pinned, approved model route. | Gateway receipts show the actual route used (for example, OpenRouter via fal routed through clawproxy) and support drift detection. |
FAQ
Why is prompt-only governance not sufficient for agent proof?
A prompt is mutable at runtime and can be overridden by tool output, user messages, or injection. A WPC is policy-as-code that is signed, hash-addressed, and enforced and verified outside the model, so you can fail closed when constraints are not met.
What is the difference between Gateway receipts and a Proof bundle?
Gateway receipts are per model call and are emitted by clawproxy for verification. A Proof bundle is the run-level harness artifact that packages the receipts and metadata needed to audit and verify the job end to end.
How do CSTs prevent token reuse across jobs?
A CST is issued by clawscope and can be job-scoped with a scope hash, with optional policy hash pinning to a specific WPC. Claw EA also supports marketplace anti-replay binding (job-scoped CST binding) so a token is harder to reuse outside the intended job context.
Does this replace OpenClaw sandboxing and tool policy?
No. OpenClaw sandboxing and tool policy are local safety boundaries, and you should still run openclaw security audit regularly and keep tool allowlists tight.
What if I need to prove non-model actions like filesystem writes or API calls?
Start by proving model traffic with Gateway receipts and Proof bundles, and treat tool execution evidence as an enterprise buildout based on your environment and toolchain. In practice, teams bind “dangerous” side effects to explicit approvals and require proof verification before promotion.