Tamper-evident audit logs for agents require more than saving chat transcripts. You need a permissioned execution layer that binds “what was allowed” (policy) to “what actually happened” (tool and model calls), then produces verifiable evidence you can retain and replay for audits.
Claw EA runs OpenClaw as the baseline agent runtime, then adds Work Policy Contracts (WPC), CST, gateway receipts, and proof bundles so you can prove an agent run followed a specific policy, using artifacts that are signed, hashed, and verifiable later.
Step-by-step runbook
-
Define what must be auditable for your agents: model calls, tool invocations, tool outputs, policy decisions, and operator approvals. Decide what must be retained in raw form versus redacted form, and for how long.
Write this down as an evidence checklist that security and internal audit both sign off on.
-
Publish a WPC in the WPC registry and treat its policy hash as the stable identifier for “allowed behavior.” The WPC is signed and hash-addressed, so audit reviewers can fetch the exact policy later and confirm it has not changed.
This is the key difference versus prompt-only controls: prompts are not a permission boundary, and they are easy to edit without leaving a reliable compliance trail.
-
Issue a CST from clawscope for each job run, scoped to the minimum capabilities needed. Enable optional policy hash pinning so the CST is bound to the exact WPC hash expected for that run.
This prevents “policy drift” where the agent runs under a different policy than the one the ticket or approval referenced.
-
Route model traffic through clawproxy so each model call emits gateway receipts. Store gateway receipts alongside run metadata, including job identifiers and the CST scope hash.
For OpenRouter via fal, keep the same pattern: model requests still go through clawproxy so the evidence format stays consistent.
-
Bundle evidence into a proof bundle at the end of the run. Retain the proof bundle in your evidence store and optionally publish a Trust Pulse for easy viewing and third-party audit workflows.
Keep an internal pointer from your ticketing system to the proof bundle hash, not to a mutable URL.
-
Verify before you ship: re-verify a sample of proof bundles as part of CI or release gates for agent changes. Treat verification failures as a production incident, because “no proof” usually means “no audit.”
Also run OpenClaw’s local security audit periodically to reduce common gateway configuration footguns that undermine your overall posture.
Threat model
Tamper-evident logs are designed for environments where you assume failures, mistakes, and incentives to edit history. The table below lists common failure modes and the specific control you should expect to hold.
| Threat | What happens | Control you rely on |
|---|---|---|
| Prompt-only “policy” is bypassed | An injected instruction convinces the model to call risky tools or exfiltrate data, and the prompt transcript is later “cleaned up.” | Permissioned execution via WPC plus tool policy and sandboxing in OpenClaw. Evidence is anchored by signed WPC and run-bound receipts, not by editable chat text. |
| Evidence replay or substitution | A proof artifact from one run is reused to “prove” a different run, or receipts are mixed across jobs. | Marketplace anti-replay binding using job-scoped CST binding, plus consistent job identifiers inside the proof bundle metadata. |
| Selective deletion of bad events | Someone removes the one model call or tool step that looks suspicious, leaving the rest of the log intact. | Proof bundle integrity checks over receipt sets and metadata, so missing or altered components fail verification. |
| Unverifiable “screenshots of logs” | An auditor receives exports with no cryptographic binding to the original system and no stable identifiers. | Gateway receipts are signed, and WPC is hash-addressed and fetchable for verification. Auditors can re-check signatures and hashes independently. |
| Overbroad execution surface | A single configuration mistake exposes the gateway, a browser control port, or elevated host execution to untrusted users. | OpenClaw’s security audit and strict tool profiles reduce the chance of “open rooms plus dangerous tools.” Treat these checks as required operational hygiene, not optional. |
Policy-as-code example
This is a JSON-like sketch of what teams typically pin for auditability: the WPC identity, the CST constraints, and retention rules. The important part is that the run is permissioned by artifacts that can be fetched and verified later, not by whatever prompt text happened to be used that day.
{
"job": {
"job_id": "job_2026_02_11_00123",
"agent_runtime": "OpenClaw",
"wpc": {
"policy_hash_b64u": "wpc_hash_here",
"required": true
}
},
"auth": {
"cst": {
"issuer": "clawscope",
"scope_hash": "scope_hash_here",
"pin_policy_hash": "wpc_hash_here",
"ttl_seconds": 3600
}
},
"model_calls": {
"route_via": "clawproxy",
"require_gateway_receipts": true
},
"evidence": {
"proof_bundle": {
"include": ["gateway_receipts", "job_metadata", "policy_reference"],
"store_immutable": true
},
"retention": {
"raw_days": 30,
"redacted_days": 365,
"legal_hold": "manual"
}
}
}If you need egress allowlists outside clawproxy, automatic cost budget enforcement, or transparency log inclusion proofs, those are optional or planned items and should be treated as separate implementation workstreams.
What proof do you get?
In Claw EA, the minimum tamper-evident evidence set is: the signed WPC reference, the CST scope hash (and optional policy hash pinning), gateway receipts for each model call, and a proof bundle that packages the run context. The goal is to answer “what was allowed?” and “what happened?” with artifacts that can be checked later without trusting the operator who exports them.
What is signed: gateway receipts are signed by clawproxy, and the WPC is a signed artifact served by clawcontrols. What is hashed: the WPC is hash-addressed, CST includes a scope hash, and the proof bundle includes stable identifiers so you can detect missing or swapped components.
What is replayable: auditors can replay verification, meaning they can re-check signatures and policy hashes and confirm receipts belong to the job context. This is not “replaying the agent,” it is replaying the evidence validation steps so a reviewer can reach the same conclusion independently.
A compact “shape” of the evidence often looks like this:
{
"proof_bundle_id": "pb_...",
"job_id": "job_...",
"wpc_policy_hash_b64u": "wpc_...",
"cst_scope_hash": "scope_...",
"receipts": [
{
"receipt_id": "r_...",
"provider": "openrouter_via_fal",
"model": "model_name",
"request_hash": "h_req_...",
"response_hash": "h_res_...",
"signature": "sig_..."
}
],
"timestamps": {
"started_at": "2026-02-11T10:00:00Z",
"ended_at": "2026-02-11T10:07:12Z"
}
}Common pitfalls: logging only the final assistant message, storing mutable “latest policy” instead of pinning a policy hash, and letting teams bypass the proxy path for “just one quick test.” Those shortcuts tend to surface during incident response, when you discover the evidence gaps are exactly where you needed proof.
Rollback posture
Tamper-evident audit logs are most useful when they support safe rollback after a bad run. Rollback should be operationally boring: revoke credentials, stop new work, and preserve evidence without depending on anyone’s memory of what happened.
| Action | Safe rollback | Evidence you should keep |
|---|---|---|
| Agent started calling an unexpected model or route | Require routing via clawproxy for model calls and block direct paths in your deployment config. Re-run verification on the last known good proof bundle and compare WPC and scope hashes. | Gateway receipts showing provider and model, plus the proof bundle for the incident window. |
| Policy changed and behavior drifted | Roll back to the previous WPC hash and re-issue CST with policy hash pinning to that hash. Treat any run without a pinned policy hash as lower confidence during review. | WPC hashes for each release, CST scope hashes per job, and proof bundles before and after the change. |
| Suspected credential misuse during a run | Revoke CST issuance paths for the affected job pattern, rotate downstream secrets out of band, and keep the evidence immutable. Confirm the receipts and job binding to rule out cross-job substitution. | Proof bundle, gateway receipts, and the run’s job-scoped CST binding context. |
| Need to satisfy retention and audit export requirements | Store proof bundles in an immutable evidence store, and use Trust Pulse for audit viewing when appropriate. Keep redaction rules explicit and versioned so reviewers know what was removed and why. | Proof bundle identifiers, retention policy versions, and any redaction configuration tied to the job. |
FAQ
Why is prompt-only governance not enough?
Prompts are not a permission system, and they are easy to edit after the fact. A permissioned execution layer uses WPC and CST so the run is constrained by machine-enforced policy, and the audit trail binds that policy to actual model and tool activity.
What should we retain for “audit replay evidence”?
Retain WPC policy hashes, CST scope hashes, gateway receipts for model calls, and the proof bundle for each job. Add run metadata such as job id, timestamps, and the agent version so reviewers can re-check evidence without relying on mutable environment state.
How does tamper-evidence work if logs are stored in our systems?
Tamper-evidence comes from signatures and hashes that fail verification if altered, even if the storage system is compromised later. You still need good storage controls, but verification lets you detect edits and missing components instead of trusting exports at face value.
Do we get a Microsoft-style audit log feed automatically?
Not by default. If you need to align with Microsoft audit practices, you can map agent events and evidence references into your own logging pipeline via official API or enterprise buildout, and keep proof bundles as the cryptographic source of truth.
What is the fastest way to find configuration mistakes before incidents?
Run OpenClaw’s security audit regularly and treat failures as blockers, especially after changing network exposure, tool profiles, or sandbox settings. Pair that with “verify a proof bundle sample” in CI so you catch missing receipts or unpinned policy hashes early.