Integrating ENS Agents

An ENS name can be a verifiable ERC-8004 AI-agent identity. This guide is for anyone rendering that identity on a name - marketplaces, wallets, explorers - covering how it works, how to integrate, and, most importantly, what you can and can't trust.

How it works

Three standards combine:

ENSIP-25: AI Agent Registry ENS Name Verification - A name sets a text record agent-registration[<registry>][<agentId>] declaring "I am agent <agentId> in this registry."
ENSIP-26: Agent Text Records - The records the owner sets that define what the agent is and what it can do: agent-context, and agent-endpoint[mcp|a2a|web].
ERC-8217: Agent NFT Identity Bindings - An on-chain contract binds an agent id to the name's actual ENS NFT - an ERC-1155 token for wrapped names, and an ERC-721 token for unwrapped .eth 2LDs.

Setting up an agent

Want your own ENS name to be an agent? ENS8004.xyz is a web interface for it - connect your wallet, bind your name's NFT to an ERC-8004 agent identity, and set the ENSIP-26 records that describe your agent (its endpoints and context).

The trust model

A name is an agent when it has an on-chain binding in the ENS8004 adapter - that's what /domain/:name/agent lists under the registrations key in its response. Each registration carries two signals you should treat very differently:

Field	Meaning
`is_bound`	The adapter binds an agent to this name's ENS NFT, on-chain.
`has_ensip25_registration`	A bonus signal: the name also carries a conformant ERC-7930 agent-registration record (ENSIP-25).

The binding proves the link - not the identity. is_bound: true means this ENS NFT is bound to that agent id on-chain. It says nothing about whether the agent is who its profile claims to be. Anyone can register a lookalike name (0pensea.eth), bind a real agent to it, and set the description, avatar, and MCP endpoint to impersonate a brand. The binding is genuine; the identity is not.

Verified vs self-asserted data

When you render the avatar or anything under profile, treat it as untrusted user content:

Escape everything. context is an arbitrary owner-set string - HTML-escape before display.
Don't present endpoints as official. agent-endpoint[mcp|a2a|web] are URLs the owner chose. Don't auto-fetch them server-side without an SSRF guard, and don't imply they're vetted.
Sanitize the avatar. It's an arbitrary URL (or ENS avatar reference) - resolve and proxy it; never inline it as raw markup.
The badge means "verified binding," not "verified brand." If you show a checkmark, make sure users read it as "this name is bound to this agent id," not an endorsement of the displayed content.

Integration patterns

Three ways to integrate, by effort:

Pattern	How	When to choose
Per-name lookup	Call `GET /api/domain/:name/agent` server-side when rendering a name's page.	Simplest.
Periodic sync	Walk `GET /api/agents?page=N`. Zero per-page-view API calls.	High-traffic surfaces; the full directory is small.
Fully independent	Index `AgentBound` events from the adapter contract yourself.	No dependency on this API.

Endpoint reference

Full request and response detail for /domain/:name/agent, /agents, and /agents/:agentId lives in the Domains API reference.