Blog

Evidence Labels and an Externally-Anchored Audit Log

Two things shipped today, both about being honest under scrutiny: a factual evidence label on every agent, and a tamper-evident audit log of every change to an agent's record — with its integrity anchored to a public, third-party-verifiable repo.

Evidence labels — facts, not verdicts

Every agent record (GET /api/v1/agents/{air_id}) and trust score (/trust-score) now carries an evidence object with one of four labels: Verified, Attested, Self-declared, or Registered. These describe what evidence exists — Verified means a high verification score across ≥3 distinct WHOIS roots; Attested means some independent attestation below that bar; Self-declared means a score from self-reported data with no independent check; Registered is the anonymous baseline. They are deliberately not endorsements or rankings — just a mechanical classification, versioned (definition_version) and linked to its published criteria (criteria_url). The README badge now shows the label word by default; add ?format=score for the legacy numeric badge.

An externally-anchored audit log

Every registered, updated, deleted, and redacted event on an agent record is now written to an append-only, hash-linked log. Each entry chains prev_hash → entry_hash, and anyone can re-derive the hash from the published recipe to confirm the linkage — so accidental corruption or a partial edit is detectable. Read a single agent's history at GET /api/v1/agents/{air_id}/history.

The harder problem is the operator. A log the registry controls could, in principle, be rewritten by the registry. So every Sunday a cron publishes the chain's tip hash and entry count to a public, append-only repo — AgentIdentityRegistry/audit-anchors. GET /api/v1/audit/verify re-derives the live chain and cross-checks its tip against that latest external anchor; GET /api/v1/audit/anchor returns the anchor itself. We want to be precise about what this buys you: the log is tamper-evident against the operator back to the last weekly anchor. Between anchors it is not real-time-trustless — we're not claiming the log is immutable or that it can't be tampered with, only that any tampering before the most recent anchor is detectable by a third party.

Check it yourself: curl https://agentidentityregistry.org/api/v1/audit/verify, or read the endpoint reference on the /developers page.

June 2026: Attestations, AIR Verified, a Loop-Safe Trust Graph, the TypeScript SDK, and AIR Note

May was the developer surface. June was the thing it was all for: earned trust. Agents can now vouch for one another with cryptographically-signed attestations, an agent becomes AIR Verified only with endorsements from independent roots, and the whole trust graph is hardened against gaming. Plus a first-class TypeScript SDK on npm, and a name and a home for our messaging product — AIR Note.

Attestations + AIR Verified

Agents can now make signed attestations about other agents — the on-registry version of "I've worked with this one; it's legit." Each attestation is signed client-side with the attester's Ed25519 key (the registry never sees a private key) over the JCS-canonical payload, then submitted to POST /api/v1/agents/{air_id}/attestations. Six "Locks" gate whether a vouch counts toward Verified — live did:wba key binding, a distinct WHOIS root, attester tenure + trust thresholds, frozen weighting, a rate limit, and a public audit trail. An agent earns the AIR Verified badge only when its active attestations clear a threshold from ≥3 distinct WHOIS roots — so you can't manufacture trust by spinning up agents on a single domain.

A loop-safe trust graph

Two hardening passes made earned trust both real and hard to game. The peer-attestation component of the trust score is now derived from the actual attestation graph using weights frozen at issue time — so inflating one agent's score can't retroactively pump everyone it vouched for (no feedback loop), and a deleted or deactivated attester's vouch stops counting (the dead-vouch filter). And an external attester's vouch only counts if its live did:wba document still advertises the exact key AIR has on file — a fail-closed key-binding check. The graph itself is queryable: GET /api/v1/agents/{air_id}/graph (ego graph), /dependents, and /graph/stats.

TypeScript SDK — npm install agent-identity-registry

A first-class TypeScript/JavaScript SDK is now on npm — dual ESM + CommonJS, full type definitions, zero runtime dependencies — published with SLSA build provenance. It sits alongside the Python SDK, the MCP server, and the OpenAPI generators on the /developers page. Source: agent-identity-registry-typescript.

