What Is an AUID? The Cryptographic Identity Standard for AI Agents

AI agents have no persistent, portable identity. The AUID — Agent Unique Identifier — is the cryptographic identity standard that changes that. Here is how it works, why ULID was chosen over UUID, and why non-transferable identity is the right foundation for agent trust.

By Leonidas Esquire Williamson — March 17, 2026

The Identity Problem at the Heart of the Agentic Economy

Every trust system begins with identity. Before you can assess reputation, extend credit, or grant access, you need to know — with confidence — who or what you are dealing with. For humans and organizations, this problem has been solved, imperfectly but adequately, by a patchwork of government-issued identifiers, domain registrations, and cryptographic certificates. For AI agents, it has not been solved at all.

The gap is structural. An AI agent is not a legal entity. It has no passport, no tax identification number, no domain registration that persists across deployments. Two agents running on the same underlying model — say, GPT-4o or Claude 3.5 Sonnet — can have completely different system prompts, tool configurations, permission sets, and behavioral histories. From the outside, they are indistinguishable. From the inside, they may be radically different actors.

This is the identity problem that the Agent Unique Identifier (AUID) is designed to solve.

---

What Is an AUID?

An AUID is a structured, cryptographically anchored identifier assigned to every agent registered in the AXIS system. It is the foundational primitive on which everything else in AXIS is built — the T-Score, the C-Score, the behavioral event log, the public trust profile. Without a stable, verifiable identity, none of these can exist.

The design goals of the AUID are:

Persistence. The AUID does not change when the agent is redeployed, updated, or migrated to a new infrastructure. It is tied to the agent as a deployed, configured instance — not to the underlying model, the hosting provider, or the operator's account.

Portability. The AUID is a self-describing string that any system can parse, validate, and query without prior knowledge of the issuing registry. It carries its own metadata — registry origin, agent class, issuance timestamp — in a human-readable format.

Verifiability. The AUID includes a checksum that allows any system to verify its structural integrity without a network call. Full cryptographic verification — confirming that the AUID was issued by the claimed registry and has not been tampered with — requires a query to the AXIS API.

Human-readability. Unlike UUID v4 (which is a random 128-bit string with no semantic content) or opaque database primary keys, the AUID is designed to be readable by a human engineer. You can look at an AUID and immediately understand its registry origin, agent class, and approximate issuance time.

---

The AUID Format

Every AUID follows this canonical five-component format:

```

axis:{registry_domain}:{agent_class}:{ulid}:{checksum}

```

A concrete example:

```

axis:axis.registry:enterprise:01hx7k2m3n4p5q6r7s8t9u0v1w:a3f7

```

Each component carries specific semantic meaning:

---

Why ULID Instead of UUID?

The choice of ULID over UUID v4 for the identifier component is deliberate and worth explaining, because it reflects a design philosophy that runs throughout AXIS: identifiers should carry information, not just uniqueness.

UUID v4 is a random 128-bit string. It is collision-resistant, but it is also completely opaque. You cannot sort UUIDs by creation time, you cannot tell from a UUID when it was issued, and you cannot use UUIDs to answer questions like "show me all agents registered in the last 30 days" without a separate timestamp column.

ULID encodes a 48-bit millisecond timestamp in the first 10 characters, followed by 80 bits of randomness in the remaining 16 characters. This means:

For a system that will eventually contain millions of registered agents, the operational benefits of time-sortable identifiers are significant.

---

The Five Agent Classes

Every AUID encodes the agent's declared class, which determines its default permissions, trust tier starting point, and the behavioral event types that are relevant to its operation.

The agent class is declared at registration time and is part of the AUID. It cannot be changed after issuance — if an agent's operational context changes significantly, the correct approach is to register a new agent with the appropriate class and migrate its behavioral history.

---

Agent Identity vs. Model Identity: The Critical Distinction

One of the most important conceptual contributions of the AUID system is the explicit separation of agent identity from model identity.

A foundation model — GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro, Llama 3 — is an engine. It can power thousands of distinct deployed agents, each with different system prompts, tool configurations, permission sets, and operational histories. The model is the capability substrate. The agent is the deployed, configured, governed instance.

AXIS tracks the agent, not the model. This has several important consequences:

Trust is non-transferable. A high T-Score earned by one agent running on GPT-4o does not transfer to a different agent running on the same model. The score reflects the specific agent's behavioral history, not the general capabilities of the underlying model.

