Cloudflare Automation with AI Agents: From Alerts to Safe Action

The email lands at 2:07 a.m.: "Firewall events increased on app.example.com." That's Cloudflare automation as most teams run it, a notification, and it has done everything a notification can do. It can't tell you whether this is a credential-stuffing run against your login endpoint, a scanner sweeping for a fresh CVE, or a WAF exception someone deleted yesterday afternoon that's now blocking your own mobile app. Answering that takes Security Events, the audit log, DNS records and origin error graphs: four dashboard tabs and forty minutes, at 2 a.m., before anyone can decide whether to act.

Part one mapped the config-sprawl problem: years of page rules and WAF exceptions nobody dares touch, DNS records without owners, security events nobody reviews. Part two built the DIY layer with the Cloudflare API, scoped tokens and Notifications, and ended at its honest ceiling: the API executes what you already decided. It doesn't investigate, and it doesn't decide.

This part covers what sits above that ceiling. CloudThinker connects to Cloudflare read-only in minutes, investigates continuously, and acts within Auto Mode, so you decide what runs on its own and what waits for approval.

---

Why notifications and scripts stop short

Part two's setup is good. It still leaves the expensive work with a person, for structural reasons.

Notifications fire on counts. A Security Events Alert says volume went up. It doesn't group by rule, path or network, so a credential-stuffing run and your own blocked app look identical in the email.

Changes and symptoms live in different places. The audit log records what changed. Analytics shows what broke. Nothing native joins them, so the most useful question in Cloudflare operations ("what changed right before this?") is always asked by hand.

Scripts encode yesterday's decisions. A failover script knows one failure. A drift diff knows one baseline. Anything new falls through to a person.

Hygiene decays between reviews. Every incident adds a skip rule, a record or a toggle. A quarterly review finds them months late, and the person who added them has forgotten why.

---

Connecting: one scoped, read-only API token

01Edge

Cloudflare

• Zones, DNS and settingsZone, Zone Settings, DNS: Read
• WAF and security eventsFirewall Services: Read
• Traffic, certs and changesAnalytics, SSL, Account Settings: Read

Scoped, read-only API token

02Investigation

CloudThinker

• Live inventoryEvery zone, record, rule and setting
• InvestigateEvents, origin health, recent changes
• Propose the fixWith expected effect and rollback

Nothing installed at the edge

03Where the team works

Chat and on-call

• Slack or TeamsFindings and approvals in the thread
• PagerDutyEscalations with the diff attached
• JiraHygiene follow-ups with evidence

Nothing new to watch

CloudThinker connects the way part two taught you to connect anything to Cloudflare: a scoped API token, never the Global API Key. You create it in the dashboard (My Profile → API Tokens → Create Token) with read permissions only:

• Zone → Zone → Read and Zone → Zone Settings → Read for zone inventory and settings
• Zone → DNS → Read for every record in every zone
• Zone → Firewall Services → Read for WAF custom rules, managed ruleset overrides and security events
• Zone → Analytics → Read for traffic, cache and origin error data
• Zone → SSL and Certificates → Read for certificate status and expiry
• Account → Account Analytics → Read and Account → Account Settings → Read for the audit log, the change history that makes correlation possible

Paste the token into CloudThinker and the first scan starts. The whole flow takes about five minutes. The Cloudflare connection guide lists the exact permission set, so your security review can see precisely what's granted, and that nothing in it can change a record, a rule or a setting.

---

What CloudThinker does continuously

Once connected, CloudThinker builds and maintains a live model of your Cloudflare estate, the inventory you tried to assemble by hand in part one, refreshed instead of decaying.

1. Config inventory across every zone. DNS records, page rules and their modern Rules replacements, redirect rules, WAF custom rules and managed ruleset overrides, cache settings, TLS versions. Drift between zones (one zone at minimum TLS 1.0 while the rest enforce 1.2) shows up as a finding, not an audit surprise.
2. Security events, grouped. Firewall events are grouped by rule, path, ASN and country instead of counted. A spike of blocks from one managed rule against one endpoint reads very differently from a uniform rise across the zone, and the agent makes that distinction before anyone is paged.
3. Origin health. 5xx rates per zone, the 520 to 526 band, cache hit ratios and health check state: the signals part one named as the ones that matter.
4. Correlation with the audit log. Every symptom is checked against recent config changes. "WAF blocks spiked at 01:52" becomes "WAF blocks spiked 19 minutes after user X deleted the exception rule for /api/mobile," which is most of an investigation done.

