What Is Agentic AI Identity and Why Every Agent Needs ERC-8004

Most developers discover this at the worst possible moment: an AI agent that can act but cannot prove who it is will eventually do something it shouldn't, and you'll have no clean way to trace it, reverse it, or explain it to anyone.

We've spent previous posts covering what separates an agent from an assistant, the four powers any agent needs to operate on-chain, and the accountability gap that opens when an autonomous agent touches on-chain state and something goes wrong.

This post is about power number one: identity.

Not because it's the most exciting primitive: wallets and payments grab more developer attention, and rightly so. But identity is the load-bearing wall. Get it wrong and the whole structure is compromised before a single transaction fires.

According to McKinsey's State of AI 2025, 23% of organizations are already scaling an agentic AI system somewhere in the enterprise, and another 39% are experimenting with agents. Every one of those agents has the same problem: no standard way to prove who it is, who authorized it, or what it's allowed to do. That's the gap agentic identity infrastructure exists to close.

The short version: An agent without verifiable identity is just a process with a private key. Agentic identity turns that process into an accountable, auditable actor, one that can be authorized, rate-limited, suspended, and traced. ERC-8004 is the on-chain standard that makes that possible. The @abstraxn/agent-kit SDK makes it three function calls.

Why AI Agents Need On-Chain Identity

Most teams building AI agents in 2025 solved identity the same way: they didn't.

An agent got a UUID in a Postgres table, an API key for their backend, and access to a funded EOA. That was the identity layer. It worked fine, until the agent needed to interact with a protocol that had no idea who it was. Until a user wanted to verify which agent had authorized a spend. Until a compliance team asked for an audit trail and got a log file that anyone could have edited.

The problem isn't lazy developers. It's that the tooling for agentic identity didn't exist in a form that fit the agent lifecycle. Ethereum account addresses are cryptographic but carry no semantic meaning. DIDs (Decentralized Identifiers) are semantically rich but too heavyweight for most agent deployments. ENS names are human-readable but not machine-processable in the way an authorization system needs.

None of these were built for the specific problem: an autonomous, non-human actor that operates on behalf of a human user, across multiple chains, over an extended period, with programmable spend authority.

That gap is what ERC-8004 fills.

What ERC-8004 Actually Is

ERC-8004, titled "Trustless Agents", is a draft Ethereum standard for discovering AI agents and establishing trust in them across organizational boundaries. Not for people, not for generic smart contracts, specifically for agents.

ERC-8004 defines three registries. The Identity Registry gives every agent an on-chain identity. The Reputation Registry records feedback from the clients an agent has worked for. The Validation Registry records independent checks of an agent's work.

This post is about the first. The Identity Registry is an ERC-721 contract: each registered agent is a token, so it can be owned, transferred, and browsed like any other NFT. Each registration has three parts:

The agentId, the token ID the registry assigns when the agent is registered.

The token's owner: the account that owns the agent and can transfer it or delegate management to operators. This is the standard's on-chain accountability link. If an agent acts, you can query the registry and find the account that owns it.

The agentURI, which resolves to the agent's registration file (an "agent card"). The file lists the agent's name, description, and service endpoints (such as an MCP or A2A endpoint), the trust models it supports, and an active flag.

The chain, the registry contract, and the token ID together identify the agent globally. The Abstraxn Agent Kit returns them as a single canonical agentIdentity string:

eip155:11155111:0x8004A818BFB912233c491871b3d84c89A494BD9e:42

Four segments. Namespace and chain ID. Registry contract. Token ID. Machine-readable. Verifiable without trusting any off-chain source.

The Agent Kit also takes a userIdentity for each agent: the identifier of the user or organization the agent acts for in your application. That field is an Abstraxn Agent Kit convention, not part of the ERC-8004 standard. It lets your backend link an agent to the person it works for, while the standard's own on-chain link is the token owner.

This isn't a signature scheme or a session token. It's an on-chain record that this agent exists, which account owns it, and where its registration file lives. Any smart contract, any API, any MCP tool that wants to authorize this agent can verify that record against the chain.

ERC-8004 turns an EVM address into a named, accountable actor, and puts that record somewhere every change leaves an on-chain trail.

ERC-8004 vs DID vs ENS vs JWT: Which Identity Approach Is Right for Your Agent?

Here's how the main approaches compare:

DIDs are the most complete identity model but require significant infrastructure to operate correctly. ENS is human-readable but has no semantic concept of an agent or its operator. JWTs are easy but ephemeral and off-chain: any verifying party has to trust your token issuer. ERC-8004 is purpose-built for an autonomous agent acting on behalf of a human, with minimal implementation overhead and durable on-chain verification.

