---
title: "What Certificate Transparency for the agent web would actually look like"
date: 2026-05-25
summary: "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."
slug: agent-web-certificate-transparency
author: "Sebastiaan Hilbers"
hero_glyph: rings
---

The web took a decade to converge on Certificate Transparency. The
[Sigstore Rekor transparency
log](https://github.com/sigstore/rekor) 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](https://thehackernews.com/2026/03/google-develops-merkle-tree.html)
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](https://agenstry.com/blog/a2a-signed-cards-key-not-identity),
[on-chain identity
registries](https://agenstry.com/blog/erc-8004-three-registries-honesty),
and [10,000-plus MCP
servers](https://agenstry.com/blog/mcp-discovery-fragmentation)
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](https://www.rfc-editor.org/rfc/rfc6962.html), 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

<svg viewBox="0 0 640 360" xmlns="http://www.w3.org/2000/svg" style="max-width:100%;height:auto;display:block;margin:28px auto" role="img" aria-labelledby="ct-title ct-desc">
  <title id="ct-title">Append-only transparency log for agent cards and probe results</title>
  <desc id="ct-desc">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.</desc>
  <style>
    .lb { fill: none; stroke: var(--c-fg-3, #6b7280); stroke-width: 1.4; }
    .lp { fill: none; stroke: var(--c-pink, #F472B6); stroke-width: 1.6; }
    .lv { fill: none; stroke: var(--c-violet, #A855F7); stroke-width: 1.6; }
    .lt { font-family: 'Geist', system-ui, sans-serif; font-size: 12px; fill: var(--c-fg, #0a0a0a); }
    .lh { font-family: 'Geist', system-ui, sans-serif; font-size: 13px; fill: var(--c-fg, #0a0a0a); font-weight: 600; }
    .lp-text { font-family: 'Geist Mono', ui-monospace, monospace; font-size: 10px; fill: var(--c-fg-2, #404040); }
    .ll { font-family: 'Geist Mono', ui-monospace, monospace; font-size: 10px; fill: var(--c-fg-4, #9ca3af); letter-spacing: 0.14em; }
    .line { stroke: var(--c-fg-3, #6b7280); stroke-width: 1.4; }
  </style>
  <text x="0" y="18" class="ll">AGENT TRANSPARENCY LOG · APPEND-ONLY MERKLE STRUCTURE</text>

  <!-- Root -->
  <rect x="270" y="36" width="100" height="36" rx="4" class="lv"/>
  <text x="320" y="58" text-anchor="middle" class="lh" style="fill:var(--c-violet,#A855F7)">root hash</text>
  <text x="320" y="84" text-anchor="middle" class="ll">SIGNED · PUBLIC</text>

  <!-- Internal nodes -->
  <line x1="320" y1="72" x2="170" y2="118" class="line"/>
  <line x1="320" y1="72" x2="470" y2="118" class="line"/>

  <rect x="120" y="118" width="100" height="32" rx="4" class="lb"/>
  <text x="170" y="138" text-anchor="middle" class="lp-text">hash(left half)</text>

  <rect x="420" y="118" width="100" height="32" rx="4" class="lb"/>
  <text x="470" y="138" text-anchor="middle" class="lp-text">hash(right half)</text>

  <line x1="170" y1="150" x2="80" y2="194" class="line"/>
  <line x1="170" y1="150" x2="260" y2="194" class="line"/>
  <line x1="470" y1="150" x2="380" y2="194" class="line"/>
  <line x1="470" y1="150" x2="560" y2="194" class="line"/>

  <!-- Leaves: log entries -->
  <rect x="35" y="194" width="90" height="76" rx="4" class="lp"/>
  <text x="80" y="212" text-anchor="middle" class="lt" style="fill:var(--c-pink,#F472B6); font-weight:600">card</text>
  <text x="80" y="226" text-anchor="middle" class="lp-text">publication</text>
  <text x="80" y="246" text-anchor="middle" class="lp-text">sha256(card),</text>
  <text x="80" y="260" text-anchor="middle" class="lp-text">signer key, ts</text>

  <rect x="215" y="194" width="90" height="76" rx="4" class="lp"/>
  <text x="260" y="212" text-anchor="middle" class="lt" style="fill:var(--c-pink,#F472B6); font-weight:600">probe</text>
  <text x="260" y="226" text-anchor="middle" class="lp-text">result</text>
  <text x="260" y="246" text-anchor="middle" class="lp-text">probe id,</text>
  <text x="260" y="260" text-anchor="middle" class="lp-text">findings, ts</text>

  <rect x="335" y="194" width="90" height="76" rx="4" class="lp"/>
  <text x="380" y="212" text-anchor="middle" class="lt" style="fill:var(--c-pink,#F472B6); font-weight:600">card</text>
  <text x="380" y="226" text-anchor="middle" class="lp-text">publication</text>
  <text x="380" y="246" text-anchor="middle" class="lp-text">v2 of agent,</text>
  <text x="380" y="260" text-anchor="middle" class="lp-text">new signer key</text>

  <rect x="515" y="194" width="90" height="76" rx="4" class="lp"/>
  <text x="560" y="212" text-anchor="middle" class="lt" style="fill:var(--c-pink,#F472B6); font-weight:600">revocation</text>
  <text x="560" y="246" text-anchor="middle" class="lp-text">card hash,</text>
  <text x="560" y="260" text-anchor="middle" class="lp-text">reason, ts</text>

  <text x="320" y="298" text-anchor="middle" class="ll">LEAVES · ONE LOG ENTRY PER OBSERVABLE EVENT</text>
  <text x="320" y="328" text-anchor="middle" class="lt">Anyone can fetch an inclusion proof for any leaf and verify it</text>
  <text x="320" y="345" text-anchor="middle" class="lt">against the signed root. No operator can rewrite history undetected.</text>
</svg>

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](https://agenstry.com/blog/agent-capability-three-layers)
  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](https://github.com/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](https://agenstry.com/blog/erc-8004-three-registries-honesty)**
  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](https://github.com/modelcontextprotocol/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](https://docs.sigstore.dev/logging/overview/) follow a similar
pattern with OpenSSF backing. For the agent web, the equivalent
trusted-operator set has no obvious provider yet. The
[AAIF](https://agenstry.com/blog/aaif-membership-vs-protocol-convergence)
could run one. The [AGNTCY
project](https://agenstry.com/blog/agntcy-vs-aaif-foundation-bets)
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](https://agenstry.com/blog/mcp-spec-vs-probe-evidence):
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](https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-tree-certs/)
   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

- [RFC 6962: Certificate Transparency](https://www.rfc-editor.org/rfc/rfc6962.html) — IETF, accessed May 2026.
- [Sigstore Rekor](https://github.com/sigstore/rekor) — Software Supply Chain Transparency Log, accessed May 2026.
- [Rekor — Sigstore Documentation](https://docs.sigstore.dev/logging/overview/) — Sigstore, accessed May 2026.
- [Catching Malicious Package Releases with Rekor Transparency Log Monitoring](https://openssf.org/blog/2025/12/19/catching-malicious-package-releases-using-a-transparency-log/) — OpenSSF, December 19, 2025.
- [Google Develops Merkle Tree Certificates to Enable Quantum-Resistant HTTPS in Chrome](https://thehackernews.com/2026/03/google-develops-merkle-tree.html) — The Hacker News, March 2026.
- [draft-davidben-tls-merkle-tree-certs-10 — Merkle Tree Certificates](https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-tree-certs/) — IETF draft, accessed May 2026.
- [ERC-8004: Trustless Agents](https://eips.ethereum.org/EIPS/eip-8004) — Marco De Rossi et al., Ethereum Improvement Proposals, August 13, 2025.