Architecture

Checksum engine

The checksum engine is not a service. It is the one piece of code that has to run identically everywhere. The client computes an agent’s fingerprint at runtime; the Authority independently recomputes it at registration (rejecting a submitted checksum that doesn’t match) and, at mint, checks the presented fingerprint against that stored value. Because both sides run the same bytes, a client can prove “this is the registered, unmodified agent” without the agent ever declaring who it is.

What it hashes

The checksum is a one-way hash over what makes an agent that agent: its id, system prompt, model configuration, and, where included, the interfaces of its tools. Most of the work happens before the hash: inputs are put into a canonical form, so changes that don’t affect behavior (formatting, key order, framework wrappers) don’t move the fingerprint, while any change that does is always caught.

Figure 1. Identity inputs are canonicalized, then hashed once. The same logical agent yields the same checksum across frameworks and formatting.

The versions, precisely

You’ll see four checksum versions, and the Authority accepts the relevant one at mint:

v1, patchet-compatible. SHA-256, bare hex, whitespace-collapsed prompt with no Unicode NFC folding. Retained so agents registered under earlier releases aren’t orphaned.

v2, auth51 native. SHA3-512, self-describing (sha3-512:…), over prompt, config, and tools, with Unicode NFC folding.

v3, identity-only. SHA3-512 over id, prompt, and config, no tools. The baseline when tool interfaces aren’t available at the point of computation.

v4 extends v3 with the interfaces of the agent’s in-process tools (names, normalized signatures, and where configured, AST-normalized source). The strongest form: it detects a swapped tool, not only an edited prompt.

Watch out

This is a wire and registration contract. Changing the algorithm changes the fingerprint of every already-registered agent. That is a breaking change. It’s pinned to golden vectors; a single differing output byte is a release blocker, and a new behavior means a new version, never an edit to an existing one.

▶How the same bytes run in two places

The hashing layer is shared verbatim between the client and the Authority. The client’s copy is byte-identical to the Authority’s, and parity is proven by a conformance test that pins both to the same golden vectors. Only the extraction layer differs: turning a live agent (in LangGraph, CrewAI, or a hand-rolled loop) into the canonical identity inputs is framework-aware and client-side; the hashing over those inputs is not.

Canonicalization is what makes that portable: tool signatures are stripped of framework wrapper parameters, source is normalized through the AST (docstrings and comments removed), and structured inputs are serialized with sorted keys. An independent Go implementation even uses a different hash (BLAKE2b-256). The protocol only requires a collision-resistant hash, which is why the spec keeps the primitive separate from the logic. draft-goswami-agentic-jwt §5

Keep reading