Cloudflare's cf CLI Gives Agents 3,000 Operations. Your API Token Is the Only Brake

What the new agentic CLI trusts first, why Edit means delete, and how to scope it before an agent ever runs it

Wrangler, Cloudflare's longtime command-line tool, grew to roughly 280 functions over its life. The new CLI that Cloudflare opened as a public beta on September 28 starts with more than 3,000.

That jump is the whole pitch of cf, which Cloudflare calls "the agentic CLI for the entire Cloudflare API." It is generated straight from Cloudflare's public OpenAPI description, it speaks JSON by default, and it ships a search command so an agent can ask in plain language which of those 3,000 operations it needs. It is a well-designed tool for the audience it names.

It is also the first time most teams will hand an agent a single binary that can reach every corner of their Cloudflare account. And when you read the launch post and the README side by side, one thing is missing: any description of what stops that agent from deleting something.

What Cloudflare built

The launch post, by Matt "TK" Taylor and Samuel Macleod, is candid about its target user. "Agents just need JSON," it says, "and if agents are the future primary user of this tool, it should be the default." The cf cli search command lets "your agent ask in natural language what it needs to do," backed by a small search index over API descriptions and parameters. Configuration moves to a typed cloudflare.config.ts, which the post argues agents can "easily identify and edit." Cloudflare also says "we are also open-sourcing Forge," the internal SDK generator behind all this, without giving a date.

The package (npm) is an open beta, requires Node.js 22 or newer, and is licensed Apache-2.0 or MIT at your option. It moved fast: npm shows 1.0.0-beta.2 published September 27 at 20:00 UTC and 1.0.0-beta.5 at 14:41 UTC the next day. Four betas in under a day is normal for a launch week, and a reminder that the surface is still moving. The README says as much: the generated commands follow cf <product> [group…] <operation>, and the surface "changes with the pinned public OpenAPI release."

What the launch post does not cover is permissions. It never mentions token scopes, confirmation prompts, dry runs or a --yes flag, and the npm README does not either. The only hint sits in Cloudflare's April 13 technical preview post, "Building a CLI for all of Cloudflare", which lists a flag-naming rule: "Always --force, never --skip-confirmations." That suggests some commands confirm, and that a single flag an agent can pass skips them. Neither post says which commands those are. I could not find any documented step that reliably sits between an agent deciding to run a destructive command and that command reaching the API.

Why the token is the whole story

If the CLI has no brake of its own, the brake is the credential. So it matters which credential cf uses, and what that credential allows.

Which credential. The npm README lists the order plainly. cf resolves credentials from:

the CLOUDFLARE_API_TOKEN environment variable, then
the OAuth profile selected by --profile, the nearest directory binding, or the default profile.

That order has a sharp edge. The environment variable wins. If your shell already exports a CLOUDFLARE_API_TOKEN for Wrangler, Terraform or a CI job, an agent running cf in that shell uses it, regardless of which OAuth profile you logged into. Many of those tokens were minted broad, because the humans using them wanted fewer surprises. An agent inherits that breadth silently.

What it allows. Cloudflare's token documentation defines two permission levels per resource. Read grants read "and list where appropriate." Edit grants "full CRUDL (create, read, update, delete, list) access."

There is no create-only level. A token that can add a DNS record can also delete every DNS record in that zone. A token that can deploy a Worker can remove one. The permission model draws its lines around resources, not verbs.

Put those two facts together with a 3,000-operation CLI built for agents, and the security model becomes simple to state. Whatever an agent can reach through cf is exactly what its token can do, including every delete inside every resource the token can edit.

The safety feature that is actually there

Credit where it is due, because cf does ship one guardrail that matters, and it is easy to miss.

Add --local to a supported command, and it runs against a short-lived Miniflare instance backed by cf's persisted local state. The README covers KV, D1 and R2 operations locally, then makes a promise worth quoting in full: "Commands with no local explorer equivalent return an error instead of falling through to production."