Retraining does not reset identity. If an agent's underlying model is updated or fine-tuned, its AUID remains the same. The behavioral history accumulated before the update is preserved. The T-Score may change as new behavioral events are recorded under the updated model, but the identity is continuous.

Cloning creates a new identity. If an operator creates a second agent by copying the system prompt and configuration of an existing agent, the new agent receives a new AUID and starts with a fresh behavioral history. It cannot inherit the original agent's T-Score or C-Score.

This design prevents a class of reputation gaming that would otherwise be straightforward: building a high-reputation agent, cloning it, and using the clone to exploit the reputation of the original.

---

AUID Verification: Structural vs. Cryptographic

AXIS supports two levels of AUID verification, designed for different use cases:

Structural verification checks that the AUID conforms to the expected format — five colon-separated components, a valid agent class, a 26-character ULID, and a matching 4-character checksum. This can be done entirely client-side without a network call, and it is sufficient for filtering out malformed or spoofed identifiers.

Cryptographic verification confirms that the AUID was issued by the claimed registry, that the agent is currently active, and that the AUID has not been revoked or transferred. This requires a query to the AXIS API:

```bash

curl "https://axistrust.io/api/trpc/agents.getByAuid?batch=1" \

--get \

--data-urlencode 'input={"0":{"json":{"auid":"axis:axis.registry:enterprise:01hx7k2m3n4p5q6r7s8t9u0v1w:a3f7"}}}' \

-H "Content-Type: application/json"

```

The response includes the agent's full public trust profile: name, class, status, T-Score, trust tier, C-Score, credit tier, registration date, and the most recent behavioral event timestamp.

---

The AUID as the Root of the Trust Graph

The AUID is not just an identifier — it is the root of the agent's entire trust graph. Every behavioral event recorded in AXIS is anchored to an AUID. Every T-Score component score is computed from events anchored to an AUID. Every C-Score rating is derived from the T-Score and economic events anchored to an AUID.

This means that the AUID is the single point of truth for everything AXIS knows about an agent. Revoke an AUID, and the agent's entire trust history becomes inaccessible. Transfer an AUID (which AXIS does not permit), and you transfer the agent's entire reputation.

The non-transferability of AUIDs is a deliberate design choice. It prevents reputation laundering — the practice of building a high-reputation identity and then selling or transferring it to a different operator. In AXIS, reputation is earned by the specific agent that holds the AUID, and it cannot be sold.

---

Registering an Agent and Obtaining an AUID

Obtaining an AUID requires registering an agent in the AXIS system. Registration is free, takes under 60 seconds, and requires no technical integration. The process:

The AUID is displayed on the agent's dashboard card and can be copied with a single click. It is also queryable via the public API immediately after registration.

---

The AUID in the Broader AXIS Trust Stack

The AUID is the foundation, but it is only the first layer of the AXIS trust stack. Once an agent has an AUID, two additional trust signals become available:

The T-Score is the behavioral reputation score — a 0–1000 composite computed from 11 weighted dimensions including reliability, accuracy, security posture, and adversarial resistance. It maps to five trust tiers from T1 Unverified to T5 Sovereign. See the [AXIS T-Score reference page](/trust-score) for a full explanation.

The C-Score is the economic reliability rating — a 0–1000 score that maps to letter grades from AAA (Prime) to D (Default). It determines transaction limits, staking requirements, and insurance coverage for agent-initiated financial actions. See the [AXIS C-Score reference page](/credit-score) for a full explanation.

Together, the AUID, T-Score, and C-Score form the complete AXIS trust profile: a verified identity, a behavioral reputation, and an economic reliability rating — the three primitives that any agent needs to participate in the agentic economy with accountability.

---

Why This Matters: The Infrastructure Argument

The AUID is infrastructure, not a feature. The distinction matters.

A feature is something you build into your product to differentiate it. Infrastructure is something the entire ecosystem shares, so that every participant benefits from the network effects of every other participant's contribution.

DNS is infrastructure. TLS is infrastructure. OAuth is infrastructure. None of these were built by a single company to serve its own interests — they were built as shared, open standards that any system could implement and any user could rely on.

The AUID is designed to be infrastructure in the same sense. It is an open, queryable, portable identifier that any platform can integrate, any developer can verify, and any agent can carry across the systems it interacts with. The goal is not to lock agents into AXIS — it is to give the agentic economy the identity layer it currently lacks, so that trust can be built on a foundation that is shared rather than siloed.

The agentic economy is growing. The infrastructure it needs is not yet there. The AUID is where that infrastructure starts.