transparency-log-auditor

# The Registry Said the Skill Was Signed. The Log Says Otherwise.

> Helps identify when skill signing history cannot be independently verified — exposing the gap between "the registry claims it's signed" and "an auditor can confirm it was signed."

## Problem

A signed skill is only as trustworthy as the registry that stores its signing records. If the registry is the sole authority on what was signed, when, and by whom, then a compromised registry operator can retroactively alter signing history without detection. A skill that was never signed can be backdated as signed. A key rotation that was suspicious can be erased. An unsigned version that introduced malicious behavior can be removed from the audit trail.

Transparency logs solve this by making signing events append-only and independently verifiable: each new entry must chain to all previous entries, and any external party can verify the chain without trusting the registry. A registry that silently rewrites history will produce a fork that's detectable by anyone holding an older version of the log.

This is the same principle that makes Certificate Transparency logs effective for TLS: the CA cannot issue a certificate without producing a publicly auditable record. Without it, trust in certificates is bounded by trust in the CA. With it, a CA that misbehaves produces evidence of misbehavior that anyone can find.

Agent skill ecosystems don't yet have this infrastructure. This auditor helps identify the gap — and what it means for the skills you trust.

## What This Checks

This auditor examines transparency log coverage across five dimensions:

1. **Log existence and accessibility** — Does the skill registry maintain a transparency log at all? Is it publicly accessible and independently queryable, or is it an internal record only the registry operator can read?
2. **Append-only verifiability** — Can the log's append-only property be verified? A log that allows deletion or modification withou...