Agent evidence needs a verifiable chain of custody.

Other industries have already confronted the trust problem.

As agents perform work across organizational systems, the records they leave become part of operational accountability. Teams need to investigate outcomes, explain decisions, and sometimes provide evidence to someone who does not operate the original application. At that point, ‘the dashboard says so’ is a weak basis for assurance.

Software supply chains offer a useful reference. Sigstore’s Rekor records signed metadata in a transparency log and supports checking inclusion and the integrity of the log. Certificate Transparency addresses a different domain, TLS certificates, but uses related verifiable structures. RFC 9162 describes inclusion and consistency proofs that allow participants to check properties of the recorded history.

These systems do not establish that AI governance and software signing are the same problem. They demonstrate a narrower design principle: a party outside the original application can verify specific properties of a record without simply trusting that application’s current presentation. We think agent evidence should be evaluated with that same precision.

Sources: [1][2]

Integrity and truth are separate questions.

A valid signature can help establish that a key signed a particular statement. A hash can help detect a change to recorded content. Neither mechanism establishes that the statement describes the world accurately. If an integration records an incorrect actor or misses an action, applying cryptography afterward does not repair the evidence.

The word ‘log’ does not settle this distinction. Logs can have strong integrity controls, and a product can call something a receipt while offering very little assurance. The useful questions concern the fields captured, the meaning of those fields, the controls around the record, and what a verifier can independently check.

For an agent action, those fields may include the actor, attempted operation, relevant rule version, verdict, approval history, and available execution result. Each has a different meaning. A permit shows that a request passed the applicable evaluation. It does not establish that the target system completed the requested change. An imported event can describe a completed operation without establishing that it was checked beforehand.

A proof needs a claim small enough to verify.

An inclusion proof demonstrates that a particular leaf is included in a particular Merkle tree root. A consistency proof can help establish that a later tree extends an earlier one without changing the prior entries. A signed checkpoint binds a signer to a particular tree state. These are useful, specific claims. They do not automatically prove that every relevant event was captured.

RFC 9162 itself makes a careful distinction: Certificate Transparency does not prevent certificate misissuance, but makes detection possible for interested parties. That separation between recording, detection, and prevention is a valuable lesson for agent systems. A trustworthy account should name which of those functions it provides.

Verification also depends on the verifier’s inputs and trust decisions. Which key is expected? Which checkpoint is being checked? Is the relevant time window covered? Optional timestamps or independent witnesses may strengthen particular assurances, but they should be described as configured mechanisms rather than implied properties of every record.

Sources: [2]

We keep the event, its governance context, and its limits together.

Our response is an ordered, append-only receipt chain connected to the governance record. Receipts carry event information, sequence and cryptographic links, with the associated actor, rule, approval, and outcome evidence available through the connected record. Corrections should add to the history rather than quietly replace it.

Where transparency publication is configured, a receipt can be accompanied by an inclusion proof against a signed checkpoint. Independent timestamps and witness cosignatures are optional configured additions. These mechanisms complement the internal chain; they do not expand the meaning of the underlying evidence.

The distinction is especially important for external review. A conformance packet can organize the available record, its coverage, and verification information. It remains evidence for someone to assess. It is not a certification that the organization complies with a regulation, or a guarantee that a recorded decision was wise.

We also keep observed activity distinct from in-path governance. Cryptographically checking an observed event does not promote it into proof of prior authorization. That limit should remain visible even when every integrity check succeeds.

Ask what would make the verification fail.

A useful demonstration includes a changed receipt, a missing link, an unexpected signing key, and a request for a period outside the available coverage. It should explain which checks detect each condition and which questions remain unanswered. If the presentation always ends with a generic green check, it is difficult to understand the actual assurance.

Then ask a separate question about meaning: does this record support the claim that a particular actor was allowed to perform a particular action at a particular time? That requires the relevant governance and execution evidence, not just an intact file. The integrity review and the substantive review should inform each other without being collapsed.

Our view is that useful evidence becomes stronger when its claims become more exact. A verifiable record with explicit limits is more valuable than a broad assurance whose basis cannot be inspected. As agents perform more consequential work, that precision should become a normal part of buying and operating their supporting systems.

• State the exact claim established by each verification step.
• Separate permission, attempted execution, and confirmed outcome.
• Check capture coverage independently from record integrity.
• Treat framework mappings as evidence references, not certification.