# Naming AI agents under your own TLD
> As software agents start to act for organizations, counterparties need to know whose agent they face. What a name under your TLD provides.
Source: https://hush.partners/naming-ai-agents-under-a-tld
Category: Onchain today
Published by Hush Partners.
---
Organizations are deploying software agents that negotiate, order, pay and commit on their behalf. A procurement agent places a purchase order. A treasury agent moves funds. A compliance agent approves a document. Each of these actions is taken in the organization's name. The party on the other side of each transaction needs to answer a simple question before they proceed: whose agent is this, and how far can I rely on it?
That question does not have a clean answer yet. Work on agent identity is active and unsettled, and no single approach has become the reference. What is clear is that a name matters: a string like `pay.yourbrand` tells a counterparty something a wallet address alone never can. It tells them which organization stands behind the agent, and it places accountability where it belongs.
This article works through what a name under your own TLD adds, what the draft onchain standard proposes, and where the open questions remain. By the end you will be able to design a naming scheme for the agents you are deploying, and you will know the governance decisions to make before your first agent name goes live.
## The identity problem when agents act across organizations
A human employee who enters a contract is traceable. Their email comes from a domain the organization controls. Their authority is documented. Their actions leave an audit trail. When something goes wrong, the chain of responsibility can be reconstructed.
An agent has none of this by default. An agent that calls a service on your behalf carries, at minimum, a wallet address (the public identifier of a key pair) and often an access key issued by the service. The wallet address proves that someone controls a key, and nothing about who that someone is. The access key is a secret shared between two systems. Neither of them is legible to a counterparty who has never dealt with you before.
Inside one organization this is manageable, because the organization knows its own systems. The difficulty starts at the boundary. Without a shared way to identify agents and to record how they behave, agents built by different vendors and run by different organizations have no common ground on which to check each other. Each pair of parties ends up arranging its own exchange of credentials, which works for a handful of long-standing partners and not for a first contact.
A useful agent identity is therefore more than a name or an address. It ties together an operator, a place where the agent can be reached, the wallet it acts through, the tasks it is permitted to perform and some evidence of how it has behaved. That is a larger set of requirements than any single mechanism covers, and it is the reason the subject is discussed in layers.
The problem compounds when agents direct other agents. A sourcing agent might start a negotiation agent and a logistics agent to complete a purchase. Each of those acts with some delegated authority. A counterparty who receives an instruction from the second or third agent in such a chain has no settled, widely used way to trace it back to the organization that authorized the chain in the first place.
This is more than a technical inconvenience. If an agent commits your organization without clear authority, the question of whether that commitment holds will reach your legal team, and the answer depends on the law that applies and on the facts. The name an agent carries, and the governance behind that name, is part of the record your counsel will want to see.
## What a counterparty needs to know
When a counterparty faces an agent they have not dealt with before, they need answers to three distinct questions. The first is identity: who operates this agent, and are they who they claim to be? The second is authorization: what is this agent permitted to do on behalf of its operator? The third is history: how has this agent behaved in past interactions?
The three questions are separate, and an answer to one does not answer the others. An agent can be correctly attributed to a well-known organization and still act outside its mandate. An agent with an excellent record can belong to an operator the counterparty has never heard of. Treating a single signal as if it settled all three is the most common mistake in early designs.
A name under your TLD answers the first question directly. If `pay.yourbrand` is a name issued under `.yourbrand`, and `.yourbrand` is held by your organization, the counterparty knows the agent was named by you. They cannot learn this from a wallet address, and they cannot learn it from a credential the agent issued to itself.
The name does not answer the second and third questions. Those need more: a record of what the agent may do, and a record of what it has done, kept somewhere the counterparty can read and that the agent cannot rewrite at will. This is the gap that a draft standard, ERC-8004, sets out to fill. It is not finished.
It also helps to be honest about what the counterparty already has. Where both parties run conventional systems, a domain name in the DNS, a certificate and a contract between them answer the identity question well, and nothing in this article replaces that. The onchain approach becomes relevant when the agent acts through a wallet, pays or is paid onchain, or meets counterparties with whom no prior arrangement exists.
## The draft standard and its three registries
ERC-8004, "Trustless Agents", is a draft Ethereum standard. Its aim is to let agents be found and assessed across organizational boundaries without a single platform vouching for them. It defines three registries, each a shared onchain record that answers one of the counterparty's questions.
| Registry | Question it answers | What it holds |
| --- | --- | --- |
| Identity | Whose agent is this? | A token per agent, pointing to its agent card |
| Reputation | How has it behaved? | Feedback from those it worked with |
| Validation | Has its work been checked? | Independent checks of its work |
### Identity
In the identity registry, each agent is an ERC-721 token, the widely used standard for a unique token held in a wallet. The token points to an agent card: a file that describes the agent, what it does and where it can be reached. The token gives the agent an identifier that does not depend on any one vendor's platform, and because it follows a common token standard, existing tools that read such tokens can display it.
Note what the token does and does not establish. It establishes that a given wallet holds the identity. The description in the agent card is written by whoever controls the token. A counterparty still needs a reason to believe that the wallet belongs to the organization named in the card, and that is where a name under a TLD the organization holds becomes useful.
### Reputation
History, the third of the counterparty's questions, is the business of the reputation registry, where feedback from those the agent worked with is collected. Its purpose is to let a new counterparty see how earlier ones rated their dealings. How feedback is weighted, who may leave it and how much of it lives onchain are matters of detail in the draft, and details of this kind are the ones most likely to move before a standard settles.
### Validation
The validation registry records independent checks of an agent's work. Where reputation is the opinion of counterparties, validation is a check by a party whose role is to verify. The draft leaves room for different kinds of validators, and you should not assume a particular method will be the one that prevails.
How naming registries for onchain TLDs plug into ERC-8004 is still evolving. Whether a name under `.yourbrand` will fit cleanly beside the identity token depends on tooling that is being developed. You can follow [what works at present](/whats-live), with sources, and read more on [identities for AI agents under a TLD](/onchain-tld-ai-agents).
## What a name adds to an agent's identity
A wallet address is a long string of letters and digits. It shows control of a key. It tells a counterparty nothing about the organization behind the key, the purpose the agent serves or the scope of its authority. A name under your TLD adds three things that the address alone cannot provide.
**Readability.** `pay.yourbrand` is legible to a human reviewer. A counterparty's compliance team, reading a log of transactions, can see at a glance that an instruction came from a payment agent in your organization's namespace. The address behind the name remains visible, but the name is the part that travels in audit trails, contracts and dispute records. People compare names reliably. They do not compare long addresses reliably, and most errors of attribution start there.
**Organizational attribution.** The name `pay.yourbrand` carries two assertions: that it was issued by whoever holds `.yourbrand`, and that `.yourbrand` is held by your organization. Both can be checked before a transaction rather than taken on trust. If agents are going to buy, sell and negotiate for organizations, the other side needs something it can look up, and a name is the readable layer over the onchain record that makes the lookup practical.
**Namespace control.** On Freename, the registry this article takes as its reference, a TLD is recorded onchain as a token held in a wallet, and only the holder of a TLD can issue names under it. No other party can create `pay.yourbrand`. The registry record is public, and anyone can check it on a block explorer, a public website that displays what is recorded on a blockchain. The counterparty does not need to ask you, or anyone else, for confirmation.
A name can also carry more than identity. Names issued under a TLD can be used [to receive payments](/onchain-tld-payments) and resolve in the wallets that support them, so the identifier that appears in a payment record can match the one that appears in a contract record. That consistency saves real work in an audit. Support for onchain names in wallets and browsers is partial and changes, so confirm what your counterparties can resolve before you rely on it.
## Why the TLD holder matters here more than anywhere
For most uses of a TLD, the identity of the holder is a commercial matter. For agent identity it is the whole point. The value of `pay.yourbrand` to a counterparty rests entirely on one inference: the holder of `.yourbrand` is the organization of that name. If that inference fails, every name under the TLD says something untrue, however well each agent behaves.
Two consequences follow.
The first concerns who holds the TLD inside your organization. This is a question of corporate governance, not of technical access. The wallet that holds `.yourbrand` is the source of authority for every agent identity you publish under it. Whoever controls that wallet controls the namespace. A TLD held in the personal wallet of an employee, or of an agency that set it up, is a weak foundation, even if everyone involved acts in good faith. A multisignature wallet, one that requires several keys to approve an action, held under a documented corporate policy, is the usual answer.
The second concerns organizations that do not hold the TLD that matches their name. You cannot issue agent names under a TLD you do not hold, and names issued under it by anyone else would not identify your agents. Holding the TLD comes before everything else in this article. What follows the acquisition, including preparing the TLD to issue names, is the subject of [post-transfer activation](/post-transfer-activation).
There is also a difference of structure with the DNS that deserves a plain statement. In the DNS, your domain sits under a TLD operated by a registry, and you reach it through a registrar. That arrangement is mature, well governed and, for websites and email, simply better supported. With an onchain TLD, the organization holds the top level itself, and the decision to issue a name is the holder's alone. For agent identity the appeal is the short chain: one holder, one public record, and names that exist only because the holder created them. The [glossary](/glossary) defines "holder", "name" and "TLD" as they are used here.
## Naming conventions for agents under .yourbrand
A naming convention should let anyone who reads a name understand what the agent does and whether it is a production agent. It should do this within two levels: the TLD and the name under it. Everything else about the agent belongs in records, not in the name.
A function-first convention works well. The name reflects the agent's main capability, which is what a counterparty most often needs to know:
- `pay.yourbrand`: an agent that executes payments
- `procure.yourbrand`: a procurement agent
- `verify.yourbrand`: a compliance or verification agent
- `report.yourbrand`: a reporting agent
Where you run several agents with the same function, add a qualifier inside the same label, joined by a hyphen. For example, two regional payment agents could be `pay-emea.yourbrand` and `pay-apac.yourbrand`, and a non-production equivalent `pay-test.yourbrand`. The function stays first, so names sort and read together, and the structure stays at two levels.
### What to keep out of a name
Three kinds of information age badly in a name:
- The underlying model or software version. The version will change, and the name should not have to.
- The name of an individual employee. The agent may outlast their tenure, and a personal name invites the reader to assume a personal authority.
- Generic labels such as `agent.yourbrand` or `bot.yourbrand`. They tell a counterparty nothing about what the agent does, and they leave no room for the second agent.
A fourth temptation is to encode the level of authority in the name, for instance a spending limit. Resist it. Authority changes more often than function, and a name that states a limit which is no longer accurate is worse than a name that states none.
### The internal register behind the names
Keep an internal register, separate from the onchain record, that maps each name to the team that owns it, the scope of its authority, the wallet it points to, when it was issued, when it was last reviewed and the conditions under which it should be retired. The onchain record is the authority on whether a name exists. The internal register is the governance layer above it, and it is the document your auditors and counsel will ask for. The [Launch Roadmap](/activation-roadmap) tool can help you place this work within a wider plan for the namespace.
## Governance: who may create an agent identity, and how one is retired
Issuing a name under `.yourbrand` takes little effort for the holder. That is its strength. It is also a governance risk if the process has no structure. Before the first agent name is issued, settle the following points.
### Who may request a name, and who approves it
Keep the circle narrow. Not every team that deploys an agent should be able to obtain a name. Define who may ask, for example the technology owner of the agent, and who decides, for example a small group drawn from security, legal and the business owner. The request should record the agent's purpose, the wallet or system the name will point to and the scope of authority the agent holds.
Approval should involve at least one person outside the team deploying the agent. An agent that can make financial commitments should need approval at the level that would approve a comparable commitment made by a person.
### How the name relates to the agent's identity record
Under the draft standard, the identity token points to an agent card. If your agent has both a name under `.yourbrand` and an identity token, the two should describe the same agent and lead to the same place. When they diverge, with the name pointing one way and the token another, the counterparty faces the very confusion the name was meant to remove. Make one team responsible for keeping them aligned, and check the alignment at each review.
### When and how a name is retired
A name should be retired when the agent it identifies is shut down, when the scope of its authority changes so much that the old name would mislead, or when an incident gives reason to think the name or its wallet is no longer under your control.
Retirement has three parts, and only one of them is onchain. First, the name stops pointing to the agent, so that a lookup no longer leads a counterparty to a system that has been shut down or put to another use. What the registry allows the holder of a TLD to do with a name that has already been issued, and who holds that name once issued, depends on the registry's terms. Read those terms before you issue the first name, not when you need to withdraw one. Second, the internal register is updated with the date and the reason. Third, the counterparties that dealt with the agent are told.
A retired name should not be reused for a different agent. A counterparty who kept `procure.yourbrand` in its records expects it to mean what it meant before. Reuse saves a label and costs clarity.
### Who holds the TLD wallet
The wallet that holds `.yourbrand` should be a multisignature wallet controlled by at least two authorized persons, with a documented process for replacing a key holder who leaves. Losing access to this wallet means losing the ability to issue names, and for an organization that runs agents at scale that is a material operational risk.
## What is still unsettled
The draft status of ERC-8004 is not the only open question. Several practical matters would remain even if the standard were finalized as it stands.
**How naming registries connect to the identity registry.** The draft defines the token that represents an agent and the agent card it points to. How a name under an onchain TLD relates to that token is still evolving. If you bind your names tightly to your identity tokens, plan for revision, and keep the binding in your internal register so that it can be redone.
**How a retirement reaches those who need to know.** When a name stops pointing to an agent, the applications that stored the name or the address in their own records do not learn of it automatically. An offboarding process for an agent has to reach beyond the onchain record, which is why the previous section treats notification as part of retirement.
**Visibility across networks.** Agents may operate on more than one blockchain, and a name recorded on one network is not automatically readable from another. This can be dealt with, but it takes deliberate choices about where your names are recorded and where your counterparties look.
**Resolution outside the onchain world.** Onchain names resolve outside the ICANN DNS root, so ordinary software does not read them without support. A counterparty whose systems cannot resolve `pay.yourbrand` will still need the address, or a conventional identifier, alongside the name.
**How the law treats agent identity.** What counts as adequate identification of an autonomous agent for contracts, payments or regulated activities is not settled, and the answer varies by country. This article gives information, not advice. Your counsel decides how your naming policy fits the requirements that apply to you.
**How far reputation can be trusted.** A reputation record is only as good as its resistance to manipulation. Whether feedback collected under the draft will hold up in practice depends on details that are still being worked out. Until then, treat an agent's onchain reputation as one input among several.
None of these points is a reason to wait. They are reasons to choose first steps that remain useful whichever way the open questions are settled.
## A sensible first step
Start with governance, not with infrastructure. A naming policy and a register cost little, survive any change to the draft standard and make every later step easier. The plan below is ordered so that each step can be finished before the next begins.
First naming plan for AI agents under a TLD
Confirm who holds the TLDCheck that your organization holds the TLD that matches its name, that it sits in a multisignature wallet and that at least two authorized persons hold keys. If your organization does not hold the TLD, that comes first.
Write a naming policyOn one page, state which function labels are permitted, who may request a name, who approves it, what is recorded at issuance and what triggers retirement. Have legal and security approve it before the first name is issued.
Open an internal registerMap each agent name to its owning team, its scope of authority, its wallet, its identity token if it has one, and its next review date.
Issue the first namesBegin with the agents that deal with outside counterparties, because that is where identity matters most. Keep names short and function-first, and record the scope of authority before a name goes live.
Review the names on a scheduleCompare the names that exist under your TLD with your register at fixed intervals. The onchain record is public, so the comparison can be automated.
Follow the draft standardGive one person the task of tracking ERC-8004 and reporting any change that affects how your names relate to identity tokens.
Two further points sit beside the plan. Names that resemble yours can appear in namespaces you do not hold, and a counterparty may not notice the difference. Spotting those look-alikes of your agent names is a job for [Namespace Watch](/namespace-watch), the service that keeps a brand's names onchain under monitoring. And if your team would rather handle routine namespace operations in conversation than through a dashboard, see the page on [managing a TLD from an AI assistant](/onchain-tld-ai-assistants).
If your organization does not hold the TLD that matches its name, Hush Partners can be mandated to find and approach the holder, and it follows the file through to closing by onchain escrow and to activation afterwards. The desk is reached through the [contact form](/contact).
## Questions people ask
### Can one agent have several names under the same TLD?
Technically, several names can point to the same agent or wallet. Whether that is wise depends on your policy. Several names for one agent blur audit trails and make retirement harder, because every one of them has to be dealt with. The cleaner approach is one name per agent role, with a new name when the agent's function grows into something different.
### Does issuing an agent name create trademark rights in it?
No. A name under an onchain TLD is not a registered trademark and confers no intellectual property right in the label. A trademark protects a sign used to distinguish goods or services, and how the right arises varies by country. What the name gives you is a public record of issuance under a TLD your organization holds. Whether that record carries weight as evidence in a dispute is a question for your counsel.
### What happens to agent names if the TLD changes hands?
The new holder becomes the only party able to issue names under `.yourbrand`. For a TLD with active agent identities under it, that is a material point in any transaction. Before a transfer, the parties should agree in the transaction documents how existing names are treated and when the agents that carry them will be renamed or retired.
### Is an onchain agent name enough for a regulated transaction?
Not by itself. A name shows who issued it. It does not satisfy the customer identification or anti-money-laundering requirements that may apply to a transaction. Whether an onchain agent identity, combined with other documentation, meets those requirements is for your counsel to answer in each regulatory context, and the answer will not be the same in every country.