# Managing a TLD from an AI assistant: what to delegate
> An AI assistant can now search, register and configure names in a conversation. Which tasks to hand over, and where a human must still approve.
Source: https://hush.partners/managing-a-tld-from-an-ai-assistant
Category: Onchain today
Published by Hush Partners.
---
Your namespace is a business asset. The names issued under your TLD carry wallet addresses, resolve websites, identify agents, and in some configurations accept payments on behalf of your organization. When an AI assistant can reach the registry directly, every action that used to require a portal login, an API call, or a support ticket can happen inside a conversation. That is useful. It is also a new surface for errors, for scope creep, and for misunderstanding about who authorized what.
This article builds a permission model. It describes what the connection between an assistant and a registry enables, then sorts the full range of tasks into three tiers: read-only tasks that are safe to delegate without further approval, changes that should pass through a human checkpoint, and actions that should never be automated, however convenient that would be. It also covers logging, accountability, and how to introduce the capability to a team that is right to be cautious.
The goal is not to slow down a useful tool. The goal is to use it without creating a class of decisions that happened, at some point, because a machine thought you wanted them.
## What it means for an assistant to be connected to a registry
The connection is made through a Model Context Protocol (MCP) server. MCP is an open standard that lets an AI assistant discover and call the operations an external system exposes. The registry publishes the server, the assistant connects to it, and the user's conversation becomes a control surface for the registry.
Freename publishes an MCP server that connects AI assistants to Freename, to search, buy and renew domains, build and deploy websites, and manage DNS and Web3 records in a conversation. From the assistant's perspective, these are tools it can invoke when it interprets a request as calling for them. From the user's perspective, a sentence in a chat window can trigger a state change in a live system.
That framing matters. A traditional web portal requires a user to navigate to a page, read the form, and click a confirm button. The friction is not a defect. It is the moment of intention. When the same action is triggered by natural language, the moment of intention is less clear. Did "set up a record for the payments address" mean the address you pasted two messages ago, or the one in a document you shared earlier? The assistant will make a choice. Whether that choice matches your intent is a question the permission model has to handle, not the assistant alone.
Onchain registries add a further dimension. The TLD your assistant reaches on Freename is a token, recorded onchain and held in a wallet, and nobody but the holder of that token can issue names under the TLD. Changes that are written onchain are not undone by clicking back: correcting one takes a new transaction, and a transfer moves an asset out of the wallet entirely. The assistant connects to a system where a mistake can be permanent.
It follows that the first thing to establish is what the connection is authorized to do, and on whose behalf. An assistant has no authority of its own. It acts with the account, the credentials and the approvals it has been given, and it will use the whole of that scope if a request seems to call for it. Do not assume the scope is narrow because the conversation is casual. Ask the person who sets up the connection to write down which account it uses, which actions that account can complete alone, and which ones need a further confirmation outside the conversation. That short note is the foundation of everything that follows.
## What can be done in a conversation
The range of actions available through the connection is wide. The capabilities Freename describes for its MCP server fall into four broad categories.
**Name search and availability.** You can ask the assistant to check whether a name is available, to look up registration details, or to compare options. None of these actions change anything. They are queries.
**Registration and renewal.** The assistant can buy a name and can renew an existing one. Both consume funds and create or extend a record.
**DNS and Web3 record management.** This covers setting, updating and removing the records that govern what a name resolves to, such as a wallet address or the location of a website. These actions change live resolution. Depending on what is configured, a wrong record can break a payment flow, redirect a website, or make an agent unreachable.
**Website deployment.** The assistant can build and deploy a website. This changes what a name serves to the public.
The breadth of this list is why a permission model is worth building before the first team member connects the assistant to the production namespace. The conversation that starts as "check if `pay.yourbrand` is taken" can, in a session without controls, end with a new record on a live name. The page on [what works on onchain TLDs](/whats-live) describes each live capability with its sources, which is useful context before you decide which tasks sit in which tier.
## Tier one: read-only tasks that are safe to delegate
These are tasks where the assistant reads from the registry and reports back, but writes nothing: checking availability, reporting which names exist under the TLD, reading the records on a name, summarizing a configuration for a review, comparing two record sets side by side. The risk of error is limited to a wrong interpretation that you correct with a follow-up message. No onchain state changes and no funds move.
You can let these run freely in any session. The only discipline required is to make sure the assistant is connected to the correct account, a step that belongs in the setup, not in every conversation.
One practical note: even read-only access exposes information. If a contractor or a temporary team member is operating the assistant, they can query the full contents of your namespace. Access to the assistant's registry connection should follow the same controls as access to the registry portal itself. Read-only does not mean low-sensitivity.
Read-only work is also where the assistant earns its place. A person rarely reads every record on every name. An assistant can do it on request and report what looks inconsistent: a name whose records point to an address nobody recognizes, a website that no longer matches its name, a name that is due for renewal. Treat the report as a prompt for a human check, not as a finding. The assistant can misread a record as easily as it can misread an instruction, and a wrong summary acted on without verification turns a tier-one task into a tier-two error.
## Tier two: changes that should need a human approval
This tier covers actions that write to the registry but that are part of normal, recurring operations: registering or renewing a name, adding, updating or removing a record, deploying or updating a website. Fully blocking them would eliminate much of the value of the connection. Fully automating them would remove the human check that catches misconfigurations before they affect users.
The right control here is an approval step: the assistant prepares the action, presents it in clear terms, and a named human confirms before it executes. Some assistant interfaces ask for confirmation before they call a tool. Where yours does not, the workflow discipline must come from your team.
The approval step should display, at minimum, the name being affected, the specific change, and the wallet or account that will execute it. If the assistant has composed a record update from context gathered across a long session, the confirmation display is the point at which a human verifies that what the machine understood is what was intended.
An approval is only a control if the approver reads it. Two habits weaken it quickly. The first is batching: ten changes presented as one confirmation invite a single glance. Ask for one confirmation per name, or per record on a sensitive name. The second is repetition: after enough correct proposals, people confirm by reflex. The remedy is to keep the volume of approvals low enough that each one is read, which is one more reason to leave read-only work entirely unprompted and to reserve confirmation for actual changes.
For teams managing a namespace with more than a handful of active names, a simple record of pending and approved actions is worth maintaining. The assistant can help draft it. The approval decision rests with a person.
Managing a [TLD from an AI assistant](/onchain-tld-ai-assistants) also raises a question of scope: does the person approving an action have authority over that name, or only over some names under the TLD? Your internal governance should map approval authority to categories of names, not leave it at the level of "whoever is using the assistant that day."
## Tier three: actions that should never be automated
Some actions are irreversible, transfer ownership, or change who controls your namespace. These should require not only human approval but a deliberate, separate process that cannot be triggered inside a casual conversation.
The tier holds the transfer of the TLD itself, the transfer of an issued name to another wallet, and any action, where the registry or the wallet offers one, that removes a name. It also holds any attempt to let another address act on the TLD, which on Freename can only mean a transfer: only the holder manages a TLD, there is no delegated management to a second address, and an assistant connected through MCP acts as the holder.
The defining characteristic of this tier is permanence. A transfer moves an asset out of your wallet and into another, and nobody can reverse it for you. If the destination address was wrong, because the assistant took it from the wrong message or because the session was not the one you thought it was, recovery depends entirely on the cooperation of whoever controls the destination wallet.
An approval step inside the conversation is not enough here, and the reason is structural. The confirmation is shown in the same channel that produced the error. If the assistant misread the destination, the confirmation will display the misread destination, formatted cleanly, to a person who has just asked for a transfer and expects to see one. A long wallet address is hard to verify by eye. A control that depends on someone spotting one wrong character at the end of a routine exchange is not a control for an irreversible action.
These actions should happen through a separate, authenticated workflow: a direct login rather than a conversation, a multisignature approval if your wallet setup supports it, and explicit written authorization from whoever in your organization has authority over the asset. The destination address should come from a source independent of the conversation and be checked by a second person. The assistant can draft the instruction, summarize the intent, or look up the current record for reference. It should not execute the transfer.
The same applies to any action that changes who can act on the TLD. Since management cannot be delegated, the only ways to change it are to transfer the TLD or to hand over control of the wallet that holds it, and either one gives someone the key to the namespace. That decision belongs in a documented authorization process, not in a conversation.
## Why names that carry payments sit in the strictest tier
A name that resolves to a wallet address and accepts payments on behalf of your organization is not just a configuration record. It works as a standing payment instruction. If the record is wrong, payments sent to `pay.yourbrand` may reach an address you do not control.
[Payments to a name](/onchain-tld-payments) make this concrete. Senders direct funds to the name instead of a raw address, and the address in the record is what they reach. An automated update that places a wrong address in that record, even one that looks like a routine refresh, misdirects funds from the moment it takes effect, and an onchain payment that has reached the wrong address does not come back on request.
This is not a risk specific to AI assistants. It applies to any automated record management. The assistant connection makes it easier to trigger such an update inadvertently, because the same conversational interface handles both low-stakes queries and high-stakes record changes. A record update on an ordinary name and a record update on a payment name look identical in a chat window. The permission model must treat them differently.
Payment names should therefore form a protected category: named explicitly in your operating procedure, closed to changes initiated by the assistant, and modifiable only through a process that mirrors the controls you use for financial authorizations. The assistant may still read them. A regular read-only check that the address on each payment name is the one your treasury expects is one of the more valuable tier-one tasks you can assign.
## Logging and review
Any system that takes actions on your behalf should produce a record of what it did. This is true of a registry portal, it is true of a DNS provider's API, and it is true of an AI assistant.
The log you need has four fields per action: the time, the action taken, the name affected, and the identity of the session or user that triggered it. For tier-two actions, it should also record who approved and when.
Onchain actions leave a trace of their own. Whatever a session writes to the registry lands in a public record, which any person can check on a block explorer. That is a useful audit trail for what happened, but it does not tell you who in your organization authorized it. Your internal log fills that gap.
Review the log at an interval that matches the pace of change in your namespace. A team registering names daily should review weekly at minimum. A team making changes rarely might review monthly. The review should look for actions that do not correspond to an approved request, which is the sign of either a misunderstanding or a session nobody authorized.
Where your organization is subject to external review, such as a brand protection program, an IP portfolio review, or regulatory reporting, the log is evidence that your namespace is under active governance. An unreviewed log is not governance. It is a list.
Internal logging only covers your own TLD. [Namespace watch](/namespace-watch), the desk's monitoring service for the names of a brand onchain, addresses the other side: activity outside your TLD that you would not see from your registry account.
## Who is accountable for what an assistant did
The question of accountability is not primarily a technical one. The assistant does not have legal standing. The organization whose credentials authorized the session is the actor of record. The person who configured the session, the person who issued the instruction, and the person who approved the action are each accountable for their part in the chain.
This creates a gap that is easy to leave open: the assistant sits in the middle of a chain of actions, and if something goes wrong, attributing responsibility requires reconstructing the session. That reconstruction is only possible if the log described above exists and is detailed enough.
Internally, the accountability question should be answered before the connection goes live, not after an incident. Assign it in writing: who is responsible for the assistant's configuration, who has authority to approve tier-two actions, and who holds authority over tier-three decisions. If your organization uses a responsibility assignment matrix, the assistant's connection to the registry is a row in that matrix.
For external accountability, to a counterparty, to a regulator, or in a dispute, the answer will turn on the rules that apply to authorized agents and electronic transactions where you operate. Those rules vary by country. Your own counsel decides how they apply, and this article is information, not advice. What is clear is that "the AI did it" is not an answer that will satisfy any serious inquiry. The session acted under your credentials, using your account, in your namespace.
For organizations with a brand protection program already in place, this connects to an existing question: who is authorized to change a brand identifier. The page for [general counsel and brand protection teams](/brands-and-legal-teams) sets out how the desk works with them on the onchain side of that question.
## Introducing it gradually
The most reliable way to introduce a new capability to an operations team is to expand its scope only as trust is established. This is especially true when the capability can write to a live system.
Introducing assistant access in stages
Read-only use away from live namesStart where nothing is at stake: an account or a TLD with no names in active use, if you have one, and queries only. The team learns the interface, and patterns of misinterpretation show before they can affect production.
Read-only use on the production namespaceMove to the production account, still for queries only. The team uses the assistant to review live records, check name availability, and prepare change requests.
Tier-two changes with mandatory approvalAllow the changes in tier two, with an explicit confirmation for every one and a named approver for each category of change. Run this phase long enough to complete at least one log review.
Formal review and scope decisionReview the log from the previous phase with the team. Identify actions approved in error, instructions that were misinterpreted, and categories where the approval felt like a formality. Adjust scope on findings, not on assumption.
Tier three closed for goodDocument in the team's operating procedures which actions are outside the assistant's scope whatever a future configuration might permit. This is a standing instruction that survives changes to the tooling.
The staged approach also gives you evidence. If a team member asks why transfers are closed to the assistant, the answer is the operating procedure and the reasoning behind it, not a vague reference to risk. Documented decisions hold. Verbal agreements about "not doing that" do not.
The stages depend on what the TLD is for. A TLD used only for [identities for AI agents](/onchain-tld-ai-agents) inside your organization has a different permission profile from one that issues names to outside registrants. If you are putting a newly acquired TLD to work, the [Launch Roadmap](/activation-roadmap) tool builds a launch plan for it, and the plan tells you which assistant capabilities you need and which you do not.
## Put the model on one page and assign names to it
The table below is the whole framework. Every task in your operation should have a row, even if that row is "not applicable." A gap in the table is a gap in the permission model.
| Task | Tier | Approval | Notes |
|---|---|---|---|
| Name availability search | One | None | Safe to run freely |
| List names under the TLD | One | None | Sensitive information; control who has the session |
| Look up current records | One | None | Useful for audit and review |
| Renewal status check | One | None | Can be asked for on a schedule |
| Register a new name | Two | Named approver | Confirm name and paying account |
| Renew a name | Two | Named approver | Verify the name and the period |
| Add a DNS or Web3 record | Two | Named approver | Display the full record first |
| Update an existing record | Two | Named approver | Ordinary names only |
| Remove a record | Two | Named approver | Confirm the name is not in active use |
| Deploy or update a website | Two | Named approver | Verify the name and the content |
| Change a record on a payment name | Three | Separate process | Financial authorization |
| Transfer a name | Three | Separate process | Never in a conversation |
| Transfer the TLD | Three | Separate process | Written authorization, second check of the address |
| Give another address rights over the TLD | Three | Separate process | No delegation exists; only a transfer does this |
| Remove a name | Three | Separate process | Where available; written sign-off |
The technical connection between an assistant and your registry can be established quickly. The governance work takes longer, and it is the part that protects the namespace.
Start with the table and annotate it for your organization: who approves each tier-two category, who holds authority over tier-three decisions, and which names are in the protected payment category. That annotation is your permission model. It does not need to be elaborate. It needs to exist, to be known to everyone using the assistant, and to be reviewed when the team or the tooling changes.
If the TLD is newly acquired, write the permission model at the same time as the first decisions about records and access, and keep both in the same document. Hush Partners is a private desk for onchain TLDs: a TLD is sold or acquired through the desk under mandate, and [post-transfer activation](/post-transfer-activation) is its service for putting a TLD to work after the transfer. The desk is reached through the [contact form](/contact) only.
## Questions people ask
### Can the assistant act on the TLD itself, or only on names under it?
Do not assume it is limited to names. What the assistant can reach depends on the account it is connected to and on what that account can do, and an account that manages a TLD may be able to act at both levels. Your permission model must address both explicitly. The tier-three restrictions apply to any action on the TLD itself, whatever the tooling would technically allow.
### What happens if the assistant misinterprets an instruction and makes a change?
The consequence depends on the tier. A tier-one action changes nothing. A tier-two action is stopped if the approver catches the error at confirmation. After confirmation, correcting it takes a new change, and the log should show both. A tier-three action should not have been executable through the assistant at all. This is why the tier structure exists: it confines a misinterpretation to the tier where the consequences are manageable.
### Does the assistant's access need to be disclosed to name registrants?
This depends on your jurisdiction and on what your terms say to registrants. If names under your TLD belong to third parties, any change you make to them, by any means, may touch rights that your governance needs to protect. Your own counsel decides the disclosure obligations. The permission model described here is an operational framework, not a substitute for legal review.
### How does assistant access interact with a multisignature wallet setup?
A multisignature wallet, one that requires more than one key to authorize a transaction, adds a control below the conversation. A transaction that needs the wallet cannot complete unless the required number of signers approve it there. If your TLD is held in such a wallet, that requirement is a hard backstop for tier-three actions. It does not replace the permission model. It reinforces it at the level of the asset.
### Should the same person prepare and approve a change?
No, wherever that is possible. The person who asks the assistant to prepare an action and the person who approves it should be different people. In a small team where that is not feasible, the operator should at minimum leave the conversation, review the proposed action in a separate view, and return to confirm. A session that both drafts and approves its own actions provides much weaker governance than one where a second pair of eyes sees every change.