All posts
· 12 min read ·

What Certificate Transparency for the agent web would actually look like

Sigstore Rekor logs software signing. ERC-8004 logs on-chain identity. Merkle Tree Certificates are about to land in TLS. The agent web has every primitive needed to compose a Certificate-Transparency-style append-only log of card publications, probe results, and revocations, and none of the existing public registries is one.

The web took a decade to converge on Certificate Transparency. The Sigstore Rekor transparency log added the same primitive for software signing in 2022 and now logs every signed npm package, container image, and Python wheel that passes through the ecosystem's signing infrastructure. Google and Cloudflare are live-testing Merkle Tree Certificates as the next-generation analog for HTTPS, with a quantum-resistant root store targeted for late 2027. Each of these is the same shape of mechanism: an append-only public log that lets anyone audit what was published and when, with cryptographic proofs that the log hasn't been tampered with.

The agent web has signed cards, on-chain identity registries, and 10,000-plus MCP servers across competing aggregators. It does not yet have a transparency log in the CT-and-Rekor shape. The primitives to build one are well-known and battle-tested; the agent-specific schema is missing. This post is about what the missing piece would actually look like.

What Certificate Transparency does and doesn't do

CT, as standardized in RFC 6962, is structurally simple. A log accepts entries (usually X.509 certificate issuances) and arranges them in a Merkle tree. Each new entry produces a Signed Certificate Timestamp (SCT) that proves the log saw and included it. Browsers refuse to trust certificates that don't carry SCTs from logs they recognize. Anyone can audit the log by walking the tree, comparing the leaf they care about against the tree's signed root, and verifying that the proof chain is consistent. The log operator could be malicious; the cryptographic structure makes that detectable.

CT does not authenticate the content of what's logged. A maliciously-issued certificate gets logged just as faithfully as a legitimate one. What CT provides is evidence — if a bad certificate exists, it will appear in the log, and the parties whose identity was misused can detect it. The defense is observability, not prevention.

That distinction matters when imagining the agent-web analog.

What an agent transparency log would actually log

Append-only transparency log for agent cards and probe results A Merkle-tree-style diagram showing an append-only transparency log adapted for the agent web. The leaves of the tree are individual log entries containing one of three event types: card publication, probe result, or revocation. Each leaf is hashed and combined pairwise up the tree, with a single signed root at the top. The log is operated by an independent party. Cryptographic inclusion proofs let anyone verify that a specific leaf is in the tree. AGENT TRANSPARENCY LOG · APPEND-ONLY MERKLE STRUCTURE root hash SIGNED · PUBLIC hash(left half) hash(right half) card publication sha256(card), signer key, ts probe result probe id, findings, ts card publication v2 of agent, new signer key revocation card hash, reason, ts

LEAVES · ONE LOG ENTRY PER OBSERVABLE EVENT Anyone can fetch an inclusion proof for any leaf and verify it against the signed root. No operator can rewrite history undetected.

Three classes of log entries cover most of what consumers of the agent web actually need to audit:

  • Card publications. When an MCP server, A2A agent, or Skill package is published or updated, an entry records the cryptographic hash of the card, the signer key, and the timestamp. A consumer holding a card today can ask "was this card actually published by this signer at this time?" and get a cryptographic answer.
  • Probe results. When an independent prober runs a conformance test against an agent and publishes the result, an entry records the probe identity, the agent it tested, the findings, and the timestamp. A consumer asking "is this agent behaving the way it claims?" can read a population of probe results against the same card.
  • Revocations. When an operator revokes a card (key compromise, agent decommissioned, behavior recalled), an entry records the hash of the revoked card with a stated reason. A consumer with a cached card can detect the revocation through routine log polling.

None of those entries authenticates the content of what's logged (the log records that someone signed this card, that this prober found these results), but the existence and ordering of entries becomes irrefutable, and the absence of entries becomes evidence of fraud. That second property is what makes CT useful in the first place.

