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 2025 State of AI report, 30% of enterprise AI deployments now involve autonomous agents — up from under 5% in 2023. 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 is the on-chain identity standard for AI agents. Not for people, not for generic smart contracts — specifically for agents.

ERC-8004 defines an IdentityRegistry contract that maps an agent's EVM address to a structured on-chain record. That record links the agent to its controlling operator and produces a globally unique, verifiable identifier that any protocol can check without trusting an off-chain source.

The record encodes three things:

The agent's own address — the cryptographic anchor.

The identity of the human or organization that controls the agent: the userIdentity. This is the accountability link. If an agent acts, you can query the registry and find the operator.

A unique identifier — the agentIdentity — that encodes the chain, the registry address, and a token ID into a single canonical string:

eip155:11155111:0x8004A818BFB912233c491871b3d84c89A494BD9e:42

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

This isn't a signature scheme or a session token. It's a permanent, on-chain record that this agent exists, is controlled by this identity, and was registered at this contract address on this chain. 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 mapping somewhere nobody can quietly delete it.

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 compliance suitability row matters most. An on-chain record that links agent to operator, immutably, is the only thing that satisfies an auditor who wasn't in the room when the agent was created.

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: '[email protected]',
});
 
// Fund the wallet on the target chain first.
// Then register its identity on-chain.
const identity = await agentKit.registerAgentIdentity({
  agentId: agent.id,
  userIdentity: '[email protected]',
  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 EntryPoint 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: '[email protected]',
});
 
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, linked to the controlling 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–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's address before I do?"

Yes. That's a real race condition if you're not careful about your deployment sequence. The fix is the same one used in ENS commits and any other on-chain name registration: don't broadcast your intent before you execute. Fund the wallet, then register in the same atomic deployment step — or as close to it as your setup allows.

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

The IdentityRegistry enforces uniqueness at the contract level. A given EVM address can only be registered once per chain. The userIdentity is an informational field — it's not required to be globally unique, because the same human 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 attempts to register 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 registry contract is deployed at different addresses on each chain. 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 deactivate the agent in the SDK. You revoke its API key. You update your interaction policies to block that agentId. The on-chain record remains — as the audit artifact showing what the agent was authorized to do and when it was active. Any downstream system that checks the registry can treat that identity as suspended.

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, operator, timestamp. That correlation is immutable.

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 operator is immutable on-chain. 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. The userIdentity field on a server wallet ties the wallet's spend authority to a specific operator. 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 use the agent's identity to gate access to paid MCP tools. A tool provider can configure which agent identities are authorized to call their endpoints. Without ERC-8004, "which agent identities" 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.

ERC-8004 encodes that mapping. It doesn't replace your internal agent database. It creates an immutable 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 its operator in a way that satisfies compliance, 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

Okta entering the agent identity space signals that this category is forming — which means 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 links an agent's cryptographic address to its controlling identity, permanently, on-chain, 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. It maps an agent's EVM address to a structured record encoding the controlling userIdentity, the registry contract, and a unique token ID.
• 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 is the on-chain identity standard for AI agents. It defines an IdentityRegistry contract that maps an agent's EVM address to a structured record — encoding the controlling user identity, the registry contract, and a unique token ID — producing a canonical agentIdentity string any on-chain system can verify without trusting an off-chain source.

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, rotating to a new address requires a new ERC-8004 registration, since the record is tied to the address.

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–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? The registration record is permanent — that's the point. Revocation is handled at the policy and authorization layer: deactivate the agent in the SDK, revoke its API key, and update your policy rules. The on-chain record remains as a historical audit artifact.

How does ERC-8004 identity work with ERC-4337 account abstraction? ERC-4337 defines how smart accounts submit UserOperations. ERC-8004 defines who the account belongs to and who authorized 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? The on-chain record is permanent and cannot be erased — this is by design for audit integrity. The userIdentity field should not contain personally identifiable information in production. Use a pseudonymous identifier (a hashed user ID or a DID) to keep the on-chain record GDPR-compatible while preserving the accountability link.

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