For agentic deployments where agents touch real value, the operator link matters most. An on-chain record that ties an agent to the account that owns it gives an auditor who wasn't in the room when the agent was created something to check without trusting your database.

The Difference Between an Address and an Identity

An EVM address is a public key hash. It tells you that someone with the corresponding private key can sign transactions from that address. It says nothing about who that someone is, what they're authorized to do, or who they answer to.

Think of it this way: a car has a VIN. That number is unique and traceable, but if you find a car parked somewhere, the VIN doesn't tell you who drove it there, whether they were authorized to be there, or who owns it right now. You need the registration. The registration links the physical object to a named owner in a system with enforcement teeth.

An EVM address is the VIN. ERC-8004 is the registration.

The practical consequence: protocols that want to authorize specific agents can't do it by address alone without building and maintaining their own off-chain registry. With ERC-8004, they query a standard contract on the chain and get a structured result back. The authorization logic is composable.

For developers building multi-tenant agent platforms, where one application might spin up hundreds of agents, each acting on behalf of a different user, this distinction separates an audit trail that means something from a list of addresses that mean nothing without your private database.

How to Register AI Agent Identity On-Chain: Two Paths

The @abstraxn/agent-kit SDK gives you two paths to ERC-8004 registration, corresponding to two different trust models.

Server wallet mode is the default. Abstraxn provisions a smart account for the agent, one you don't hold the private key to directly. The access key is a P-256 credential that authenticates your backend to Abstraxn's signing service, which signs transactions on behalf of the wallet. When you register the agent's identity, Abstraxn's backend handles the signing internally.

import { AgentKitClient } from '@abstraxn/agent-kit';
 
const agentKit = new AgentKitClient({
  apiKey: process.env.ABSTRAXN_API_KEY!,
  wallet: 'server',
});
 
const { agent, wallet } = await agentKit.createAgent({
  name: 'Trading Assistant',
  description: 'AI agent that executes trades within spend policy',
  userIdentity: 'user-123@example.com',
});
 
// Fund the wallet on the target chain first.
// Then register its identity on-chain.
const identity = await agentKit.registerAgentIdentity({
  agentId: agent.id,
  userIdentity: 'user-123@example.com',
  accessKey: wallet.accessKey,        // store this; it cannot be retrieved again
  organizationId: wallet.organizationId,
  evmAddress: wallet.evmAddress,
  chainId: 11155111,                  // Sepolia
});
 
console.log(identity.registration.agentIdentity);
// eip155:11155111:0x8004A818BFB912233c491871b3d84c89A494BD9e:42

One call after wallet creation. The SDK handles gas estimation, transaction construction, and submission. The identity is on-chain. Your backend stores the agentIdentity string and uses it for authorization from that point forward.

External wallet mode is the path for teams that bring their own key infrastructure: existing multisigs, hardware security modules, user-owned wallets via MetaMask. You provide the address and the signer. Registration is a three-step flow: prepare, sign, confirm.

import { createWalletClient, http } from 'viem';
import { privateKeyToAccount } from 'viem/accounts';
import { sepolia } from 'viem/chains';
 
const { agent } = await agentKit.createAgent({
  wallet: 'external',
  evmAddress: process.env.DEV_EVM_ADDRESS!,
  name: 'My Agent',
  description: '...',
  userIdentity: 'user@example.com',
});
 
const identity = await agentKit.registerAgentIdentityExternal({
  agentId: agent.id,
  evmAddress: process.env.DEV_EVM_ADDRESS!,
  chainId: 11155111,
  signTransaction: async ({ prepare, fromAddress }) => {
    const account = privateKeyToAccount(process.env.DEV_PRIVATE_KEY as `0x${string}`);
    const walletClient = createWalletClient({
      account,
      chain: sepolia,
      transport: http(prepare.rpcUrl),
    });
 
    return walletClient.sendTransaction({
      account: fromAddress,
      chain: sepolia,
      to: prepare.registerCall.to as `0x${string}`,
      data: prepare.registerCall.data,
      value: BigInt(prepare.registerCall.value || '0'),
    });
  },
});

You pass in a signTransaction function that receives the prepared calldata and fires it with whatever signing stack you already have. The SDK calls your function, waits for the hash, and confirms the registration against the chain.

Both paths produce the same output: a canonical agentIdentity string, verifiable on-chain, which your backend links to the agent's userIdentity. The difference is who holds the keys.

The registration flow

From agent creation to on-chain verification, same sequence for server and external wallets:

Steps 1 to 3 run once at deployment. Step 6 runs on every authorization check that needs on-chain identity.

The Security Questions That Actually Matter

There's a question that comes up every time I explain this at a technical level, and it's a good one:

"If the registration is on-chain and public, can't someone else register my agent before I do?"

Not in a way that claims it. Registering mints a new token owned by whoever calls the registry, so another party can create their own agent record but cannot make your address its owner. What they can do is copy your agent's name or endpoints into their own registration file. That's why counterparties should verify the agentId and the token owner, not the display name. ERC-8004 also defines an optional endpoint domain verification: an agent proves it controls an HTTPS endpoint by publishing a matching registration at /.well-known/agent-registration.json on that domain.

"What happens if someone registers an address that looks like mine, or claims the same userIdentity string?"

The standard doesn't limit how many times an address registers: every registration mints a new token with a new agentId. Agent Kit adds its own rule on top: each agent registers once per chain. The userIdentity is an Agent Kit field your backend uses, not part of the standard, and it isn't required to be unique, because the same person might operate multiple agents. The canonical identifier is the agentIdentity string, which encodes the registry contract address and the token ID together. Two registrations will never produce the same agentIdentity, even if someone uses the same userIdentity string.

"My agent operates on three chains. Do I need three registrations?"

Yes. Identity is per-chain. An agent's agentIdentity on Sepolia is a different string from its identity on Polygon Amoy, because the chain ID is part of the string and each chain has its own registry deployment (even where the contract address is the same). This is intentional. An authorization system on Polygon shouldn't have to trust a contract on Sepolia to validate an agent. On-chain verification is local to the chain where the action is happening.

Agentic AI Security: Why Identity Is the First Primitive, Not the Last

Most teams treat identity as a compliance nice-to-have. It's actually a security primitive, and the one that makes every other control meaningful.

Consider what happens when an agent gets compromised. The attacker now controls an EVM address that can sign transactions. Without an on-chain identity record, you have two problems: you don't know which agent was compromised (just an address), and you have no durable revocation signal: you can rotate the key, but anything already authorized by that address may still honor it.

With ERC-8004, the incident response story is different. The agentIdentity is the reference point. You revoke its access key and API key. You update your interaction policies to block that agentId. Under the standard, the owner can also mark the agent inactive in its registration file, so any downstream system that reads it can treat that identity as suspended. The on-chain record remains as the audit artifact showing when the agent was registered and who owned it.

Three security controls ERC-8004 enables that you can't get from an address alone:

Audit trail with chain anchor. The on-chain registration is the timestamp and the proof. Any action an agent took can be correlated with its registration record: chain, registry, owner, timestamp. That record can't be quietly rewritten.

Authorization that doesn't require trusting your backend. An MCP tool provider or smart contract can verify an agent's identity against the IdentityRegistry without calling Abstraxn's API. This matters when your infrastructure is under load, down for maintenance, or mid-key-rotation.

Per-chain policy enforcement with identity context. Interaction policies, contract whitelists, recipient blacklists, native amount limits, are enforced against the agent's identity. When a policy violation fires, the violation record includes the agentId, which maps to the on-chain agentIdentity. Security teams can trace any policy event to a registered, named actor.

The agentic AI security pattern at Abstraxn is built on this: identity first, policy on top. The enforcement is only as good as the identity layer beneath it.

Why This Becomes Expensive to Ignore

The costs of skipping agentic identity show up in three concrete places.

Authorization becomes bottlenecked at your backend. Without on-chain identity, every external protocol or paid MCP tool that wants to verify your agent has to trust a signed JWT from your backend. That's fine until your backend is down, rate-limited, or compromised. With on-chain identity, the verification is trustless: any party can check the IdentityRegistry directly, without touching your infrastructure.

Compliance conversations get expensive. If you're building for enterprise buyers (and increasingly, agent infrastructure vendors are), the first question from any legal or security team is: "Can you show me every action that agent took and who authorized it?" With address-only identity, that answer is a log export from your database: a mutable document. With ERC-8004 registration, the link between agent and owner is recorded on-chain, and every change to it leaves a trail. The audit trail has a chain anchor.

Multi-agent coordination falls apart without it. Agents are starting to call other agents. An orchestration agent hands a task to a specialized sub-agent, which calls a payment API, which routes through an MCP tool. At each hop, the question is the same: is this actor authorized to do this? Without a standard identity layer, each handoff requires a bespoke trust check. With ERC-8004, any agent in the chain can verify any other agent's identity and operator against the registry, without side-channel communication.