AIR Note — verified messaging for agents

The reference-implementation messaging product we mentioned in May (then working-named "BossClaw") now has a name and a home: AIR Note, at /note. It's cryptographically-signed, end-to-end-encrypted messaging for AI agents — your agent acts and speaks as you, provably, with every message bound to an AIR-verified did:wba identity. It's a working reference implementation today (an MCP server + the air-msg CLI + an air-rs Rust reference); the consumer experience is still in progress.

What's still being built

The behavioral trust component is still a flat placeholder until we have signed action-history data — so live scores top out around BBB today, and the A / AA / AAA grades are deliberately reserved for when that lands. The consumer AIR Note experience (one-tap web invite links, managed handles, a polished app) is in active development. As always, we'll post as it ships.

Try it now: pip install agent-identity-registry, npm install agent-identity-registry, or read the protocol at /specs/air/draft-1/v1.md.

May 2026: Python SDK, MCP Server, CLI, OpenAPI Spec, and a New Developer Surface

Quiet for a few weeks, busy underneath. Between May 15 and May 27 we shipped the complete developer surface for AIR — Python SDK on PyPI, MCP server on PyPI, a CLI tool, an OpenAPI 3.1 spec, a new /developers page, plus a major API sprint that landed did:wba support, public-key registration, and W3C DID documents. Here's what's new and where to find it.

API sprint (May 22–24) — eight steps + a bug fix

The registry API went from "basic CRUD" to "complete W3C-aligned trust infrastructure" in three days:

• did:wba support — Agents can register with a did:wba:example.com:agents:my-bot creator DID. AIR validates the format strictly (no IPv4 literals, no localhost) and performs best-effort resolution (3-second timeout, 1KB cap, no redirect-following).
• Public key registration — Optional public_key field (Ed25519, base64url, 32 bytes). Required when creator DID is a did:wba.
• Per-agent secrets — Every registration returns a 32-char agent_secret (shown once). Required to call PUT /agents/{air_id}. Stored as SHA-256 hash; compared in constant time.
• W3C DID document endpoint — GET /api/v1/agents/{air_id}/did-document returns the agent's full DID document with Ed25519VerificationKey2020 publicKeyMultibase. Cacheable for 5 minutes at the edge.
• AIR-minted did:wba — Agents without their own domain can register with just a public key. AIR mints did:wba:agentidentityregistry.org:agents:{air_id} for them and serves the DID document.

Plus a critical bug fix: BASE32 encoding had been using only 29 characters instead of the Crockford 32-char alphabet, producing "undefined" segments in roughly a third of new AIR IDs. Fixed and verified.

Python SDK — pip install agent-identity-registry

An async Python client covering all 11 endpoints. Pydantic v2 models field-mapped to the actual API JSON. A seven-class exception hierarchy that distinguishes AgentNotFoundError from RateLimitedError (with retry_after_seconds) from NetworkError and the rest. 53 tests behind it (47 unit, 6 live integration).

One-liner to try it:

$ pip install agent-identity-registry && air health

That installs the SDK and the air CLI: air list, air lookup AIR-XXXX-XXXX-XXXX, air score AIR-XXXX-XXXX-XXXX (with a bar chart of the five trust components), air did-doc, air check, air register. --json for scripting; --no-color when piping. Source: agent-identity-registry-python.

MCP server — pip install air-mcp-server

A Model Context Protocol server that drops AIR into any LLM client (Claude Code, Cursor, Codex, anything MCP-aware). Six read-only tools — air_health, air_list_agents, air_lookup_agent, air_trust_score, air_did_document, air_check_name. 27 tests cover registration, happy paths, structured-error returns for 404/429/5xx/network failures, env-var config.

One-line MCP config gets your LLM talking to AIR:

{ "mcpServers": { "air": { "command": "air-mcp-server" } } }

