Replay for agent actions is only trustworthy when you can bind “what the agent was allowed to do” to “what it actually did”, and verify both later. In Claw EA, OpenClaw is the baseline agent runtime, and Claw Bureau primitives make replays and rollbacks auditable via WPC, CST, gateway receipts, and proof bundles.
Prompt-only controls are not enough because they are not enforceable at execution time and do not create a stable artifact you can verify after an incident. A permissioned execution layer with policy-as-code lets you deny unsafe tool calls, pin allowed scopes, and produce evidence that survives log rotation and human memory.
Step-by-step runbook
-
Define the action boundary you want to be able to replay. Split “model calls and tool calls” from “external side effects” (API writes, emails, deployments). You can replay the former deterministically enough for audit, but the latter must be treated as non-idempotent unless the target system supports idempotency keys or a dedicated replay mechanism via official API.
-
Write a WPC that encodes the allowed tools, model routing, and scope constraints. Treat the WPC as the contract you will show an auditor later, not a suggestion for the agent. Keep it narrow, and version it by hash so you can prove exactly what was in force at the time.
-
Issue a CST that is job-scoped, and pin it to the policy hash when you need strict replay semantics. A job-scoped CST reduces replay risk because captured tokens do not remain broadly useful. Policy hash pinning makes “same token, different policy” invalid, which matters when you are trying to reproduce a run under the original constraints.
-
Route model traffic through clawproxy to get gateway receipts. This is where you get signed evidence of model inputs and outputs at the gateway boundary, including enough metadata to verify ordering and association to a job. If you use OpenRouter via fal, keep it behind clawproxy so receipts are emitted consistently.
-
Package artifacts into a proof bundle and store it with the run record. Include the WPC hash, CST scope hash, gateway receipts, and the minimal runtime metadata required to verify context without storing secrets. If you need shared viewing, store or mirror the bundle as a Trust Pulse for audit access.
-
Verify before you replay. Recompute hashes, validate signatures on gateway receipts, and ensure the CST binding matches the job you are attempting to reproduce. Fail closed if the policy hash, scope hash, or receipt chain does not match what was recorded.
-
Replay in an isolated environment, then roll forward with explicit approvals. For tool execution, prefer sandboxed runs in OpenClaw so the replay cannot mutate production state. If a replay identifies required rollback actions, execute rollback as a separate, permissioned job with its own WPC and CST.
Threat model
Replay and rollback are most often broken by missing boundaries: logs that are editable, policies that are not pinned, or side effects that cannot be reconstructed. The table below focuses on concrete failure modes and the operational control you can apply in Claw EA with OpenClaw plus Claw Bureau primitives.
| Threat | What happens | Control |
|---|---|---|
| Token replay against a new job | An attacker reuses a captured token to rerun tools or model calls outside the intended run. | Use job-scoped CST binding (anti-replay) and keep CST TTL short. For strict cases, pin CST to the WPC hash so policy drift makes reuse fail. |
| Policy drift between original run and replay | You “replay” using today’s permissions, which can hide how the incident happened or widen damage. | Record and verify the WPC hash in the proof bundle. Require replays to reference the exact WPC and fail closed if the hash does not match. |
| Receipt gaps or partial logging | Model calls occurred outside the gateway, so you cannot prove what the model saw or returned. | Route model calls through clawproxy and require gateway receipts for the job. Treat missing receipts as an incomplete audit trail and block “verified replay” status. |
| Non-idempotent external side effects | Replaying causes double writes, duplicate emails, or repeated financial actions. | Do not treat external writes as replayable unless the target supports idempotency via official API. Prefer “simulate replay” for analysis, then do rollback with a separate, explicitly approved job. |
| Prompt-only “policy” bypass | The agent is socially engineered to ignore instructions, and then performs real tool actions. | Enforce policy at execution time with policy-as-code, not in the prompt. In OpenClaw, pair tool allow/deny and sandboxing with WPC-based constraints so the agent cannot exceed the contract. |
Policy-as-code example
This example illustrates the shape of a permissioned contract you can verify later. The WPC is the signed artifact, identified by its hash, and referenced by the job so a replay can prove the same constraints were in force.
{
"wpc_version": "v1",
"policy_name": "audit-safe-replay",
"model_routing": {
"provider": "openrouter_via_fal",
"must_use_gateway_receipts": true
},
"tools": {
"allow": ["read", "search", "http_get_via_mcp_server"],
"deny": ["exec", "write", "email_send", "deploy"]
},
"cst_requirements": {
"job_scoped": true,
"scope_hash_required": true,
"policy_hash_pinned": true
},
"retention": {
"proof_bundle_required": true,
"store_as_trust_pulse": "optional"
}
}
Two operational notes: first, deny rules must be enforced by the execution layer, not requested in the prompt. Second, any tool that can mutate state should be treated as a separate class of job with approvals, even if you later decide to allow it in a tightly scoped WPC.
What proof do you get?
Claw EA evidence is built around verifiable artifacts, not “trust me” logs. The WPC is signed and hash-addressed, the CST carries a scope hash and can be pinned to a policy hash, and gateway receipts are signed at the model gateway boundary.
A proof bundle is the harness artifact that packages those elements so you can hand it to an auditor or use it for internal incident review. If you choose, you can store or share the resulting run artifact via Trust Pulse for audit viewing.
Here is a simplified “shape” of what a bundle might contain (illustrative, not an API contract):
{
"job": { "id": "job_123", "started_at": "2026-02-11T01:02:03Z" },
"wpc": { "policy_hash": "b64u:...", "issuer": "clawcontrols" },
"cst": { "scope_hash": "b64u:...", "job_binding": "job_123" },
"gateway_receipts": [
{
"receipt_id": "rcpt_001",
"gateway": "clawproxy",
"model": "openrouter/*",
"request_hash": "b64u:...",
"response_hash": "b64u:...",
"signature": "ed25519:..."
}
],
"runtime": { "agent_runtime": "openclaw", "session": "agent:main:main" },
"artifacts": { "bundle_hash": "b64u:..." }
}
What is replayable: the sequence of model calls covered by gateway receipts, and the tool decisions recorded by the harness when tools are executed under the same WPC. What is not replayable by default: external side effects unless the external system provides replay, event archive, or idempotent write semantics via official API.
Rollback posture
Rollback is not “undo everything the agent did” unless you designed the environment for reversibility. The practical stance is to separate analysis replay from corrective actions, and require the corrective job to be permissioned and evidenced just like the original run.
| Action | Safe rollback | Evidence |
|---|---|---|
| Model call produced a bad recommendation | No rollback needed; replay for analysis and update WPC/tool policy to prevent execution without approval. | Gateway receipts show exact prompt/response hashes and ordering, with signatures from clawproxy. |
| Tool read-only action (query, fetch) | Typically no rollback; use replay to reproduce what data was accessed and when. | Proof bundle includes WPC hash and CST scope hash to show access was within contract. |
| State-changing external write (ticket update, email, deploy) | Rollback as a separate job that calls the vendor’s official API with explicit approval and idempotency where available. | Two bundles: original run bundle and rollback run bundle, each with its own WPC and gateway receipts. |
| Suspected credential exposure in logs | Revoke CST, rotate external secrets, and reduce future collection by tightening OpenClaw logging redaction and tool permissions. | Revocation records plus the original proof bundle to scope impact; OpenClaw security audit output can be attached as supporting context. |
FAQ
What can I actually replay for an agent run?
You can replay the decision trail and model interactions that are covered by gateway receipts, plus tool execution that was mediated under the same WPC and environment. You cannot safely replay external side effects unless the external system supports replay or idempotent writes via official API.
Why is prompt-only policy insufficient for audit and rollback?
A prompt is not an enforcement point and can be ignored or manipulated. Policy-as-code is enforced at execution time, and its hash can be pinned to the job so later verification proves what constraints were active.
How do WPC and CST help with anti-replay?
The WPC hash gives you an immutable identifier for the allowed behavior. A job-scoped CST binding reduces the blast radius of token capture, and policy hash pinning prevents a valid token from being reused under a different policy.
What is the minimum evidence set I should retain?
At minimum: WPC hash, CST scope hash, and gateway receipts for all model calls, packaged as a proof bundle. If you need cross-team audit viewing, store the artifact as a Trust Pulse.
How does this relate to OpenClaw sandboxing and tool policy?
OpenClaw controls where tools run and which tools are callable, which limits blast radius during replay and rollback. Claw EA adds portable, verifiable artifacts around those decisions so you can prove what happened, not just describe it.