What can we verify without recording someone’s private work?

A record can be too small to decide, and still leak

Our v0.1 agent receipt, a signed account of what an agent did, was built to keep secrets and still carried a clock. The draft’s example run ID is a ULID that decodes to a moment about two years before the receipt’s own stated issue time. [5] A ULID’s first ten characters are a timestamp, exact to the millisecond. [6] The example is made up, so the mismatch is the draft’s.

Delete issued_at and the clock stays, with nothing to vouch for it, like tearing the date off a letter but leaving the postmark. The less a private record holds, the less it gives away. Cut too far, though, and a run that followed policy and one that broke it leave the same evidence. Then the honest verdict is that the evidence can’t decide, and a review that counts a passing signature check as a catch hides exactly those cases.

Take a made-up contract review we’ll follow throughout. A legal team asks its agent to read an unpublished contract and query one permitted public filing service. Later the other side of the deal asks whether the agent followed the agreed policy. A full trace might expose the client and the negotiation, while a one-line assurance gives the other side nothing to challenge.

We want the smallest record that still supports that decision. The hard question is whether the only outbound request went to the permitted service, and for that, something had to watch. A small receipt can carry an observer’s evidence but can’t create it. If no trusted observer recorded an event, no receipt can prove it happened, and we call that the observer gap.

A signature shows which key signed, not whether memory was cleared

A signature answers one narrow question. Did the holder of this private key sign exactly this message? It can’t say whether the message is true. NIST’s signature standard describes two jobs for digital signatures, detecting unauthorized changes to signed data and confirming the claimed signer’s identity. [1]

Say the contract review’s v0.1 receipt claims retained: 0. Its signature can’t show that memory was cleared, that a provider didn’t log the request, or that no tool made a copy.

Under our current v0.2 format, a pass means only that the record fits the required schema, and that keys the recipient chose signed it and the log root it sits under. [7] [8] A receipt can pass with its four inventory lists, of tools, outgoing data, files and payments, all empty. [7] So the checker can’t tell a complete list from a trimmed or emptied one. Only the evidence policy and the reviewer can.

The reviewer still has to ask who authorized the key, which fields were signed, and whether whatever collected the record saw the action it describes. That last question takes an observer.

Attestation measures the machine; it doesn’t watch the agent act

Attestation can show what machine ran an agent, not everything the agent did. The IETF’s remote-attestation architecture, RATS, names three central roles. An Attester reports on itself, a Verifier checks the report against reference values and a policy, and a Relying Party decides. RATS asks for deliberate choices about whom to trust and how fresh the evidence must be. [2]

A one-time challenge signed into the evidence proves it was made after the challenge, but a claim inside it can still describe an older state. [2] So we’d ask a design to state its challenge, audience, time span, key binding and policy version.

In the contract review, a monitor inside one runtime may see its own network connections. It can still miss a spawned process, another agent, a browser, or data kept by a remote model provider. A signed note from the filing service would add one view, covering that one request and nothing else. A receipt should say which it claims: a measured machine, one witnessed action, or complete observation.

Agents can call tools through the Model Context Protocol (MCP), whose own specification says MCP can’t enforce its security principles at the protocol level and leaves that to implementers. [4] A monitor watching only the planned tool calls can miss what a tool does elsewhere.

A receipt that says where data went must name who watched, which routes they covered, for how long, and where they were blind. For the contract review, the claim needs a second source of events, independent enough to contradict the signer. It also needs a written trail from what that source saw to the signed field. That trail can leak too.

Without content, metadata can still join runs and identify a matter

A receipt with no prompts or files can still give secrets away. Our v0.1 example carries hosts, byte counts, hashes and a retained field. [5] Hosts can reveal suppliers, and exact times and counts, like the run ID’s clock, can identify a transaction. In the contract review, those would be the filing service’s host, the request’s size and the run’s time.

RFC 6973, a privacy guide for internet protocols, treats correlation, identification, secondary use and disclosure as distinct threats. [3] Any label that repeats lets someone join records, and a receipt has several:

• a run ID can join copies of one task held by different recipients;
• a reused signing-key ID can join different runs;
• runtime and policy hashes can fingerprint a setup;
• log positions show order and volume.

A pseudonym is still an identifier. A separate ID for each recipient might reduce joins, and so might less exact timing, but both would make disputes harder to settle.

Hashes leak too. If a file path can only be one of a few names, anyone can hash each one and look for a match. A salted commitment makes that harder, but only with a defined hiding property and fresh salt that stays protected. A bare hash over a few candidates has neither.

So a privacy review should count three kinds of leak separately:

• a value shown outright;
• a value guessed from a short list of candidates;
• records linked across runs.

Private verification will likely start with one observer and one named reviewer

We expect private verification to start small. The first receipts to hold up in a contested audit would carry one observer’s record, cut to one decision and sent to one named reviewer. In the contract review, that would be the other side’s reviewer. The observer gap sets the outer limit, and a receipt also can’t answer the question if the evidence never reaches the reviewer.

Who receives the record matters as much as which fields it keeps. Some metadata survives trimming, so a trimmed record posted for everyone may expose more people than a fuller one sent to one authorized reviewer.

Our own evidence is thin. Everything here is analysis of proposed fields and published specifications, and we’ve measured no attack on users. Our v0.2 checker has been tested only on synthetic test files. [8]

The pilot on our proposed-studies page would measure the trade with three kinds of case whose right answer is known:

• honest accounts;
• accounts with a material conflict;
• runs whose hidden effects leave the same evidence as honest ones.

Reviewers would judge each case from a fuller signed export or a trimmed one by the same observer. Meanwhile an attacker would try to recover or link what was hidden. The pilot would compare field policies, so it couldn’t show that our format beats an equally trimmed conventional export.

Two results would sink the case for smaller records. Trimming might add decision errors the reviewer had declared unacceptable, or runs from one matter might stay as linkable as before.