Telemetry Attestation and Tamper Evidence

Telemetry Attestation & Tamper-Evidence

Shipped in v0.1.77 (Track 1). The differentiator: CW does not run the model, yet it can prove whether the executor's reported token usage is real and unedited.

The problem

A control-plane that delegates model execution only ever learns what the executor reports. If it trusts unverified self-reports, it audits claims, not facts — and a forged "green" record is indistinguishable from a real one. For an auditable runtime that is existential.

Two layers of evidence

1. ed25519 attestation (the executor really said this)

The executor signs the canonical usage payload (usage + runId + taskId + promptDigest, key-sorted JSON, plus a resultDigest when it covers the finding) with a private key; CW verifies it against the operator's public trust key at intake. The verdict is recorded as attested / unattested / absent — surfaced loudly, never silently averaged. CW only ever holds the public half (CW_AGENT_ATTEST_PUBKEY / agent attestPublicKey).

• signTelemetry() / verifyTelemetryAttestation() in telemetry-attestation.ts.
• The signature binds the promptDigest, so a signature cannot be replayed onto a different task or run.
• When the executor also signs sha256(result), the signature binds the finding itself: edit a signed result and CW re-derives a different digest, so the signature no longer matches. cw report verify-bundle uses this to prove every signed finding is in the report unaltered, offline, with only the public key.

2. Hash-chained ledger (CW really recorded that, unedited)

Every hop appends one record to an append-only chain (telemetry.json, a runDir peer): recordHash = sha256(canonical record sans hash), and each record's prevHash links the previous record's hash (genesis = sha256("cw-telemetry-ledger:" + runId)).

verifyTelemetryLedger() recomputes every hash independently — it never trusts the stored value — and re-proves the chain linkage. Two protections:

• per-record digest: edit any field, the record's hash no longer recomputes.
• chain linkage: even if an attacker recomputes the edited record's local hash to cover their tracks, every record after it was linked to the original hash — so the chain breaks downstream. A flat per-record hash could be defeated by recomputation; the chain cannot.

Fail-closed mode (opt-in)

require-attested-telemetry (flag / env / agent config) refuses to accept any hop whose usage cannot be cryptographically verified. Off by default — most executors aren't signing yet, so default-on would break live runs; security-strict operators turn it on. Composes with limits.tokenBudget (Track 3) for strict budget-against-attested-usage accounting.

See it / verify it

cw demo tamper            # hermetic proof: build a signed report, forge it 3 ways (ledger + signature + result), watch it fail offline
cw telemetry verify <run> # operator-facing: re-prove a real run's ledger (cw_telemetry_verify on MCP)
cw report verify-bundle report.cwrun.json   # prove the signed findings are present + unaltered, offline

cw demo tamper is fully hermetic (ephemeral keypair, no model, no network, no API key) and exits nonzero if the proof ever fails to hold — it cannot green a broken integrity guarantee. See Observability Cost Accounting for how attested usage feeds cost, and Boundary Contracts for the budget gate that consumes it.