v0.1 is intentionally read-only — write operations (register, update) require an agent secret that would cross the LLM context, a sharper design decision deferred to v0.2. Source: air-mcp-server.

OpenAPI 3.1 spec — for every other language

The full API contract is now a 1,154-line OpenAPI 3.1 document served at /api/v1/openapi.yaml with Access-Control-Allow-Origin: *. Drop it into openapi-typescript, oapi-codegen (Go), openapi-generator-cli (Rust, Java, Kotlin, C#, PHP, Ruby, Swift, etc.) and generate a typed native client in seconds. Paste the URL into Swagger Editor or Redoc to browse it visually.

It validates as OpenAPI 3.1 both locally and after a round-trip through the live URL. The /developers page has install commands per language.

/developers — a real developer guide

A dedicated /developers subpage with quick start, full Python SDK + CLI + MCP install walkthroughs, OpenAPI generator examples for TS/Go/Rust, a REST API reference table, and a troubleshooting section. Replaces the previous placeholder section on the homepage that promised "SDKs coming soon" and showed a code sample with the wrong endpoints.

What's still being built

Plenty. The trust score model still has static placeholder values for the behavioral and peer-attestation components (no real history data yet). The MCP server is read-only. Standards engagement conversations (Paola, Taylor, Ben at SwarmSync, the W3C CG presentation) are in flight. BossClaw — the open-source reference-implementation agent that demonstrates the full AIR integration — is in active development in a separate repo. We'll post more as those land.

Try it now: View the developer guide or just pip install agent-identity-registry && air health in any terminal with Python 3.10+.

AIR Registry API Is Live

Today we're announcing the launch of the AIR Registry API — a working REST API for registering AI agents and querying trust scores. This is the first step from specification to implementation.

What's now available:

• Agent Registration — Register any AI agent and receive a unique AIR ID (format: AIR-XXXX-XXXX-XXXX)
• Trust Scoring — Each agent receives an initial trust score based on our five-component model (Provenance, Behavioral, Transparency, Security, Peer Attestations)
• Agent Lookup — Query any registered agent's identity passport and trust score breakdown
• Registration Form — A web-based form at /register with a live trust score preview as you fill in details

The API runs on Cloudflare Workers with a D1 database, deployed at the edge globally. It's free to use and the source code is fully open on GitHub.

Try it: Register an agent or look up an existing one.

Engaging with W3C, IETF, and DIF

We've submitted introductions to three major standards organizations working on adjacent problems:

• W3C AI Agent Protocol Community Group — Exploring how AIR's trust layer complements their agent discovery and communication protocols
• IETF AIMS / WIMSE Working Group — Discussing how AIR trust scoring layers on top of AIMS agent authentication
• Decentralized Identity Foundation (DIF) — Contributing to the Trusted AI Agents Working Group as a DID/VC-native implementation

This follows our public comment to NIST CAISI submitted on April 3. Our approach is to complement existing standards, not compete with them — AIR provides the trust verification layer, while these bodies define the communication and authentication layers.

NIST CAISI Public Comment Submitted

We submitted a detailed public comment to the National Institute of Standards and Technology (NIST) in response to their Concept Paper on AI Agent Identity and Authorization, part of the Consortium for the Advancement of Intelligent Systems (CAISI) initiative.

Our comment addresses gaps in current agent identity frameworks and proposes how a neutral, standards-based registry like AIR can help. The full specification and supporting materials are available in our GitHub repository.

AIR Identity Specification v0.1 Published

We've published the first draft of the AIR Identity Specification, covering:

• The AIR ID format — cryptographic identifiers using SHA-256 hashing and base32 encoding with CRC32 checksums
• Agent Identity Documents — JSON-LD structures linked to W3C Decentralized Identifiers
• Trust Score Methodology — a five-component, 0-1000 scoring model with letter grades (AAA through C)
• Verification protocols and credential formats based on W3C Verifiable Credentials

The specification is open for community review. Read it on GitHub and share feedback via Discussions.