AI & Domains
Your Domain Is Your Agent's Name: Identity for the Agentic Web
2026-08-13 · OSIR Team
Summary: AI agents are now the majority of web traffic, and the sites they visit have started asking who they are and who sent them. Every serious answer so far - IETF drafts like DNS-AID and the Agent Name Service, A2A agent cards, Cloudflare's Web Bot Auth - puts that identity in the same place: the domain name system. If that sticks, the domain you already own becomes the name your agent carries. We go through the proposals, what they agree on, and the migration mistake we caught in our own agent card while writing this post.
Part 4 of our Agents & Domains miniseries. Previously: can an AI buy you a domain?
The web is closing to anonymous agents
In June 2026 Cloudflare published a number that would have sounded absurd two years earlier: bots now generate 57.5% of HTML web traffic. More than half. Humans are officially a minority on their own web, and much of the machine share is AI assistants browsing on someone's behalf.
The infrastructure layer reacted fast. Cloudflare already blocks AI crawlers by default for new sites, is extending that default further in September 2026, and has moved publisher content from free crawling to paid access. Which leaves anyone running an agent with the same problem: if your agent cannot prove who it is and who it works for, it will find more and more doors closed.
That is the backdrop for a crowd of competing identity proposals. The interesting part is where all of them ended up pointing: at the domain name system.
The proposals on the table
| Proposal | Backers | How identity works | Status (August 2026) |
|---|---|---|---|
| DNS-AID | Infoblox | Agents published in DNS via service discovery, secured with DNSSEC | IETF individual draft |
| Agent Name Service (ANS) | GoDaddy co-authors | Agent naming and verification via DNS + certificates, using domains operators already own | IETF individual draft; Infoblox + GoDaddy joint endorsement May 2026 |
| A2A agent cards | Linux Foundation, 150+ orgs | A JSON card at a well-known URL on your domain describes the agent and its skills | v1.0 stable, signed cards; adoption still early |
| Web Bot Auth / Signed Agents | Cloudflare; IETF WG chartered | Agents sign requests cryptographically; verifiers check published keys | Deployed in production ahead of standardization |
| MIT Project NANDA | MIT | A federated index for agent registries, described as "DNS for agents" | Research + fresh IETF draft (July 2026) |
| ERC-8004 | Ethereum community | On-chain identity and reputation registries for agents | Ethereum mainnet since January 2026; draft EIP |
Six efforts from six very different corners, and every one of them ends up hanging agent identity on a domain. There is a boring reason for that: a domain is the one identifier that is already global, resolvable everywhere, and something you can own outright. Nobody has managed to build a better one in thirty years of trying, so the agent people are not trying either. Even the blockchain crowd loops back to it - the .kred registry ties its on-chain agent reputation system (Score.Kred, built on ERC-8004) to domain tokens. We wrote about that one in our .kred guide.
To be fair about maturity: nothing here is a finished standard yet. These are individual drafts, early specs, and things shipped ahead of standardization. But GoDaddy, Infoblox, Cloudflare, the Linux Foundation, and MIT did not coordinate their answers, and they all gave the same one.
The agent card reality check - including ours
On paper, the A2A protocol is the furthest along: a stable 1.0 spec, signed agent cards, over 150 supporting organizations, integrations in the big cloud agent platforms. Reality is running well behind the paper. A survey in late July 2026 found only about 65 published agent cards on the entire public web - and 15 of those sit at a location where a current A2A client will never find them.
How does a published card end up unfindable? A path change. Early versions of the spec put the card at /.well-known/agent.json; since spec 0.3.0 the standard location is /.well-known/agent-card.json. Cards that never moved are invisible to 1.0-era clients.
We would love to smugly explain other people's migration mistakes, but while writing this post we checked our own A2A card - published back when the old path was the spec - and found it exactly where we left it: at the legacy path, with the new path not yet answering. We are in that survey's unlucky 15. The fix (serving the card at both paths) is in flight on our backend, and the lesson is bigger than us: in a standards land rush, publishing early is an advantage that decays unless you keep tracking the spec. Our live card, for the curious, describes 7 agents with 53 skills; the AI integration docs cover how to call them.
So what should a domain owner do?
Here is what we would actually do, starting with the safest call:
- Your domain is the safest bet in the room. Every proposal builds on names you can already own. An agent identity like
agent.yourcompany.comcosts nothing beyond the domain you have and works with today's drafts (subdomains, TXT records, well-known URLs) the moment any of them settles. - Don't buy speculative "agent TLDs." Alternative-root extensions marketed for AI agents are not real, resolvable TLDs. Real candidates (like the .agent string proposed for ICANN's 2026 round, which we covered in the new-extensions post) are years from launch if they survive contention. A domain you own today beats a string that may never exist.
- Clean up your DNS before verification arrives. Signed requests and DNS-anchored discovery both reward domains with tidy records, DNSSEC enabled, and control you can actually demonstrate. Every OSIR domain includes DNSSEC support - and yes, your agent can manage those records itself.
- Expect your registrar to speak agent. Discovery documents, agent cards, and signing keys live at the registrar/DNS layer, so this becomes registrar work. It is why the MCP connector, the A2A card, and the agent-facing docs are part of what we sell, not weekend experiments.
Agent identity FAQ
Does my AI agent legally need a domain?
No - nothing requires it today. But every emerging discovery and verification mechanism (DNS-AID, ANS, A2A cards, Web Bot Auth key discovery) is built around domains, so an agent meant to be found or trusted by others will in practice be named by one.
What is an A2A agent card?
A JSON document at a well-known URL on your domain (since A2A spec 0.3.0: /.well-known/agent-card.json) describing an agent's identity, endpoints, and skills so other agents can discover and call it. A2A 1.0 adds cryptographic signing. If you published a card before mid-2025, check the path - the location changed, and clients only look at the new one.
Should I create a subdomain for my agent?
It is the sensible pattern: something like agent.yourdomain.com gives the agent a stable name, its own DNS records, and TLS - without touching your main site. Any OSIR domain can add it in seconds (an A or CNAME record), and part 5 of this series walks through the full setup.
What is Web Bot Auth?
A mechanism (Cloudflare-led, now with an IETF working group) where agents cryptographically sign their requests and sites verify the signature against published keys. It is already enforced in production by major infrastructure providers ahead of formal standardization - a signal of how fast "prove who your agent is" is becoming mandatory.
Do I need blockchain for agent identity?
No. DNS-based approaches cover discovery and verification without any chain. On-chain systems like ERC-8004 add portable reputation on top; the .kred registry bridges both worlds by anchoring on-chain agent identity to a domain.
Part 4 of the Agents & Domains miniseries. Next: Give your agent a home. Previously: Can an AI buy you a domain?
Image generated with AI (Higgsfield).