Secure Cloudflare access for AI agents

Through Cloudflare, agents can discover and call any endpoint across DNS, Workers, R2, and Zero Trust – every call runs through your policies and is logged for audit.

Server URL: https://mcp.cloudflare.com/mcp

Credential modes

Cloudflare supports per-org dynamic registration only, so there is no app to create on Cloudflare's side and no client ID or secret to enter. See Credential modes for how it compares with Use SecureAuth's app and Bring your own app.

Before you begin

• A Cloudflare account that can reach the zones and resources your agents need.
• Administrator access to your Agent Authority workspace, to add the resource.

Setup

1. In the Agent Authority console, go to Resources and click Add Resource.
2. Select Cloudflare from the catalog.
3. On Choose how to install Cloudflare, click Per-org dynamic registration. Selecting it adds the resource right away with its tools pre-configured.

Dynamic client registration

When you add the resource, the gateway registers its own OAuth client with Cloudflare – the credential that lets it sign users in. Cloudflare's own account and role-based permissions still apply, so an agent can only reach what the person who signed in could already reach.

Verify the connection

The gateway syncs the Cloudflare tools automatically. To check the connection end to end, ask your agent to run a request:

Search the Cloudflare API for DNS record endpoints

If matching endpoints come back from search, the connection is working.

How users connect

Access is per user. Each additional user connects their own Cloudflare account the first time their agent calls a Cloudflare tool: the gateway returns a sign-in link, the user authorizes once, and the tools work from then on. Go to Connections to manage linked accounts.

Available tools

Both tools take a single code field – a JavaScript async () => { ... } arrow function that the upstream runs in a sandboxed Dynamic Worker and whose return value becomes the tool result.

Cloudflare uses Codemode so two tools cover the entire 2,500+ endpoint API surface (~1k tokens of tool schema instead of the ~1M tokens a one-tool-per-endpoint MCP would need). Typical flow: call search to find the endpoint you want, then execute to call it.

Required scopes

The gateway requests this scope automatically when it registers the client, so there is nothing for you to configure. Cloudflare decides what to grant, and any scopes it returns during registration replace the list below.

• offline_access: lets the gateway refresh the user's access token without asking them to sign in again.

Policy examples

• Read-only access. Deny execute, ordered above anything that would allow it – including the seeded Allow all rule your org starts with. Callers can still discover endpoints through search but cannot mutate.
• Constrain what execute may run. Put the CEL condition on a deny rule that inspects the submitted code, not on an allow rule. A conditional allow whose condition doesn't match falls through to the next matching rule – usually Allow all – and the call is permitted anyway; a conditional deny that can't be evaluated fails closed and denies. See Policies for rule order and the seeded default.

Next steps

• Create a policy – start from the read-only pattern in Policy examples above.
• Policies – how first-match-wins rule order and the seeded Allow all rule interact.