Concepts
Agent identity
To a receiving service, requests made with the same bearer token have the same identity. A shopping agent, an unrelated script, and a replayed request can all present the same authorization header. The service cannot distinguish which agent produced the request or determine whether that agent still matches the version that was approved.
Auth51 adds that distinction through an agent fingerprint.
Identity is what the agent is, not a secret it holds
API keys and passwords are credentials an agent has. They can be copied, leaked, or passed to another process. The credential itself does not indicate whether the code or configuration using it has changed.
An Auth51 agent identity is instead derived from the properties that define the agent: its system prompt, the tools it can call, and its model configuration. Auth51 calls the resulting hash a checksum. Editing the prompt or adding a tool changes that checksum. Rather than presenting a stored identity value, the runtime recomputes the identity from the agent that is running.
As a result, an agent with an edited prompt or a replaced tool no longer matches its registered fingerprint. It is treated as a different identity rather than inheriting the trust assigned to the registered agent.
How the fingerprint is computed
The checksum is a one-way SHA3-512 hash over the agent’s identity inputs. Before hashing, Auth51 converts those inputs into a canonical form. Changes that do not affect behavior, such as formatting or key order, therefore leave the identity unchanged, while behavioral changes produce a different checksum.
▶What canonicalization does, and why it matters across frameworks
Without normalization, the same logical tool could produce different fingerprints in LangChain, CrewAI, or a custom loop because of wrapper parameters, whitespace, and key ordering. Auth51 normalizes these differences so the identity represents behavior rather than framework-specific packaging.
Framework-injected wrapper parameters, including *args and **kwargs catch-alls, are removed from tool signatures before hashing. The same logical tool can therefore retain the same identity across wrappers.
When tool source code is included, it is normalized through the Abstract Syntax Tree. Auth51 parses the source, removes comments and docstrings that are captured separately, and then converts the AST back to a canonical form. Reformatting does not change the checksum, while changing the logic does.
Structured inputs, including configuration and tool metadata, are serialized with sorted keys. Map ordering therefore cannot produce different hashes for equivalent content.
draft-goswami-agentic-jwt §5 specifies the normalization rules in full.
How Auth51 identifies the running agent
Your application does not call identify("shopping-agent"). The client observes the agent’s model request, reads the system prompt from that request, and recomputes the checksum against the agents registered in your organization. A match identifies the agent and verifies that it has not changed, without relying on a self-declared name.
A request with no matching checksum represents an unregistered agent. Auth51 sends that identity to Discovery for review rather than treating it as a registered agent.
The checksum, in four flavors
Checksum versions are identified as v1 through v4. v3 hashes the agent id, system prompt, and model configuration. v4 also includes the interfaces of its in-process tools. v1 and v2 remain available for backward compatibility. The client and the Authority agree on the format, so applications rarely need to select it directly.
▶Exactly what goes into each version
All four versions use SHA3-512 over canonicalized input. They differ in the fields included in that input.
v1 and v2 are legacy identity hashes retained for agents registered under earlier releases. The Authority continues to validate them so those registrations remain usable after an upgrade.
v3 is identity-only: agent id, system prompt, and model configuration. It is used when tool interfaces are not available at the point of computation.
v4 extends v3 with the interfaces of the agent’s in-process tools, including names, normalized signatures, and, where configured, AST-normalized source. It can detect a replaced tool as well as an edited prompt.
During registration, the Authority recomputes the checksum rather than trusting the submitted value. Registration succeeds only when the client and server independently produce the same fingerprint. Registering the same agent id with a different checksum creates a new versioned record, and the latest record is used for validation. draft-goswami-agentic-jwt §5.2
Where identity shows up
Identity is used in two places. At the model call, it identifies the running agent and supports Discovery when no registered match exists. For each governed action, it is also included in the intent token so the resource server can verify which agent acted before processing the request.