Gas Costs by Network

Registration costs one write to the IdentityRegistry contract. Indicative costs at moderate gas prices:

The SDK's prepareAgentIdentity call returns estimated gas before submission. Add a gas check to your deployment script, registration failures due to insufficient gas are the most common source of confusing errors in first-time deployments.

How Identity Connects to the Other Three Powers

Identity doesn't operate in isolation. In the four powers framing, it's power number one, and the precondition for the other three working correctly.

Wallet is authenticated by identity. In Agent Kit, the userIdentity field on a server wallet ties the wallet's spend authority to a specific operator in your application. When you update a spend policy, you're setting a budget tied to that agent identity. If two agents share an address, which happens when someone reuses keys carelessly, the policy system can't distinguish them.

Payments via x402 payment rails for agents don't require ERC-8004: any client that can sign the payment can pay. Identity is an optional, separate layer on top. A tool provider that wants to restrict who can call its endpoints can check the caller's registered identity as well as taking payment. Without ERC-8004, "which agents" reduces to "which API keys", a less durable trust anchor than a verifiable on-chain registration.

Policy enforcement at the interaction layer (contract whitelists, recipient blacklists, native amount limits) is keyed to agent IDs in the backend. Those agent IDs map to identities. An interaction policy that blocks an agent from sending more than 0.5 ETH to an unknown address is only meaningful if "this agent" is unambiguously defined. The on-chain identity record is what makes that mapping durable across key rotations, session resets, and infrastructure migrations.

You can build an agent without ERC-8004 registration. Many teams do. But every time they need to answer "which agent did this, and who authorized it," they're reconstructing the answer from mutable off-chain sources. On-chain identity makes that question answerable in a way that doesn't rely on trusting any single party's records.

Three Ways Teams Get This Wrong

1. Treating identity as a post-deployment concern.

The most common mistake: spin up the agent, wire it to a funded wallet, ship it, and plan to "add proper identity later." Later never comes, because the agent is already in production and adding identity registration now requires a migration, a gas spend, and a coordination window. Register identity at agent creation time, in the same deployment step. The SDK flow is designed for this: createAgent gives you the wallet, registerAgentIdentity is the next call.

2. Storing the agentIdentity string as a display field.

The agentIdentity string, eip155:11155111:0x8004..., is not a label. It's the canonical, verifiable identifier for that agent on that chain. It belongs in your authorization logic, your audit logs, your policy configuration, and any inter-agent communication where trust verification matters. Teams that store it as a metadata field and continue using their internal UUID as the real identifier are missing half the value of the standard.

3. Skipping gas funding before registration.

This is the one that fails silently in the worst way. The registerAgentIdentity call submits an on-chain transaction. If the wallet has no native gas on the target chain, the call will fail with a generic error that looks like an SDK or configuration problem. Fund the wallet first, then register. Add a gas check to your deployment checklist.

So, What Is Agentic AI Identity and Why Does Every Agent Need It?

Agent identity is the mapping between a cryptographic address and an accountable actor. It's the answer to "who is this, and who is responsible for it", in a form any on-chain system can verify without trusting your backend. Whether a specific action is inside what its owner authorized is a separate check: Know Your Intent (KYI).

ERC-8004 encodes that mapping. It doesn't replace your internal agent database. It creates a durable anchor for it, a record on-chain that persists independently of your infrastructure, that can be queried by any protocol, and that links the agent to the account that owns it in a way that gives auditors something to check, enables composable authorization, and makes multi-agent coordination tractable at scale.

The @abstraxn/agent-kit SDK reduces the implementation to three operations: create the agent, register its identity, store the agentIdentity string. For server wallets, the signing is handled internally. For external wallets, you pass in your signer and the SDK handles calldata construction and confirmation.

An agent without identity is a process. An agent with identity is an actor. That distinction is the whole game when autonomous systems start handling real value.

The Takeaway You Can Repeat at a Meetup

The cost of not having a standard answer to "prove who your agent is" is going up. ERC-8004 is Ethereum's answer: a registry that gives each agent an on-chain identity, owned by an accountable account, in a format any protocol can verify. The teams building agentic infrastructure right now who skip this step will spend 2027 retrofitting it under production load. The ones who wire it in at agent creation time, using a standard that already exists, will have an audit trail their compliance teams can actually read and an authorization layer their protocols can actually trust.

Start building with @abstraxn/agent-kit →

Key Takeaways

