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 is Cloudflare automation as most teams run it — a notification, and it has done everything a notification can do. It cannot 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 is 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 even decide whether to act. The gap between a notification and an investigation is who does those forty minutes.

This is part three of our Cloudflare automation series. Part one mapped the config-sprawl problem: zones accumulating 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 does not investigate, and it does not decide.

This article covers what sits above that ceiling: CloudThinker agents as the autonomous action layer on top of Cloudflare — connected read-only in minutes, investigating continuously, and acting only within the autonomy levels you set.

Connecting: one scoped, read-only API token

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

• Zone → Zone → Read and Zone → Zone Settings → Read — zone inventory and settings
• Zone → DNS → Read — every record in every zone
• Zone → Firewall Services → Read — WAF custom rules, managed rulesets, security events
• Zone → Analytics → Read — traffic, cache, and origin error data
• Zone → SSL and Certificates → Read — certificate status and expiry
• Account → Account Analytics → Read and Account → Audit Logs → Read — 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 is granted — and that nothing in it can change a record, a rule, or a setting.

What the agents do continuously

Once connected, the agents build and maintain 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 — surfaces as a finding, not a surprise in an audit.
2. Security event streams. Firewall events are grouped by rule, path, ASN, and country rather than counted. A spike in blocks from one managed rule against one endpoint reads very differently from a uniform rise across the zone, and the agents make that distinction before you are paged.
3. Origin health. 5xx rates per zone, cache hit ratios, health check state — the signals part one identified as the ones that actually matter.
4. Correlation with the audit log. Every symptom gets 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 piece no native tool provides. Cloudflare Notifications tell you that; the audit log records what changed; nothing native joins the two.

The 2 a.m. spike, revisited

Same event, with the agents in place. The firewall-event spike triggers an investigation, not just an email. The agents pull the event sample, see that 96% of blocks come from a single managed rule firing on POST /login, that the traffic clusters in three ASNs with rotating IPs, and that the audit log shows no config change in the window. Conclusion: credential stuffing, WAF holding, origin unaffected. Finding filed with evidence, severity low, proposed action: add 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 agents escalate instead of filing quietly, propose restoring the exception, and page the on-call with the diff in hand. Same alert, opposite correct response — and the difference was investigation, not notification.

Graduated autonomy: what may act, and where

Every action class gets an autonomy level, set per zone:

• Notify — findings and evidence only. The default for everything.
• Suggest — the agents propose the specific change: the DNS correction, the WAF rule adjustment, the cache purge, with expected effect and rollback.
• Approve — the change is prepared and executes only after a named human approves it.
• Autonomous — the agents execute and report. Teams typically reserve this for reversible, low-blast-radius actions — purging cache for a path after a bad deploy, say — after weeks of watching the agents be right at the Approve level.

Write access follows the same gradient. The connection token stays read-only until you deliberately add a write scope for a specific action class — Zone → Cache Purge → Purge before any purge can run, Zone → DNS → Edit before any record can change. No blanket write token, ever. And every action at every level lands in an audit trail: finding, evidence, proposal, approver, change, timestamp.

What a first scan typically finds

Illustrative composite for a mid-market SaaS estate — a dozen zones, several years of accumulated config. Yours will differ.

Notice the shape: nothing exotic. Every row is something you could have found with part two's curl commands — the value is that the table refreshes continuously and each row arrives with a proposed, approval-gated fix attached.

Prompts to try in your first session

The agents are conversational — you ask in plain language, and answers cite the underlying Cloudflare data so you can verify rather than trust:

• "Why did firewall events spike on app.example.com around 2 a.m. last night? 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?"

What the agents will not do

Because "AI with access to your DNS" is a sentence that should make you ask:

• Read-only by default. The connection token grants no write scopes. Acting requires you to add a scoped write permission and raise the autonomy level for that action class.
• No DNS, WAF, or setting changes without approval unless you have explicitly set that specific action class to Autonomous for that specific zone.
• 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 human — the deleted-exception case above — the agents page your on-call with the investigation attached. They shorten the path to the decision; they do not remove the decider.

From dashboards to a decision queue

Part one showed you what sprawls; part two showed you how far the native API and Notifications can take you. The remaining gap was never effort — it was that nothing native investigates, correlates, or acts. With agents doing the forty minutes of tab-hopping continuously, Cloudflare operations stop being a stack of dashboards and become a queue of evidence-backed decisions, most of them pre-approved by policy you wrote.

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