Architecture

Checksum engine

The checksum engine is simply Auth51’s hashing infrastructure and is an important piece of code that has to run identically everywhere. The client computes an agent’s fingerprint at runtime, while the Authority independently recomputes it at registration (rejecting a submitted checksum that doesn’t match) and at mint, where it checks the presented fingerprint against the stored value. Since 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 unique. This includes its id, system prompt, model configuration and, the interfaces of its tools. Most of the work happens before the hash. First, inputs must be 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.

Versions

The Authority can compute and store five different checksum formats at registration. Mint accepts a match against any stored value, so older clients keep working. For new integrations, use v3 or v4 at runtime (depending on whether in-process tool interfaces are available) and v5 at registration (for the CI/CD path that seals the tool source).

v3In useIdentity-only
SHA3-512 over agent id, prompt, and config, with no tools. The default at runtime when tool interfaces aren’t available (provider-egress observation, prompt-only agents).
v4In useIdentity + in-process tools
Extends v3 with normalized interfaces of in-process tools (names, descriptions, parameter schemas). Used at runtime when the embed captures those tools. Detects a swapped tool, not only an edited prompt.
v5In useRegistration seal
Extends v4 with AST-normalized source for in-process tools. Computed at build/CI registration (auth51 register), stored as checksum_v5, and verified on read-back. Not used for wire-derived runtime matching; it is the strongest registration-time integrity check.

▶Legacy checksum versions (v1 and v2)

These are still computed and stored on every registration, and mint still accepts them, so agents registered under Patchet or earlier Auth51 releases aren’t orphaned. New work should not target them.

v1LegacyPatchet-compatible
SHA-256, bare hex, whitespace-collapsed prompt, no Unicode NFC folding. The registration ack still returns v1 for Patchet clients that echo it at mint. Legacy only.
v2LegacyFull-component (canonical stored)
SHA3-512, self-describing (sha3-512:…), over prompt, config, and tools, with Unicode NFC folding. Stored as the canonical checksum column and used for duplicate detection at registration. Superseded by v3+ for runtime identity.

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