On September 9, the Cloud Security Alliance hosted a briefing on the emerging chain of custody for AI agents: verified identity, attenuated delegation, hardware-signed proof of what an agent actually ran, and a governance framework that appraises agents against that evidence. Alongside it, something concrete shipped. The TRACE trust registry went public, as an open repository plus a verifier on PyPI. There is no hosted service and no query endpoint, deliberately. TRACE is an agentrust-io open specification that OPAQUE implements, not an OPAQUE product. Repository and verifier: github.com/agentrust-io/trace-registry.
What the registry is for, in one breath: AI agents increasingly act on behalf of people and companies, and the parties on the other side of those actions need more than a vendor’s word for what actually ran. A TRACE record is a signed evidence envelope describing what ran, under whose authority, and with what supporting attestations. Where hardware attestation is present, a verifier can validate that evidence rather than rely on the operator’s description. The registry is the public, append-only place those records are anchored, so a counterparty, an auditor or a regulator can later check what was claimed and when, without asking anyone’s permission. Think of it as the public notary column for agent attestations: the records stay wherever their owners keep them, and the registry pins their existence and their history.
Opening the code was the point. In Imran’s words: “you cannot ask anyone to trust a record you control. You publish it and let strangers check the math, including the ones who would enjoy catching you.”
This post is the engineering deep-dive: how the registry is built so that you do not have to trust the people who run it. Including us.
The design problem
A registry’s job is to be believed by strangers. But any registry publishes its own history. Signatures prove records are authentic, not that everyone sees the same set, which is the split-view problem. And “trust our database” fails exactly when it matters: disputes, audits, adversaries.
The requirements that fall out: append-only history with cheap proofs at any scale, verification that works offline, nothing sensitive leaving anyone’s infrastructure by default, and an integrity anchor that lives outside the operator.
How it is built: an append-only log, checkpointed
The registry’s checkpointed portion is an append-only Merkle Mountain Range, with the existing per-batch RFC 6962 inclusion proofs unchanged underneath. MMRs suit evidence logs. Appending never rewrites what came before, so a proof you saved last month still verifies today. Inclusion and consistency proofs stay small at any log size, and the structure suits local-first logs that sync later.
On a cadence driven by activity rather than a heartbeat, the log emits a checkpoint of a few hundred content-free bytes: the log size, the accumulator root derived from the MMR peaks, the previous checkpoint’s size and commitment, the issuer key id, and a consistency proof back to the previous checkpoint. The registry signs it as deterministic JSON with Ed25519, matching the shipped capsule-emit shape. A COSE_Sign1 wire encoding is a coordinated follow-up across the implementations, not what ships today. No payloads, and no metadata about record contents. The chained reference to the previous checkpoint lets a verifier check, across consecutive checkpoints, that the log is a strict extension of its past, which is a consistency guarantee on top of integrity.
Three things about this design are worth naming.
Interop by construction. The registry and our own logs follow the same checkpoint discipline: a log size, a commitment over the accumulator, a chained reference to the previous checkpoint and an issuer key, under different field names and two wire formats. The registry signs deterministic JSON carrying a single peaks-derived root; the capsule ledger signs COSE_Sign1 carrying a peak list. What holds today is the same discipline, a published name mapping and two wires, with convergence on one wire as the coordinated follow-up. The disciplines match because they are the same construction. The registry’s checkpoint layer is the CLL append-only MMR with its signed, consistency-checkable checkpoints, contributed to the registry in the open by Action State Group and reviewed and merged by its maintainers (trace-registry #54), pinned against the same MMRIVER draft test vector as the capsule ledger. The registry’s verifier checks the witness’s receipts end to end; the witness checks the registry’s checkpoint signature before countersigning. The registry’s log carries TRACE records, the capsule ledger carries Agent Action Capsule records, and the checkpoint layer never sees either. That is why evidence from two different record formats ends up comparable instead of parallel.
Disclose later. Nothing is pushed to a transparency service upfront. You keep evidence local, checkpoint it cheaply and continuously, and if a dispute or an audit ever needs a specific record, you disclose it then, already provably unrewritten since the checkpoint that covered it. Accountability without a firehose of data leaving your infrastructure.
It is live. Checkpoint 1 is published and checkable: log_id trace-registry/v1, mmr_size 1, root 3af8ddf2c1f429bb4fc670437e48640887f60de809b18f8ccea55fefb0c6639a. The registry holds two entries today, one of them checkpointed, and checkpoint 1 sits at registry/2026/09/01.ndjson in the repository next to the verifier.
Cross-witnessing: the part no operator can do alone
Checkpoints are submitted to an independent witness, witness.agentactioncapsule.org, free and public, operated by Action State Group: a different company, with different incentives, keeping its own log. The witness countersigns the checkpoints it is sent and publishes them in its own log.
What that stamp says, exactly: it proves inclusion of the checkpoint under the witness’s key. Whether a receipt also carries a witness-observed time or a signed grade is a property of that receipt, so the registry’s verifier reports witness_time_established and grade_cryptographically_bound rather than asserting either. Read those two fields rather than this sentence. For the September 7 capture both are false, because that receipt signs the log root rather than a clock and reports its grade outside the signature, and those values are permanent for that receipt. The witness began signing a registration time and a grade on September 12, but it registers a checkpoint by a content-addressed hash, so submitting checkpoint 1 again returns the receipt it already has. The next checkpoint, when the log advances for a real reason, will carry both fields. Its signed grade will be countersigned-observed: this registry is enrolled as a foreign accumulator, which the witness observes and countersigns without verifying the registry’s own consistency proofs. The witness attests the bytes it saw. Continuity is a property a verifier computes across stamps, not one the witness certifies.
On September 7 the registry submitted checkpoint 1’s existing JSON bytes through the enrolled route and fetched the stamp back by log id and by digest. All three responses carried the same receipt, leaf 936 of a 937-leaf witness tree, and the registry’s standalone verifier checked the registry signature, the checkpoint-to-receipt binding and the witness signature under a pinned key, offline. The captured evidence, the verifier and the negative tests that fail when either signature check is removed are in the registry repository.
Action State Group is a witness here, not the witness. A log can anchor into several witnesses in parallel or run its own, and bring-your-own-witness stays first class. Witnessing a digest attests inclusion under the witness’s key and never endorses content, which is the same rule the witness applies to everyone. Plurality is an engineering property, not a courtesy. Because both logs are Merkle Mountain Ranges, a witness holds no entry data at all: a few hundred bytes per checkpoint, whatever the size of the log behind it. A witness enrolled to verify a log’s own accumulator can additionally check each checkpoint against its predecessor with a logarithmic consistency proof; this registry is enrolled the other way, by design: observed and countersigned, not verified. Either way the cost of being a witness stays small, which is why neither of us treats the witness seat as something to own. It is also the security argument: sustained equivocation means fooling every witness a verifier consults at once, so the number of independent witnesses is the parameter that matters, and the cost of being one is what sets that number.
From the moment a checkpoint is countersigned, the covered history is pinned. Rewriting a record means producing a commitment that contradicts a checkpoint already sitting in someone else’s log, and showing different histories to different people means fooling independent operators at once.
That cuts against the usual vendor script. With the witness in place, you do not have to trust OPAQUE, and you do not have to trust Action State either. Neither of us is asking to be believed.
If you want to check: the whole audit, offline
Who you must trust: no one’s word, only public keys and open-source math. Every step runs offline with published tooling, and all three checks are one install, pip install “trace-verify[witness]”: trace-verify for inclusion, trace-verify chain for the checkpoint chain, and trace-verify receipt for the witness receipt. None needs a clone of the registry. The capsule side runs the same three checks with its own tooling, against its own log and the same witness: inclusion, chain consistency, countersigned receipt. Same construction, two toolchains.
What this proves, and what it does not
Witnessing proves the integrity and consistency of the published history: what was recorded has not been rewritten, and the history the witness observed is pinned outside the registry operator. That does not by itself mean every reader was shown the same view; detecting a split view still requires comparing against the witness, another observer or another witness. It does not prove the log is a complete account of reality either, and more witnesses do not help: a party that never records something has nothing to witness. Closing that gap takes the other side of the exchange: the counterparty’s own record of it, and a way to ask for it where an answer, a refusal, and an absence are three different, attributable things rather than the same silence. That is the next piece of work.
Two more limits, named outright. The registry’s June 2026 entry predates checkpointing and is deliberately never folded into the log retroactively, so the chain proves consistency of what it covers, not coverage of the registry. And the producer key behind the first anchored record verifies that record and will never sign another, because the demo that produced it generates keys per run. Trust infrastructure that overstates its guarantees is worse than none. The grade is signed under a private-use COSE label agreed bilaterally between the registry and the witness, not a registered one. A third implementer must not read it as standard, and it moves if a registered label is ever assigned.
Check our work
- The trace registry: github.com/agentrust-io/trace-registry, with the verifier and checkpoint 1 at registry/2026/09/01.ndjson.
- TRACE, an open specification series at LF Projects: trace.agentrust-io.com.
- The checkpoint mechanism: The Checkpointed Local Log, an IETF Internet-Draft in progress.
- The reference stack: capsule-emit, whose seal() produces signed, chained records; checkpointed-local-log, the MMR log and its checkpoints; and capsule-anchor, the witness service, one Apache-2.0 deployment you can run yourself.
- The verifiers and conformance vectors: verify.agentactioncapsule.org, with vectors in the agent-action-capsule and checkpointed-local-log repositories.
You do not have to use either of our services. Run the code and check the math.
Open artifacts to build on
The pieces are open standards on purpose, because what matters is what gets built on them, on both sides of the evidence. On the producing side, anyone already logging receipts, whether an agent platform, a marketplace or another registry, can get these properties without handing anyone their data. Where you wrote log(), write seal(): the record composes, chains and gets witnessed, and yesterday’s log file becomes evidence. A few hundred content-free bytes is the entire disclosure. On the consuming side, checkpoints, receipts and proofs are stable, specified artifacts rather than vendor APIs, so auditors’ checklists, GRC tooling and assurance frameworks can verify any conforming log with one implementation instead of one integration per vendor. Interoperable evidence is what makes an assurance ecosystem possible, and it is the layer we are both betting on.
The specifications live where open work belongs, at the IETF (SCITT and COSE) and the Linux Foundation (TRACE), and the work continues there. More logs and more witnesses are welcome. Becoming a witness takes an honest clock and a public key: capsule-anchor is Apache-2.0, and enrolling a log’s declared wire form is one configuration entry.
“Agent actions are becoming the records that matter, and records only count when a disinterested party can vouch for their history. The witness attests inclusion, never content, on identical terms for this registry, for our own logs, and for anyone who shows up with a checkpoint.” Steven Mih, Action State Group
Top comments (0)