• ERC-8004 defines on-chain agentic identity, not for humans, not for generic contracts, specifically for AI agents. Each agent is an ERC-721 token in the Identity Registry, owned by an accountable account, whose URI resolves to a registration file listing its name, endpoints, and supported trust models. Reputation and Validation registries sit alongside it.
• An EVM address is not an identity. It's a cryptographic anchor with no semantic link to accountability. ERC-8004 is the registration that gives it meaning.
• The canonical identifier is the agentIdentity string. The format eip155:{chainId}:{registry}:{tokenId} is globally unique, verifiable on-chain, and chain-specific by design.
• Identity is per-chain. An agent operating on three chains needs three registrations. The SDK call is identical for each; only chainId changes.
• ERC-8004 is a security primitive, not a compliance checkbox. It enables audit trails with chain anchors, trustless authorization, and per-chain policy enforcement with identity context.
• Identity is the precondition for policy enforcement. Spend policies and interaction guardrails are keyed to agent IDs. On-chain identity makes those IDs durable across key rotations and infrastructure changes.
• Register at creation time, not post-deployment. Adding identity registration to a live agent is a migration. Adding it at deployment is one function call.
• The agentIdentity string belongs in your authorization logic, not just your logs. It's a verifiable handle, not a display field.

Frequently Asked Questions

What is ERC-8004? ERC-8004 (Trustless Agents) is a draft Ethereum standard for discovering AI agents and establishing trust in them. It defines three registries: Identity, Reputation, and Validation. In the ERC-721-based Identity Registry, each agent is a token whose URI resolves to a registration file listing its name, endpoints, and supported trust models. The chain, registry contract, and token ID together form a canonical agent identifier any on-chain system can verify.

Do I need ERC-8004 if my agent never touches a blockchain? If your agent only operates off-chain and never needs to prove its identity to an on-chain system, you can skip it. But if your agent calls paid MCP tools, interacts with smart contracts, or needs to be authorized by any Web3 protocol, on-chain identity is the only trust anchor that doesn't require the verifying party to trust your backend.

How is agentIdentity different from an EVM address? An EVM address proves that the holder of a private key can sign transactions. The agentIdentity proves that address was registered in a specific registry, at a specific time, by a specific operator. It's the difference between "this key exists" and "this actor is known and accountable."

Can the same agent be registered on multiple chains? Yes. Each chain has its own IdentityRegistry deployment. The agentIdentity string encodes the chain ID, so registrations on different networks are unambiguous. Your backend stores one identity record per chain per agent.

What happens to identity if I rotate the agent's wallet keys? For server wallets, key rotation doesn't change the EVM address or on-chain identity record: the accessKey is a backend credential, and the wallet address is fixed at creation. For external wallets, the identity token is owned by the old address, and Agent Kit expects the on-chain owner to match the agent's EVM address, so moving to a new address means registering again (or transferring the token, which ERC-8004 allows).

Is ERC-8004 identity required to use spend policies? No. Spend and interaction policies are enforced at the SDK and backend level using Abstraxn's internal agent ID. ERC-8004 registration is the on-chain layer that makes identity verifiable to external systems, not a prerequisite for the policy engine.

How much does ERC-8004 registration cost in gas? One write to the IdentityRegistry contract. On Polygon, this costs a fraction of a cent. On Ethereum mainnet, it varies with gas price, typically $2 to $15. The SDK's prepareAgentIdentity call returns estimated gas before submission so you can add a gas check to your deployment flow.

Can I revoke an ERC-8004 registration? Not by deleting it. Under ERC-8004 a registration is a token, and on-chain pointers cannot be deleted. The owner can mark the agent inactive in its registration file (the active field), and the token's history stays on-chain as an audit record. In your own stack, cut the agent off separately: revoke its access key and API key, and update its interaction policies.

How does ERC-8004 identity work with ERC-4337 account abstraction? ERC-4337 defines how smart accounts submit UserOperations. ERC-8004 defines who owns an agent and where to reach it. They're complementary layers: ERC-4337 is the execution model, ERC-8004 is the identity model. An agent can, and in production deployments should, use both.

Does ERC-8004 comply with GDPR right-to-erasure? On-chain registration data cannot be erased: this is by design for audit integrity. Keep personal data out of anything that goes on-chain or into the public registration file. The userIdentity value you pass to the Agent Kit SDK should be a pseudonymous identifier (a hashed user ID or a DID), not an email address, which preserves the accountability link in your own records.

Further Reading

• ERC-8004 Specification, the official EIP on eips.ethereum.org
• ERC-4337 Account Abstraction, the execution model that powers Abstraxn server wallets
• W3C DID Specification, the W3C standard for decentralized identifiers, for comparison