That last item is the one no native tool provides. Notifications tell you that. The audit log records what changed. Nothing native joins the two.

---

The 2 a.m. spike, revisited

01Signal

Notification

A WAF spike, origin errors, a cert warning or an unexpected change.

02Evidence

Group events

Grouped by rule, path, network and user agent.

03Changes

Read the audit log

Every config change in the window, with actor and diff.

04Output

Finding

Which reading the evidence supports, severity, and a proposed action.

Same notification, with CloudThinker connected. The spike starts an investigation instead of just an email, and the agent begins by naming the readings and what each predicts:

• Credential stuffing would put most blocks on one rule against the login path, from a few ASNs with rotating IPs, with no config change in the window.
• A scanner would spread hits across many paths and rules, from one or two sources, in a short burst.
• A self-inflicted block would show your own clients' user agents being blocked, right after a rule or exception changed.

Then it checks. The event sample shows 96% of blocks coming from one managed rule on POST /login. The traffic clusters in three ASNs with rotating IPs. The audit log shows no config change in the window. Origin error rates are flat. The evidence supports reading one, and the WAF is holding. The finding goes to the team channel with that evidence, severity low, and a proposed action: a rate-limiting rule on /login, for review in the morning. Nobody is woken.

Now flip one fact. The audit log does show a change: a WAF exception deleted at 01:48. The blocked requests carry your own mobile app's user agent. The evidence now supports reading three. The agent escalates instead of filing quietly, proposes restoring the exception, and pages the on-call through PagerDuty with the diff attached. Same alert, opposite right response, and the difference was investigation, not notification.

---

Write access, granted narrowly

The connection token stays read-only until you deliberately add a write permission for a specific action: Zone → Cache Purge → Purge before any purge can run, Zone → DNS → Edit before any record can change. There's never a blanket write token. Every action lands in an audit trail: finding, evidence, proposal, approver, change and timestamp.

---

What a first scan typically finds

The numbers below are illustrative, a composite for a mid-market SaaS estate with a dozen zones and several years of accumulated config. Yours will differ.

Nothing there is exotic. Every row is something you could find with part two's curl commands. The difference is that the table refreshes continuously, and each row arrives with a proposed, approval-gated fix.

---

Why this beats the traditional approach

The deeper difference is where judgment lives. In the native setup it lives in a person who has to be awake and remember the GraphQL schema. With the agent layer, the evidence-gathering is done before anyone looks, and the person's job shrinks to the decision.

---

Prompts to try in your first session

CloudThinker is conversational. You ask in plain language, and answers cite the underlying Cloudflare data so you can verify instead of trust:

"Why did firewall events spike on app.example.com around 2 a.m. last night? Group the events by rule, path and network, and check whether any config changed in the past week."

"List every DNS record across our zones that points at an IP no longer serving traffic, with the last audit-log entry that touched it."

"Which WAF custom rules have sat in Log mode for more than 30 days, and what would they have blocked? Propose only, change nothing."

---

What the agent won't do

"AI with access to your DNS" should make you ask questions. Here are the answers:

• Read-only by default. The connection token grants no write permissions. Acting needs a scoped write permission you grant, and then goes through Auto Mode.
• No DNS, WAF or setting changes you haven't allowed. Without the matching write permission, the change can't happen at all.
• No silent actions. Everything proposed or executed is in the audit trail with its evidence and approver.
• Escalation stays intact. When a finding needs a person (the deleted-exception case above), the agent pages your on-call with the investigation attached. It shortens the path to the decision. It doesn't remove the person making it.

---

From dashboards to a decision queue

Part one showed what sprawls. Part two showed how far the API and Notifications take you. The remaining gap was never effort: nothing native investigates, correlates or decides. With the forty minutes of tab-hopping done continuously, Cloudflare operations stop being a stack of dashboards and become a queue of evidence-backed decisions, many of them pre-approved by policy you wrote.

Try CloudThinker free with 100 premium credits and no card required, and follow the Cloudflare connection guide to see your own zones' first findings within the hour.