That is the right default. A tool that silently fell back to your live account when a local equivalent was missing would turn every agent test run into a production run. cf refuses.

There is a second, quieter pattern for Workers. cf workers versions create uploads a version without deploying it, and cf workers triggers deploy applies routes and cron schedules separately. An agent can stage a change that a human then promotes.

Put this into practice

None of this needs a new product. It needs twenty minutes in the Cloudflare dashboard before you let an agent near cf.

1. Check your environment first. Run env | grep CLOUDFLARE in the shell where your agent will run. If a token is already exported, find out what it can do before anything else. That token outranks every profile.

2. Mint a token per agent job. In the dashboard, go to My Profile, then API Tokens (or Manage Account, then API Tokens), and create a custom token. Give it Read wherever the agent only needs to look. Give it Edit only on the specific zone or account resource the task touches. The docs' own example is a token with "Zone DNS Read" on one zone that "will allow the token to read DNS records only for that specific zone."

3. Use the two restrictions that are easy to skip. Cloudflare tokens support client IP address filtering and a TTL. Pin the token to the IP your agent runs from, and set it to expire when the job should be done. An agent token that outlives its task is a standing credential nobody is watching.

4. Hand it over explicitly. Set CLOUDFLARE_API_TOKEN in the agent's own process environment, not your login shell. Since cf reads that variable first, you know exactly which credential is in play.

5. Default the agent to --local. Make local the norm for anything touching KV, D1 or R2, and let the error on unsupported commands tell you where the agent is trying to reach production.

6. Stage, then promote. For Workers, instruct the agent to use cf workers versions create and leave deployment to a person or a separate step with its own token.

7. Put a human in front of deletes. Until Cloudflare documents a confirmation layer, add your own. The JSON-first output and the cf <product> [group…] <operation> shape make it straightforward to wrap cf in a tiny shim that pauses on any command whose operation name starts with delete.

Honest limitations

I have not run every destructive command in cf to see whether any of them prompt at runtime. The April preview's --force convention implies some do, but no doc lists them, and an agent that has read the same convention can pass --force. That is why this article treats the token as the only reliable brake; if Cloudflare documents a confirmation layer that agents cannot skip, the calculus changes, and the token advice still stands.

The README does not say which scopes cf auth login requests through OAuth. If you use the OAuth path instead of a token, you are trusting a default you cannot see from the docs.

A per-verb shim is a blunt tool. Not every destructive operation will be named delete; some updates overwrite, and some purges are called something else. Treat the shim as a speed bump, not a policy.

The repository itself is young. The GitHub repo had about 387 stars at the time of writing, and its MIT license file still carries a 2020 Cloudflare notice with a Wrangler contact address, which suggests it was carried over rather than written for this project. That does not change your rights under the license. It does suggest the packaging is still settling. The README also links a telemetry document; read it before deploying cf somewhere that matters.

Finally, a token scoped perfectly still grants delete inside its scope. Scoping shrinks the blast radius. It does not remove it.

The brake is yours

Cloudflare built cf for agents, and it shows: the JSON, the search, the typed config, the refusal to fall through from local to production. What it did not build, at least not in anything it has documented, is a pause between an agent's decision and your account.

That pause was always going to live somewhere. In cf it lives in the token, which means it lives with you. Open your API Tokens page today, count how many tokens have Edit on everything, and ask which of them an agent could pick up from an environment variable tomorrow.

Sources: Cloudflare, Introducing cf; Cloudflare, Building a CLI for all of Cloudflare; cloudflare/cf on GitHub; cf on npm; Cloudflare docs, Create API token.

Medium metadata

Title: Cloudflare's cf CLI Gives Agents 3,000 Operations. Your API Token Is the Only Brake
Subtitle: What the new agentic CLI trusts first, why Edit means delete, and how to scope it before an agent ever runs it
Tags: Cloudflare, AI Agents, DevOps, Security, CLI
Canonical: fervorai.dev article URL
Reading time: about 8 minutes