Concepts

Agent identity

Every request an agent makes looks the same to the service on the other end. A shopping agent, a stray script, a token replayed from last week — same bearer header, same shape. The service can’t tell them apart, so it can’t ask the one question that matters: who is really calling, and are they still who they were?

auth51 answers that with a fingerprint.

Identity is what the agent is, not a secret it holds

API keys and passwords are things an agent has. They get copied, leaked, or handed to the wrong process, and the credential itself tells you nothing about whether the code behind it changed.

An auth51 agent’s identity works the other way around. It’s a hash of the things that make the agent that agent: its system prompt, the tools it can call, and its model configuration. We call that hash a checksum. Edit the prompt or add a tool, and the checksum moves with it. Nothing is stored inside the agent and handed over on request — the identity is recomputed from what the agent actually is, every time it runs.

That has a useful side effect. An agent whose prompt was quietly edited, or that had a tool swapped in, no longer matches its registered fingerprint. It doesn’t inherit the trust you gave the original. It shows up as something new.

Background

Why OAuth needs this at all

OAuth 2.0 (RFC 6749) was built on an assumption: the client application faithfully represents the user’s intent. You authorize an app once, it gets a token, and every call it makes with that token is taken to be something you asked for. For a web app with fixed code, that holds.

Autonomous agents break the assumption. They generate their own plans, spawn sub-agents, and decide which tools to call without a human in the loop — and their behavior is driven by a prompt that can be edited, injected into, or swapped. The token still says “this app, acting for this user,” but the thing holding the token is no longer fixed. The draft calls this gap the intent-execution separation problem. A checksum closes it by making the running agent’s exact identity part of every authorization decision.

How the fingerprint is computed

The checksum is a one-way hash (SHA3-512) over the agent’s identity inputs. The important design choice is what happens before the hash: the inputs are put into a canonical form first, so that changes which don’t affect behavior don’t change the identity, 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.

▶What canonicalization does — and why it matters across frameworks

Without normalization, the same logical tool would fingerprint differently in LangChain, CrewAI, or a hand-rolled loop — different wrapper parameters, different whitespace, different key ordering. The checksum would be brittle and framework-specific. auth51 normalizes so the identity tracks meaning, not packaging:

Tool signatures are stripped of framework wrapper parameters (the *args/**kwargs catch-alls a framework injects) before hashing, so a tool means the same thing regardless of who wraps it.

Tool source code, when included, is normalized through the Abstract Syntax Tree: parse to AST, remove docstrings (captured separately) and comments, then unparse to a canonical form. Reformatting the code doesn’t move the checksum; changing the logic always does.

Structured inputs (config, tool metadata) are serialized with sorted keys, so map ordering can’t produce two different hashes for the same content.

draft-goswami-agentic-jwt §5 specifies the normalization rules in full.

You don’t tell auth51 which agent is running

Here’s the part people don’t expect. You never call identify("shopping-agent"). The client watches your agent talk to its model, reads the system prompt off that request, and recomputes the checksum against the agents your org has registered. A match identifies the agent and proves it hasn’t changed, in a single step. There’s no self-declaration for an impostor to fake.

No match is information too. It means an agent is running that you haven’t registered — worth a look. auth51 surfaces it for you to review instead of trusting it quietly. That’s what Discovery is for.

The checksum, in four flavors

You’ll see checksum versions referenced as v1 through v4. The short version: v3 hashes the agent’s identity — its id, prompt, and config; v4 also folds in the interface of its in-process tools. v1 and v2 exist for backward compatibility. The client and the authority agree on which format to use, so you rarely touch this directly.

▶Exactly what goes into each version

All four are SHA3-512 over a canonicalized input; they differ in what that input includes.

v1 / v2 — legacy identity hashes retained for compatibility with agents registered under earlier releases. The authority still validates them so an upgrade never orphans a registered agent.

v3 — identity-only: agent id, system prompt, and model configuration. This is the baseline used when tool interfaces aren’t available at the point of computation.

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

When an agent registers, the authority recomputes the checksum itself rather than trusting the one submitted — client and server independently arrive at the same fingerprint, or registration fails. Re-registering the same agent id with a different checksum creates a new, versioned record; the latest is used for validation. draft-goswami-agentic-jwt §5.2

Where identity shows up

In two places. At the model call, to work out which agent is running — that’s Discovery. And on every governed action, folded into the intent token so the resource server can check who acted before it does the work — that’s intent tokens, next.

Keep reading