# Your AI Agent Can Delete Your DNS Records

> The Cloudflare MCP server gives AI agents access to DNS changes, worker deployments, and zone management. Here's how to block deletions and rate limit infrastructure changes.

Published: Mon Mar 16

Canonical: https://policylayer.com/blog/secure-cloudflare-mcp-server

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.

<!--truncate-->

## What the Cloudflare MCP server exposes

Cloudflare's official [MCP server](https://github.com/cloudflare/mcp-server-cloudflare) 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

[PolicyLayer](/mcp-gateway) 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:

```yaml
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:

```yaml
    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:

```yaml
    "*":
        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](/blog/rate-limiting-mcp-tool-calls).

## Getting started

Route your Cloudflare MCP server through PolicyLayer — point your MCP client at the gateway URL with a per-person grant token, and the policy above runs on every call before it reaches Cloudflare:

```json
{
  "mcpServers": {
    "cloudflare": {
      "url": "https://proxy.policylayer.com/mcp/<server-uuid>/",
      "headers": { "Authorization": "Bearer <grant-token>" }
    }
  }
}
```

You define and adjust the policy in the [PolicyLayer dashboard](https://app.policylayer.com) — no local proxy to install or run.

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 →](/policies/cloudflare)
