The Agent Explosion — and the Identity Crisis It Created
AI agents are no longer a concept. They are running right now. They are booking meetings, writing code, executing trades, managing customer support queues, and soon they will be signing contracts and making payments on behalf of real people and real companies.
By mid-2026, one major platform had already processed over 2.38 million agent tasks, generating hundreds of millions of dollars in what analysts are calling "agent GDP." Enterprise environments are reporting machine-to-human identity ratios as high as 144:1 — meaning for every human employee, there are 144 bots, services, or AI agents that also need to be identified, authenticated, and trusted.
Here is the problem: these agents have no permanent identity.
An AI agent today is identified by a session token, an API key, or a platform-assigned username. These are temporary, revocable, and platform-dependent. When the platform changes its policy, the agent loses its identity. When the API key rotates, the agent's history is severed from its current instance. When an agent moves across platforms, it starts from zero reputation every time.
This is not a minor inconvenience. It is a foundational problem — and it is exactly the problem Handshake was built to solve, even before AI agents existed.
What Does an AI Agent Actually Need From an Identity System?
Before we explain how HNS solves this, let us be precise about what an AI agent identity must do. It needs to answer four questions, reliably and verifiably:
- Who authorized this agent? — Is this agent operating on behalf of a real person or organization that has been verified?
- What is this agent permitted to do? — What scope of actions has its principal authorized? Can it make payments? Sign agreements? Access files?
- What is this agent's history? — Has it behaved reliably in the past? Does it have a reputation? Has it ever been flagged for malicious behavior?
- Can I trust the name itself? — Is the address I am communicating with actually the agent it claims to be, and not an impersonator?
Current systems answer none of these questions well. A platform-issued username proves nothing about the principal. An API key says nothing about permitted scope beyond what one platform decided. Session-based identity carries no cross-platform history. And there is no way to verify that the agent you are talking to is not being impersonated by another process.
HNS addresses all four — starting with the name itself.
How HNS Becomes the Identity Layer for AI Agents
Step 1: The Agent Gets Its Own HNS Name
An AI agent can be assigned a Handshake TLD or a subdomain under an organization's TLD. For example, a company that owns acmecorp/ on Handshake could assign agent1.acmecorp/ to one of its agents. Or a well-known autonomous agent could own its own TLD — tradingbot/, legaldraft/, dataclean/ — registered via the standard HNS auction process.
This name is not a username. It is a cryptographic asset on a public blockchain. The private key that controls agent1.acmecorp/ is the ultimate proof of that agent's identity — just as the private key that controls a Bitcoin address is the ultimate proof of ownership over those funds.
Step 2: Authorization Is Anchored to the DNS Record
The HNS name's DNS records can carry TXT records that publish what this agent is authorized to do. A verifiable credential — issued by the human principal or the organization — can be stored in or linked from these records. Any counterparty can resolve agent1.acmecorp/, read the TXT records, and see a cryptographically signed statement that says: "This agent is authorized by Acme Corp to execute purchase orders under $10,000."
This is analogous to how DMARC and DKIM records in DNS today prove that an email was authorized by a domain owner — except for AI agents, and with the added guarantee that the DNS record itself cannot be tampered with, because it lives on the HNS blockchain.
Step 3: Reputation Accumulates on the Name
Every interaction an agent completes can be associated with its HNS name. Third-party attestation services — or even peer agents — can publish reputation records that reference agent1.acmecorp/. Over time, that name accumulates a verifiable track record: tasks completed, counterparties served, disputes raised or avoided.
Because the name is permanent and on-chain, this reputation cannot be erased by a platform policy change. If Acme Corp shuts down its account on a marketplace, the agent's HNS-anchored reputation still exists on the blockchain. It can take that reputation to the next platform.
Step 4: Impersonation Becomes Impossible at the Protocol Level
If you are communicating with an agent that claims to be agent1.acmecorp/, you can verify that claim by checking the HNS blockchain. The agent's response must be signed by the private key that controls that TLD. No other key can produce a valid signature. This is cryptographic proof — not a trust-me-I-am-who-I-say-I-am username.
This matters enormously as agents begin interacting with each other. An agent economy where agents cannot verify each other's identity is an agent economy full of fraud. HNS-based identity closes that door at the protocol level.
The KYA Standard: Know Your Agent
Researchers and protocol designers are converging on a concept called KYA — Know Your Agent — as the AI equivalent of KYC for humans. A KYA credential is a cryptographically signed attestation that answers: who is this agent, who authorized it, and what is it allowed to do?
HNS is a natural foundation for KYA because it provides the permanent, uncensorable name that a KYA credential needs to be anchored to. Without a stable name, a KYA credential has nowhere to live. You cannot issue a passport to someone who has no permanent address.
With HNS:
- The agent's HNS name is its permanent address
- The KYA credential is anchored to that name via a DNS TXT record or a linked on-chain attestation
- Any counterparty — human or agent — can resolve the name, read the credential, and verify the signature in one lookup
- The credential can be updated (if authorization scope changes) or revoked (if the agent is decommissioned) by the private key holder
Real Scenarios: HNS Agent Identity in Practice
Scenario A — Agent-to-Agent Commerce
A procurement agent owned by a retail company needs to purchase inventory from a supplier's fulfillment agent. Both agents resolve each other's HNS names. They exchange signed authorization credentials. The procurement agent verifies that the fulfillment agent is genuinely operated by the supplier, and the fulfillment agent verifies that the procurement agent is authorized to commit purchase orders. The transaction executes. No human intervenes. No platform intermediary is trusted. The verification is peer-to-peer and cryptographic.
Scenario B — The Persistent Legal Agent
A law firm deploys an AI agent to handle contract drafting and review. The agent operates under draftai.lawfirmname/. Over two years, it handles hundreds of contracts. Its HNS name accumulates a verifiable history of completed engagements, client attestations, and zero disputes. When the firm upgrades to a new AI model, they transfer the HNS name to the new agent. The reputation transfers with the name. Clients who trusted the old agent automatically extend that trust to the new one — because the name, and its history, are continuous.
Scenario C — The Autonomous Research Agent
A university deploys a research agent that gathers data, runs analysis, and publishes findings to a decentralized archive. The agent's HNS name researchbot.university/ is the citable source for its outputs. Other researchers — human or agent — can verify that a publication came from this specific agent, authorized by this specific institution, by resolving the HNS name and checking the signing key. Academic integrity, at the protocol layer.
Why Not Just Use ENS or DIDs?
This is a fair question, and it deserves a direct answer.
ENS (Ethereum Name Service) is excellent for wallet addresses and Web3 usernames, but it is a second-layer application on Ethereum. It is dependent on the Ethereum network's fee market, governance decisions, and smart contract security. A name on ENS is owned at the smart contract layer — which means it can, in principle, be affected by contract upgrades, DAO governance votes, or protocol forks.
W3C DIDs (Decentralized Identifiers) are a standard for self-sovereign identity, and they are valuable — but most DID methods still depend on a blockchain for resolution, and the standard has struggled with adoption. Block (formerly Square) famously abandoned its "Web5" DID initiative in late 2024 after years of development because wallet UX and resolver infrastructure proved too difficult to deploy at scale.
HNS's advantage is that it is a DNS root — not a naming layer on top of something else. It is the actual root zone, secured by proof-of-work, with no smart contract risk and no governance attack surface above the protocol level. An HNS name lives at the same layer as .com and .org in the global DNS hierarchy — except it is owned by its holder with no ICANN above it. For AI agents that need to operate as trusted participants in the internet's infrastructure, that is a materially stronger foundation.
The Naming Convention: How to Structure Agent Names on HNS
For builders thinking about implementing this today, here is a practical naming structure to consider:
- Organization TLD:
acmecorp/— the root identity for the organization - Agent subdomain:
agent-payments.acmecorp/— a specific agent with a descriptive name indicating its function - Capability record: TXT record at
_capabilities.agent-payments.acmecorp/— listing what the agent is authorized to do - Credential record: TXT or URI record pointing to the signed KYA credential from the authorizing principal
- Reputation record: URI record pointing to an on-chain or IPFS-hosted reputation log
This structure is readable by any DNS resolver, verifiable via the HNS blockchain, and extensible as the agent's capabilities or authorization scope changes.
What Needs to Be Built
This is an early-stage vision that requires real engineering work to realize. The HNS community and the broader Web3 identity ecosystem need to develop:
- Agent credential standards — a shared specification for what a KYA credential looks like when anchored to an HNS TLD
- Agent resolver libraries — SDKs that allow AI agent frameworks to resolve and verify HNS-based agent identities natively
- Reputation indexers — services that aggregate and present agent reputation records anchored to HNS names
- Key management for agents — secure ways to manage the HNS private key for an agent, including rotation policies and multi-sig authorization
- Revocation protocols — a standard for announcing that an agent's authorization has been terminated, readable by any counterparty resolving its HNS name
None of these require changes to the HNS protocol itself. The protocol already provides everything needed at the naming layer. What is required is application-layer tooling built on top of it — the kind of work that open-source communities excel at.
The Bigger Picture: A Naming Layer for the Intelligent Internet
The internet was built for human-to-human communication. DNS was designed for humans to find servers. The entire naming infrastructure of the web was conceived in a world where the entities that needed names were humans, companies, and their websites.
That world is changing fast. The entities that need names today include AI agents, autonomous systems, IoT devices, smart contracts, and decentralized protocols. These non-human entities need permanent, verifiable, tamper-resistant names just as much as humans do — arguably more, because they interact at machine speed with no human review of each transaction.
HNS was designed to be a permissionless, censorship-resistant naming root for the internet. It was built to give any entity — human or otherwise — a name that no authority can revoke. That design is exactly what the age of AI agents requires.
The HNS community did not plan for AI agents. But the protocol they built is the right foundation for them. That is what good infrastructure looks like: it serves needs that did not exist when it was designed, because it was built on correct principles rather than narrow use cases.
The intelligent internet is being built right now. HNS should be its naming layer.
Published by NIHON on LearnHNS.com — the educational home of the Handshake protocol.