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.
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
dns_records_create
dns_records_update
workers_create_worker
workers_delete_worker
zones_create
zones_update
kv_namespace_delete
r2_bucket_delete
d1_database_delete
MCP provides no built-in controls. Every tool is available, every call goes straight through.
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: "Policy for cloudflare/mcp-server-cloudflare"
default: "allow"
tools:
dns_records_delete:
rules:
- name: "block dns deletion"
action: "deny"
on_deny: "DNS record deletion is not permitted via AI agents. Delete records manually in the Cloudflare dashboard."
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: "rate limit dns creates"
rate_limit: 10/hour
on_deny: "DNS record creation rate limit reached (10/hour). Try again later."
dns_records_update:
rules:
- name: "rate limit dns updates"
rate_limit: 10/hour
on_deny: "DNS record update rate limit reached (10/hour). Try again later."
workers_create_worker:
rules:
- name: "rate limit worker deploys"
rate_limit: 5/hour
on_deny: "Worker deployment rate limit reached (5/hour). Try again later."
zones_update:
rules:
- name: "rate limit zone updates"
rate_limit: 5/hour
on_deny: "Zone update rate limit reached (5/hour). Try again later."
A global backstop catches everything — including read tools — at 60 calls per minute:
"*":
rules:
- name: "global rate limit"
rate_limit: 60/minute
on_deny: "Global rate limit reached (60/minute). Try again later."
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.
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.