Letting an AI Agent Manage Your Domain Safely

An agent that can edit DNS can take your site, mail and certificates offline with one bad request, or quietly point them somewhere else. Keeping agents away from DNS entirely is rarely necessary. The safer pattern is a narrow lane: the agent may change records in one zone, every change is planned and reviewed before it lands, a copy of the zone exists before each run, and the powers that cannot be undone stay with people.

Split the powers before you hand anything over

A domain has three layers of control, and they deserve three different answers:

1. Records in a zone. A, AAAA, CNAME and TXT entries at your DNS host. This is the layer an agent can reasonably work in.
2. Zone-level settings. Nameservers, DNSSEC, and the DNS host's security features. Mistakes here break resolution for every name at once. Keep these human.
3. The registration. Your registrar account, renewals, contacts, transfers and payment. Losing this layer can mean losing the domain. Keep it human, and keep it in a separate account the agent never touches.

Every control below exists to hold the agent inside layer one.

Give the agent a token for one zone and nothing else

Most DNS hosts let you create API tokens with limited scope. On Cloudflare, you create a custom token, give it the DNS Edit permission, and set Zone Resources to include only the specific zone the agent should manage. The same screen offers two optional restrictions worth using: Client IP Address Filtering, so the token only works from the machine that runs the agent, and a TTL, so the token expires on a date you choose. Cloudflare shows the token secret only once, so put it straight into your secrets manager.

A few rules make the token safer still:

• Use two tokens. A DNS Read token for planning and exports, and a DNS Edit token that only the apply step can use. The agent can think with read access and only change things through a gate.
• Never use a global key. An account-wide key, or a token that can manage other API tokens, lets a confused or manipulated agent mint itself whatever access it wants.
• Prove the limits. Before handing the token over, ask the API for a zone the token should not see and confirm the request is refused.
• Enforce name rules yourself. Token scopes typically stop at the zone. If the agent should only touch names under preview.example.com, enforce that in the wrapper that executes its plans.

Keep the registrar out of reach

The agent should never see your registrar credentials, but a lock at the registry adds protection in case someone else does. ICANN's EPP status code reference describes the client-side locks a registrar can set. clientTransferProhibited "tells your domain's registry to reject requests to transfer the domain from your current registrar to another," and clientUpdateProhibited and clientDeleteProhibited do the same for updates and deletion.

For names you cannot afford to lose, the same page notes that "some Registry Operators offer a Registry Lock Service," which lets registrants, through their registrars, set the matching server-side statuses as extra protection against unauthorized transfers, updates and deletions. Removing a registry lock takes a deliberate, slower process with the registrar, which is exactly the point.

Spending limits

Registrations and renewals cost real money and are hard to reverse. If you want an agent to register names, give it a separate account with its own prepaid balance or a payment card with a hard monthly cap, and require a human approval for anything above a small amount. Keep auto-renew decisions for important names out of its hands altogether.

Two-factor authentication on every human login

Turn on two-factor authentication for every person who can sign in to the registrar or DNS host, ideally with hardware security keys or passkeys. The agent never logs in, so 2FA does not limit it. Its reach is exactly the token's reach, which is why the token scoping above matters so much.

Turn on DNSSEC, and keep the agent away from it

DNSSEC signs your DNS answers so validating resolvers can reject forged ones. Cloudflare describes it as an extra layer of authentication "ensuring requests are not routed to a spoofed domain." Enabling it is a two-step job: turn on signing at the DNS host, then add the DS record it gives you at your registrar.

It also raises the cost of mistakes. Cloudflare's DNSSEC documentation warns that if you change nameservers before the old DS TTL has expired, "validating resolvers will return SERVFAIL" because the cached DS records no longer match the signing keys. A SERVFAIL means the name stops resolving for everyone behind a validating resolver. DS records and nameserver changes belong on a human-only checklist, never in an agent's plan.

Export the zone before every run

A backup you take automatically is worth more than a careful one you forget. Cloudflare's API has an export endpoint that returns the zone as a BIND file, and it 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"

Run this at the start of every agent session, not once a week. Commit the exports to a private repository and every change the agent made shows up as a readable diff.

Plan, review, then apply

The biggest safety gain comes from separating what the agent wants to do from doing it. Instead of letting the agent call the edit API directly, have it write the desired state of the zone as a file, and let a tool compute the difference.

DNS-as-code tools already work this way. octoDNS, an open-source tool for managing DNS across providers, runs octodns-sync as a dry run that prints the planned changes, and only applies them when you add --doit to the command. The same docs carry a warning that matters here: "octoDNS assumes ownership of any domain you point it to," and when told to act it will do what it takes to match, "including deleting any unexpected records." So the desired-state file must describe the whole zone, not just the names the agent cares about, or the plan will propose deleting everything else. With that settled, the split maps onto an agent workflow:

1. The agent edits the desired-state file on a branch.
2. Your pipeline runs the dry run and posts the plan.
3. A person reads the plan and approves it, or rules decide it is small enough to pass.
4. The apply step runs with the edit token, which the agent itself never holds.

Write the approval rules down. Reasonable ones: anything that deletes a record needs a person; anything touching the apex, MX, NS or mail policy TXT records needs a person; plans above a small number of changes need a person; new records under the agent's own subdomain can pass automatically.

Keep an audit trail

Your DNS host keeps its own record. Cloudflare's audit logs "summarize the history of changes made within your Cloudflare account," and as of September 2026 the documentation says they are retained for 18 months. Give the agent its own dedicated token rather than sharing yours, so you can revoke its access without disrupting anything else.

Keep your own log as well, because the host's log shows what changed but not why. For each run, store the plan, who approved it, the exports from before and after, and the task the agent was working on. When something breaks three weeks later, that record turns a guessing game into a lookup.

Rollback

Rollback is where the export pays off. The cleanest path is to restore the previous desired-state file and run the same plan and apply cycle: the plan shows exactly which records will revert, and it gets reviewed like any other change. For a single bad edit, you can also set the one record back to the value in the latest export.

Cloudflare also has an import endpoint that accepts a BIND file, but check how it treats records that already exist before you count on it as an undo button. Whatever method you choose, rehearse it once on a spare zone before you need it, and remember that caches keep serving the bad value until its TTL runs out. Short TTLs on the records an agent changes often 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 DS records.
• A payment method without a hard cap.
• Access to the mailbox that receives registrar and DNS host notices, since that inbox can approve transfers and reset passwords.

Hold that line and the worst an agent can do is a bad record change you can see in a diff, revert from an export, and fix within one TTL.