Gateway receipts are signed records of each model call made by an agent through clawproxy, designed so you can later prove what was requested, what policy context applied, and whether the response you used matches what the gateway saw.
In Claw EA, receipts are generated while running OpenClaw as the baseline agent runtime, then packaged into a proof bundle so verification can be automated and fail closed when something is missing or mismatched.
Step-by-step runbook
This runbook assumes your agents send model traffic through clawproxy (for example OpenRouter via fal routed through clawproxy) and that you want a verifiable audit artifact after each run.
-
Publish a WPC and treat it as the execution contract. A WPC is a Work Policy Contract (signed, hash-addressed policy artifact; served by clawcontrols). Your operator workflow should start by choosing a WPC hash for the job and keeping it stable for the run.
-
Issue a CST for the job with scope hash and optional policy hash pinning. A CST is a scoped token (issued by clawscope). If you pin the policy hash, the token can be constrained to a specific WPC so “same scope, different policy” fails verification later.
-
Route model calls through clawproxy using that CST. Do not rely on the agent prompt to “promise” it only used certain models or tools. The gateway is where you can measure and bind what actually happened.
-
Collect gateway receipts for every model call. Gateway receipts are signed receipts emitted by clawproxy for model calls. Store them with job metadata such as the job id, agent id, and the WPC hash that was intended for the run.
-
Assemble a proof bundle and verify it before accepting outputs. A proof bundle is a harness artifact bundling receipts and related metadata for audit/verification. Verification should check signatures, binding fields, and that the receipts cover the set of outputs you plan to act on.
-
Optionally publish the result to Trust Pulse. Trust Pulse is a marketplace-stored artifact for audit/viewing. Use it when you need a stable external reference for reviewers without giving them direct access to internal logs.
Common pitfall: teams only log prompts and responses. That is useful for debugging, but it is not a receipt, and it does not prove the messages were the ones actually sent to the model provider.
Threat model
Receipts are meant to address concrete failure modes: prompt tampering, post-hoc log editing, and replay of “good” outputs under a different policy context. The goal is not perfect security, it is tamper-evident evidence that can be verified independently.
| Threat | What happens | Control |
|---|---|---|
| Prompt-only policy bypass | An agent is instructed to ignore rules and call a different model, request disallowed content, or exfiltrate via the model output. | Permissioned execution via WPC plus CST scope hash, with model calls routed through clawproxy so every call is receipted. |
| Post-hoc audit log editing | Someone edits application logs to make it look like a safer prompt or different response was used. | Gateway receipts are signed at the proxy. A proof bundle can be validated later without trusting the application log pipeline. |
| Receipt replay across jobs | A prior “good” receipt or response is reused to justify a different run, or to satisfy a downstream reviewer. | Marketplace anti-replay binding (job-scoped CST binding) ties artifacts to a job context so replay fails verification. |
| Policy drift between run and review | The policy changes after execution, but reviewers assume today’s policy was enforced during the run. | WPC is hash-addressed and can be referenced by hash in the job record and pinned via CST optional policy hash pinning. |
Why permissioned execution must be policy-as-code instead of prompt-only: prompts are not an enforcement boundary. OpenClaw already treats tool policy and sandboxing as the local safety boundary, and receipts extend that idea to model traffic by making the network-level call auditable.
Policy-as-code example
Below is a JSON-like example showing how you can bind an agent run to a WPC hash and require that model calls are receipted through the gateway. Treat this as shape and intent; your exact fields depend on your enterprise buildout.
{
"job": {
"job_id": "job_2026_02_11_143200Z",
"agent_runtime": "OpenClaw",
"wpc_policy_hash_b64u": "wpc_7uQm...pinned",
"auth": {
"cst_required": true,
"cst_scope_hash": "scope_9d2c...evidence",
"pin_wpc_hash": true
},
"model_gateway": {
"route_via": "clawproxy",
"require_gateway_receipts": true
}
}
}
This is the key operational difference from “just add rules to the system prompt.” The WPC and CST define what is allowed, and the gateway receipts prove what was actually called under that contract.
What proof do you get?
At minimum you get gateway receipts for each model call, and a proof bundle that packages those receipts with enough metadata to verify them later. Verification checks the signature on each receipt, then checks bindings such as job context, CST scope hash, and any pinned WPC policy hash.
What is signed: the receipt envelope emitted by clawproxy, including fields that bind the receipt to the gateway’s view of the request and response. What is hashed: canonicalized content references (for example message payload digests) so you can detect edits even if you store the full payload elsewhere.
What is replayable: any artifact can be copied as a file, so replay defense depends on binding. The shipped control is marketplace anti-replay binding (job-scoped CST binding), which makes “valid receipt, wrong job” fail when you verify in the expected job context.
A minimal receipt and proof bundle shape (illustrative) looks like this:
{
"proof_bundle": {
"job_id": "job_2026_02_11_143200Z",
"wpc_policy_hash_b64u": "wpc_7uQm...pinned",
"cst_scope_hash": "scope_9d2c...evidence",
"receipts": [
{
"receipt_id": "rct_001",
"gateway": "clawproxy",
"model": "openrouter/...via_fal",
"request_hash": "h_req_...",
"response_hash": "h_res_...",
"issued_at": "2026-02-11T14:32:10Z",
"signature": "sig_..."
}
]
}
}
Common verification pitfall: teams verify signatures but forget to verify bindings. A valid signature only proves clawproxy issued a receipt, not that it was issued for your job, your policy hash, and your intended scope.
Rollback posture
Receipts help you roll back safely because you can distinguish “the agent said it did X” from “the gateway observed X.” In an incident, you typically pause automation, quarantine outputs, then re-run verification before reinstating write privileges.
| Action | Safe rollback | Evidence |
|---|---|---|
| Stop acting on agent outputs | Switch to read-only mode for downstream systems and require human approval for writes (enterprise buildout). | Proof bundle existence and completeness for the affected job ids. |
| Invalidate compromised scope | Rotate and re-issue CST for the next run, and treat the old CST as untrusted for new jobs. | CST scope hash in proof bundles distinguishes old runs from new runs. |
| Re-run with tightened policy | Publish a new WPC and pin it, then rerun the job so the new policy hash is unambiguous during review. | WPC hash references in job records and proof bundles show which contract applied to each run. |
| Audit what the model actually saw | Reconstruct the sequence of model calls from receipts and compare to application logs for drift. | Gateway receipts provide a proxy-level ground truth for model traffic. |
If you need stronger containment, egress allowlists enforced outside clawproxy can be implemented, but they are optional and environment-specific. The same is true for automatic cost budget enforcement and transparency log inclusion proofs, which are planned or can be implemented based on your requirements.
FAQ
Are gateway receipts the same as application logs?
No. Logs are writable by whoever controls the logging pipeline, while gateway receipts are signed artifacts emitted at the proxy for each model call and intended for later verification.
What do gateway receipts prove, exactly?
They prove that clawproxy observed and signed a specific model call under specific binding metadata, and that the request and response hashes match what you are presenting later. They do not prove the internal weights of a closed model provider.
Why can’t we enforce policy with a system prompt?
A prompt is guidance, not enforcement. Permissioned execution uses WPC and CST to define allowed behavior, then uses gateway receipts to prove what was actually executed at the model boundary.
What causes verification to fail most often?
Mismatched job context, missing receipts for some calls, or policy drift where the WPC hash used during review is not the one pinned for the run. Another common issue is routing some calls outside clawproxy, which creates unreceipted gaps.
Do receipts cover tools and filesystem actions too?
Gateway receipts cover model calls made through clawproxy. For tool execution, OpenClaw’s sandbox and tool policy controls are the local safety boundary, and the proof bundle focuses on receipted model traffic plus related run metadata.