VOOZH about

URL: https://dev.to/policylayer/your-ai-agent-can-delete-your-dns-records-4gh7

⇱ Your AI Agent Can Delete Your DNS Records - DEV Community


Your AI agent just deleted the A record for your production domain. It was trying to "clean up stale DNS entries" after you asked it to audit your Cloudflare zone. Thirty seconds later, your site is unreachable. Customers see nothing. Your uptime monitor fires. And the agent has already moved on to the next record.

DNS propagation means even after you recreate the record, some resolvers won't see it for hours. One tool call, minutes of downtime, and there's no undo button.

What the Cloudflare MCP server exposes

Cloudflare's official MCP server gives agents access to 30 tools spanning DNS, Workers, KV, R2, D1, and zone management. The read operations are harmless — listing zones, querying Workers observability, searching documentation. The dangerous ones:

  • dns_records_delete — removes DNS records from a zone
  • dns_records_create and dns_records_update — modify your DNS configuration
  • workers_create_worker and workers_delete_worker — deploy or destroy Workers
  • zones_create and zones_update — create and modify zones
  • kv_namespace_delete, r2_bucket_delete, d1_database_delete — destroy storage

MCP provides no built-in controls. Every tool is available, every call goes straight through.

Block deletions, rate limit everything else

Intercept sits between your agent and the Cloudflare MCP server. Every tools/call is evaluated against a YAML policy before it reaches Cloudflare. Violating calls are blocked and the agent receives a clear denial message — not a silent failure.

The first thing to lock down: DNS deletions. There is almost never a reason for an AI agent to delete a DNS record. Block it outright:

version: "1"
description: "Policyforcloudflare/mcp-server-cloudflare"
default: "allow"
tools:
 dns_records_delete:
 rules:
 - name: "blockdnsdeletion"
 action: "deny"
 on_deny: "DNSrecorddeletionisnotpermittedviaAIagents.DeleterecordsmanuallyintheCloudflaredashboard."

The action: "deny" rule is unconditional. No rate limit, no conditions — the tool is simply unavailable. The agent gets back the on_deny message and can tell the user to handle it manually.

For tools that agents legitimately need, rate limits prevent runaway loops. DNS creates and updates are capped at 10 per hour. Worker deployments and zone changes get 5 per hour — tight enough to stop a misfiring agent, generous enough for real work:

 dns_records_create:
 rules:
 - name: "ratelimitdnscreates"
 rate_limit: 10/hour
 on_deny: "DNSrecordcreationratelimitreached(10/hour).Tryagainlater."
 dns_records_update:
 rules:
 - name: "ratelimitdnsupdates"
 rate_limit: 10/hour
 on_deny: "DNSrecordupdateratelimitreached(10/hour).Tryagainlater."
 workers_create_worker:
 rules:
 - name: "ratelimitworkerdeploys"
 rate_limit: 5/hour
 on_deny: "Workerdeploymentratelimitreached(5/hour).Tryagainlater."
 zones_update:
 rules:
 - name: "ratelimitzoneupdates"
 rate_limit: 5/hour
 on_deny: "Zoneupdateratelimitreached(5/hour).Tryagainlater."

A global backstop catches everything — including read tools — at 60 calls per minute:

 "*":
 rules:
 - name: "globalratelimit"
 rate_limit: 60/minute
 on_deny: "Globalratelimitreached(60/minute).Tryagainlater."

The rate_limit shorthand expands into a stateful counter that tracks calls per window and resets automatically. For more on how this works under the hood, see Rate Limiting MCP Tool Calls.

Getting started

Install Intercept and point it at the Cloudflare MCP server:

npm install -g @policylayer/intercept

Then run it with the Cloudflare policy:

intercept -c cloudflare.yaml -- npx -y @cloudflare/mcp-server-cloudflare

Every tool call now passes through the policy engine. DNS deletions are blocked entirely. The 11th DNS change in an hour gets denied. The 61st call in a minute hits the global limit. Your infrastructure stays intact.

Adjust the limits to match your workflow. A platform team managing dozens of zones might raise DNS limits to 30/hour. A solo developer might drop worker deploys to 2. The point is that the enforcement is deterministic, transport-level, and impossible for the model to override.

Full Cloudflare policy →