You ask an AI agent to check a DNS record. It asks for Cloudflare access. A minute later, you are looking at a permissions screen that could let it change far more than the record you wanted checked.
That screen deserves more attention than the prompt. The AMA Hub's recommendation is to define the job first, then grant access that fits it. For a DNS inspection, start with read access to the intended zone. Decide separately whether any change is necessary. A successful connection should tell you that a bounded task works, not leave you guessing what else the same connection can do.
This guide uses Cloudflare's documentation checked September 13, 2026. The examples are proposed configurations, not a claim that we tested every connector or account. The accompanying image is an AI-generated editorial illustration of limited access, not a Cloudflare interface or product photograph.
Write the job before choosing permissions
Start with a sentence you could hand to another person: “Read the DNS records for this website and explain whether its mail records match the provider's instructions.”
That sentence has a target, an action, and an output. It does not authorize changing mail routing, deploying an application, or adjusting another website. Keep those as separate decisions if the inspection finds a reason to act.
For your own setup, write down four things: the site or account, the requested operation, the expected evidence, and who can stop the access. Avoid a task description such as “manage my Cloudflare.” It gives you almost nothing against which to judge the resulting configuration. Our agent-permissions audit guide covers the wider inventory beyond this one provider.
Prefer an API token to the Global API key
Cloudflare describes the Global API key as its legacy authorization method. It carries the user's permissions across the user's resources; it is not a credential you can confine to one staging site while keeping that user's production resources out of reach. Cloudflare recommends API tokens where possible. Source: Global API key limitations.
For a new agent integration, that makes a scoped token the sensible starting point. If a tool asks specifically for a Global API key, pause the setup and inspect its current supported authentication methods. An old tutorial is not sufficient reason to give a new integration broad access.
Keep the credential out of the conversation. Use the integration's intended secure configuration mechanism. A token with fewer permissions still needs protection: anyone who obtains it can exercise the authority it grants.
Match both the operation and the resource
Cloudflare's token setup separates permissions from resource selection. Its documented example grants DNS read access to one zone, allowing DNS reads there while denying other operations and other zones. Many permission groups distinguish read access from edit access. Source: creating API tokens.
The distinction matters when a connector says it is “read only.” Check the credential behind that label. A read-only tool interface and a read-only token are two different controls. The former describes exposed behavior; the latter restricts what the credential can authorize at the provider.
Use the current permission reference to match the actual endpoint. For example, DNS Read and DNS Write are separate entries. Do not assume that a permission suitable for DNS also covers a Workers deployment, or that every product offers an equally narrow resource boundary.
When a workflow needs broader permission than the task warrants, consider keeping its write step in a separate, explicitly invoked deployment process. That is an operating recommendation, not a promise that Cloudflare can scope every token to every individual object.
Choose the right kind of token
Cloudflare offers user API tokens and account API tokens. Account tokens belong to an account rather than an individual user, which can be useful for ongoing service operations. Creating or updating one requires Super Administrator permission, and product compatibility must be checked. Source: account API tokens.
An account token is not automatically the right answer for every connector. Check what that integration accepts and which APIs it needs. In Cloudflare's current compatibility matrix, Workers is supported while Registrar is not. That is enough to show why “it works for one Cloudflare task” does not establish that it works for another.
Avoid changing token type, permissions, and deployment behavior all at once during troubleshooting. With one change at a time, a failed check has a much smaller set of possible explanations.
Put an end date on temporary work
Cloudflare supports token restrictions by time window and client IP address. These let you limit when a token is usable and where requests may originate. Source: restricting tokens.
For a one-time inspection, choose a lifetime that covers the work and review. For an ongoing integration, record who maintains it and how it will be replaced before expiry. An expiration date without an owner can become tomorrow's unexplained outage.
Treat IP restrictions as a fit question. A machine with a known, stable outbound address is a different case from a hosted connector whose egress addresses you have not established. Confirm the real request origin before configuring an allowlist. Never guess an address merely to get through the setup screen.
Verify the task, then record how to revoke access
Cloudflare's token verification endpoint can report that a user token is active. That is useful, but it is not the same as showing that the intended API operation succeeds with the intended resource selection. Cloudflare also documents that client IP filtering does not apply to its Verify Token endpoint. After verifying the credential, perform the smallest authorized read needed for the job from the actual integration host.
Keep the evidence compact: the intended target, operation, result, time, and token identifier or descriptive name. Keep the token value out of that record. When testing denial behavior, use resources you own and a controlled environment; do not probe unrelated accounts or attempt production writes just to prove they fail.
Finally, document the revocation path before depending on the integration. Our access-revocation guide explains why disconnecting a tool and invalidating its credential are different steps. The MCP server checklist covers the additional service boundary when a connector sits between the agent and the API.
The useful result is straightforward: the agent completes the named job, you can inspect what happened, and you know how to withdraw its access. Expand that arrangement only when a new task gives you a concrete reason.