rentadomain.sh

Give Your AI Agent Its Own Domain, Safely

4 min read

Agents increasingly need a real hostname. A webhook target, a small site, a mail-from address, a place to serve an API: all of them want a domain. Giving an agent its own name is reasonable. Giving it your registrar login is not. The safe pattern is narrow: a name whose registration you keep, control of exactly one zone, and a gate between what the agent wants to do and what actually happens.

Rent the name, do not sign it over

The first decision is who holds the registration, and the answer is not the agent. Keep the name registered to you, or lease it from a holder who keeps it, and give the agent operational control only. The reason is blast radius. If an agent is confused, compromised or simply wrong, the worst it should be able to do is a bad DNS change on one name, visible in a diff and reversible within one TTL. It should never be able to transfer the name, change the registrant, or let it lapse.

One token, one zone, two scopes

Give the agent an API token that reaches one zone and nothing else. Most DNS hosts let you scope a token to a single zone; a platform built for this hands you a token tied to one name. Two rules make the token safe:

  • Split read from write. Where the host issues separate tokens, a read token lets the agent plan and export, and a write token is used only at the apply step. Where one token carries both scopes, as a token on this site does (dns:read and dns:write on one lease), the gate has to live on the server: a plan writes nothing, and only an applied plan changes records.
  • Never a global key. An account-wide key, or a token that can mint other tokens, lets a confused agent grant itself whatever it wants. Prove the limit before you trust it: ask the API for a zone the token should not see and confirm the refusal.

Plan, review, then apply

The biggest safety gain comes from separating what the agent wants from doing it. Instead of letting the agent call the edit endpoint directly, have it propose the change as a plan, compute a verdict on that plan, and only then apply it.

  1. The agent submits the records it wants, as a plan. Nothing is written yet.
  2. The system returns a verdict: what would change, and whether the plan is allowed.
  3. A person approves it, or rules pass it automatically when it is small and safe.
  4. The apply step is the only one that writes, and it writes only a plan the verdict allows.

Two defaults make this gate real rather than decorative. The first plan on a new name is worth holding for a person to read, because that is when a misconfigured agent does the most damage. And anything that deletes a record, or touches the apex, deserves a human by default.

The API on this site is built on that cycle: one call proposes a plan and returns a verdict, a second applies it, and the first plan on a new lease is held for a person to review. The API reference has the calls, and the page for agents has the setup for each client.

Keep the dangerous records human

Not all records are equal. The ones that route or authenticate mail, and the ones that match everything, can hand your name to someone else if they are set wrong. Keep these behind a second factor, a person with a passkey, out of the agent's reach:

  • MX, SPF, DKIM, DMARC. Together these decide who can receive and send mail as your domain. A bad change here is a mail outage or a spoofing hole.
  • CAA. This controls which certificate authorities may issue for the name.
  • Wildcard records. A single * record answers for every name you did not define, so one mistake has a wide reach.

Let the agent freely manage ordinary A, AAAA, CNAME and TXT records under the name, and route the dangerous ones to a human. That split is most of the safety.

Export before every run, roll back from the diff

A backup you take automatically beats a careful one you forget. Export the whole zone at the start of every agent session. Cloudflare's API has an export endpoint that returns the zone as a BIND file and works with a read-only token:

ZONE_ID="your-zone-id"
STAMP=$(date -u +%Y%m%dT%H%M%SZ)
mkdir -p zone-backups
curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/export" \
  -H "Authorization: Bearer $CF_DNS_READ_TOKEN" \
  > "zone-backups/example.com-$STAMP.txt"

Commit the exports to a private repository and every change the agent made shows up as a readable diff. To roll back, restore the previous state and run the same plan and apply cycle, so the revert is reviewed like any other change. Remember that caches keep serving a bad value until its TTL runs out, so short TTLs on the records an agent touches make recovery faster.

What never to hand an agent

  • Your registrar login, registrar API keys or 2FA recovery codes.
  • Transfer authorization codes.
  • A global API key, or any token that can create or edit other tokens.
  • The ability to change nameservers or DNSSEC DS records.
  • A payment method without a hard cap.
  • Access to the mailbox that receives registrar notices, since that inbox can approve transfers and reset passwords.

Hold that line and an agent can run a real domain for you: serve a site, answer a webhook, publish the records it needs, all on its own name. The powers that could lose the domain stay with a person, and the agent works inside a lane where its worst day is a bad record you can see and undo.

More from rentadomain.sh