The pieces that already exist

Three pieces of the agent transparency stack are already in production for adjacent purposes:

  • Sigstore Rekor logs signed software artifacts and is used by npm, PyPI, the container ecosystem, and many open-source projects. An MCP server is a piece of software, and an MCP server's published version can already be Rekor-logged via Sigstore today. The work to extend that into the agent card metadata is incremental, not foundational.
  • ERC-8004's Identity Registry is an on-chain append-only log of agent identifiers. Different trust model from a CT log (block-producer consensus instead of log operator), but the same load-bearing property: history is not rewritable.
  • The AAIF MCP Registry is a publication index for MCP servers. It is not a transparency log today — entries can be updated and removed without a cryptographic audit trail. The schema is the missing piece, not the storage.

The pattern of the missing piece is concrete. Take Rekor's transparency-log architecture, add agent-card and probe-result entry types, run independent log operators, and require consumer-side verification of inclusion proofs before trusting an agent claim. Each individual step is well-trodden; the composition is the work that hasn't been done.

What stops it

The technical barrier is low. The coordination barrier is the familiar one: who runs the logs, what consumers enforce inclusion, and what the cost model is.

CT's existing logs are run by a small set of operators that browsers hard-code as trusted. The web took that on because the threat model (misissued certificates) was concrete and the operational economics (small number of logs, predictable volume) were tractable. Sigstore's logs follow a similar pattern with OpenSSF backing. For the agent web, the equivalent trusted-operator set has no obvious provider yet. The AAIF could run one. The AGNTCY project could run one. ERC-8004's on-chain registries are already running a specific shape of this. None has committed to running an agent-card transparency log at the breadth Rekor covers for software.

The consumer-side enforcement is the other half. CT-with-no-browser-side-check is just an audit trail. CT-with-Chrome-refusing-non-SCT-certificates is a defense. The equivalent for agents is whether an agent runtime (Claude Code, Cursor, Devin, goose) refuses to install or run an MCP server whose card isn't logged. None does today. The first one that does will be the practical step that turns "transparency log for agents" from architecture into infrastructure.

What this means for the registry layer

The Agenstry-relevant observation is the same one we keep coming back to: self-declared claims are different from independently logged evidence. A registry that publishes "this MCP server claims spec compliance" is encoding a marketing string. A registry that publishes "this MCP server's card was logged at timestamp T, and here are the probe results logged against it since" is encoding an audit trail.

The audit trail is the underlying primitive. The registry is one of several consumers of it. The next step for the agent web is for those primitives to compose: Sigstore-style transparency for the package layer, an analog at the agent-card layer, and consumer-side enforcement gates at the agent runtime layer. Each layer has a real-world precedent the agent web can draw on; the composition is what doesn't ship yet.

What we're watching

Three things, observable in the next two quarters:

  1. Whether AAIF or AGNTCY commits to running an agent-card transparency log. Both foundations have the governance structure to operate one. The first commitment of staff and infrastructure to it will be the signal that the field is beginning to compose this layer.
  2. Whether an agent runtime adds a transparency-log enforcement flag. A Claude Code or Cursor option that refuses to load an MCP server without an SCT-like proof would create the consumer-side pull that CT itself eventually produced for browsers. Without the runtime enforcement, the log is incentive-misaligned with adoption.
  3. Whether the Merkle Tree Certificate work adopted by Chrome influences the agent-card identity schema. The quantum-resistant Merkle Tree Certificate design from Google and Cloudflare may be the better substrate than conventional X.509 + CT for an agent web building from scratch. If the AAIF or AGNTCY identity work adopts MTC-style structures, the agent transparency log can use the same architecture from day one.

The web's transparency stack took five years from CT proposal to Chrome enforcement. The agent web's version has all the pieces and none of the composition; the next year will tell whether someone puts them together or whether the agent web keeps trusting self-declared cards.

Sources

← Back to blog Agenstry