Agent Proof and Attestation (Receipts and Proof Bundles)

Agent proof and attestation is the ability to show what an agent did, under which permissions, and which model calls were made, in a way another party can verify. In Claw EA, OpenClaw is the baseline runtime, and Claw Bureau primitives add verifiable artifacts: a WPC, a CST, gateway receipts, and a proof bundle.

This only works if execution is permissioned with policy-as-code, not prompt-only rules. Prompts can be bypassed by injection or tool misuse, but a WPC and CST are enforced by the execution layer and can be verified after the fact.

Step-by-step runbook#

1. Decide what you need to prove and to whom. Typical recipients are internal audit, customers, or incident response. Write down which claims must be verifiable: allowed tools, model routing, and whether a specific policy was pinned.

2. Author and publish a WPC. A WPC is a Work Policy Contract (signed, hash-addressed policy artifact; served by clawcontrols). Treat the policy hash as the stable identifier you will later pin and audit against.

3. Issue a CST tied to the job. A CST is a scoped token (issued by clawscope). Use the CST scope hash and, when you need hard guarantees, use optional policy hash pinning so the job can only run under the intended WPC.

4. Run the agent with model traffic routed through clawproxy. clawproxy emits gateway receipts for model calls. This is where you get verifiable evidence of what was sent to the model and what came back, plus binding metadata.

5. Collect artifacts into a proof bundle. The proof bundle is the harness artifact bundling receipts and related metadata for audit/verification. Store it alongside any produced outputs so you can later answer “which policy and token allowed this result?”

6. Verify before accepting results. In high-risk workflows, verification should be a gate in CI, a deployment pipeline, or a human approval step. Fail closed when the policy hash does not match, receipts are missing, or binding metadata indicates replay risk.

7. Optionally publish to Trust Pulse. Trust Pulse is a marketplace-stored artifact for audit/viewing. Use it when you need a durable viewer surface for third parties without giving them your internal logs.

Threat model#

Prompt-only “policies” fail because they are advice to the model, not enforcement on execution. A well-scoped CST plus a pinned WPC moves control to something the model cannot rewrite mid-run.

Policy-as-code example#

This is a small, JSON-like sketch of the kind of fields teams typically pin and verify. The point is not the exact schema, but the discipline: a signed WPC defines allowed execution, and the CST pins to its hash so “approved” equals “executed.”

{
  "wpc": {
    "policy_hash": "b64u:...hash...",
    "version": "2026-02-11",
    "tools": {
      "profile": "allowlist",
      "allow": ["read", "write", "exec"],
      "deny": ["browser_remote_control", "host_elevated_exec"]
    },
    "models": {
      "route_via": "clawproxy",
      "provider": "OpenRouter_via_fal"
    }
  },
  "cst": {
    "scope_hash": "b64u:...hash...",
    "pin_policy_hash": "b64u:...hash...",
    "job_binding": "required"
  },
  "verification": {
    "require_gateway_receipts": true,
    "fail_closed_on_missing_receipts": true
  }
}

Where prompt-only policies say “do not use X,” this policy says “X is not available.” That difference is what makes verification meaningful during an incident review.

What proof do you get?#

For each model call routed through clawproxy, you get gateway receipts: signed receipts emitted by clawproxy for model calls. These receipts are designed to be checked later so you can validate that a given response corresponds to a specific request under a specific job context.

A proof bundle packages those receipts with run metadata needed for audit. In practice, you want the bundle to let a reviewer answer: which WPC was in force, which CST authorized the actions, which model calls occurred, and whether the run is consistent with your approval process.

In workflows that cross organizational boundaries, the proof bundle is also your “hand-off unit.” You can provide the bundle to a customer or auditor without giving them shell access to your runner, and they can verify that the run meets the agreed policy constraints.

If you publish to Trust Pulse, you get a marketplace-stored artifact for audit/viewing. Use it when you need a consistent review surface across many jobs, and when you want to reduce ad hoc “send me logs” requests.

Rollback posture#

Attestation is only useful if you can stop and revert safely when verification fails. Your rollback posture should be explicit per job type, including what is reversible, what requires human approval, and what evidence you keep.

FAQ#

What is the difference between gateway receipts and a proof bundle?#

Gateway receipts are per-model-call, signed receipts emitted by clawproxy. A proof bundle is the packaging that groups those receipts with run metadata so a verifier can check the whole job coherently.

Why can’t we just log prompts and responses?#

Logs are easy to edit, omit, or reformat, and they do not prove what policy constrained execution. Receipts plus WPC and CST binding let you check that the run was authorized and that the model calls you see are the ones that occurred.

What does “permissioned execution” mean in practice?#

It means the agent is constrained by policy-as-code that the runtime enforces, rather than instructions in the prompt. In Claw EA terms, the WPC defines the allowed boundary and the CST carries the scoped authorization, optionally pinned to the WPC hash.

How does this relate to OpenClaw sandboxing and tool policy?#

OpenClaw already separates sandboxing (where tools run) from tool policy (which tools exist) and elevated execution (host escape hatch). Claw EA adds attestable controls around authorization and verification, while OpenClaw remains the baseline runtime for tool execution and local safety boundaries.

Can we use this with Microsoft identity and Conditional Access?#

It can be implemented in enterprise buildout, typically by issuing CSTs based on your enterprise identity flow and gating job launch on your Entra ID posture. If you later call Microsoft services, do it via official API with explicit Microsoft Graph permissions/scopes and keep side effects reversible.

Sources#

• OpenClaw Gateway Security (audit + footguns)
• OpenClaw: Sandbox vs Tool Policy vs Elevated
• OpenClaw: Sandboxing