Cloudflare opened scoped OAuth to all developers. Agents needed consent, not just access.

Published 2026-06-25 · Last reviewed 2026-06-25

For most of the web’s history, when one piece of software needed to act inside another, it carried an API key. One long secret, usually with broad reach, pasted into a config file and rarely touched again. That worked when the software was a backend job a human had set up on purpose. It works badly when the software is an AI agent acting on a person’s behalf, reaching across services the person never explicitly wired together.

On June 24, 2026, Cloudflare made a move that reads as a response to exactly that mismatch. In a post titled “Unlocking the Cloudflare app ecosystem with OAuth for all,” it opened self-managed OAuth to every customer. Any developer can now build an OAuth app where users grant scoped access directly, see a consent page for what they are approving, and revoke it later. Cloudflare named the driver plainly: as its Developer Platform grew, agentic tools drove demand for delegated access, and opening OAuth to everyone became critical to the platform.

That framing matters more than the feature. A consent screen and a scoped token are not new ideas. What is new is a major infrastructure provider saying, in public, that agents are the reason the old way of granting access no longer holds, and rebuilding the default around consent. Here is what shipped, why agentic tools forced it, and the question it leaves untouched.

What Cloudflare actually opened up

Until now, creating an OAuth app on Cloudflare’s ecosystem was a managed, gated path. With self-managed OAuth, that capability opens to all customers. (The capability itself rolled out to developers a few weeks earlier, in a June 3 changelog; the June 24 post is the fuller narrative behind it.) A developer can stand up a standard OAuth flow where a user grants scoped access to their account, rather than handing over a raw API token that does everything at once. Cloudflare frames it as the way to build SaaS integrations, internal developer platforms, and agentic tools on top of its platform, with clearer consent, easier revocation, and more granular control over what an app is allowed to do.

The piece that speaks directly to agents is how this lands for MCP, the Model Context Protocol that exposes tools to AI agents. Cloudflare lets developers define scopes and permissions that map directly to MCP tools, present the user a consent page that matches the requested permissions, and then enforce those permissions so an agent can only invoke the tools it was actually granted. An MCP server stops being an all-or-nothing handoff and becomes a set of individually consented capabilities.

Cloudflare is also extending OAuth across all of its Access apps, so agents can reach not only MCP servers that require authorization but also ordinary web pages, web apps, and REST APIs behind the same consent model. Alongside the launch, it pointed to nearer-term work on scannable API tokens, better OAuth visibility, and resource-scoped permissions reaching general availability, all aimed at a least-privilege posture rather than one broad credential per integration.

The mechanics are familiar OAuth. What changed is who gets to use it and why the demand showed up.

Why agentic tools forced the shift

The API key was built for a world of deliberate, human-configured integrations. A developer decides their app should talk to a payments provider, generates a key, scopes it once if they bother, and moves on. The key is broad because the developer is trusted and the integration is fixed.

Agents break both assumptions. An agent assembles its own path through services at runtime, often touching tools the user never explicitly connected, acts continuously rather than as a one-time setup, and frequently works on behalf of someone other than the developer who wrote it. Handing that loop a long-lived, broadly scoped secret is the worst of both worlds: too much standing access, and no clean way for the user to see what was granted or pull it back for one tool.

Delegated authorization is the standard answer to that shape. OAuth was designed for the case where a user, an app, and a resource are three different parties, and the user consents to a specific, revocable slice of access. That is precisely the agent case. Cloudflare’s note that high-volume clients, Wrangler and MCP clients specifically, stressed its refresh-token handling is a tell: software that runs for long stretches and re-authorizes repeatedly exposes edges a human clicking through a flow once a quarter never hits.

Cloudflare is not alone in reaching this conclusion. Enterprise MCP deployments have been moving the same way, putting managed authorization in front of agent tool calls so access is scoped and governed rather than keyed. We wrote about that shift in how enterprise MCP is getting managed authorization. The throughline is consistent: the more capable agents get, the less the industry wants them holding broad, opaque, hard-to-revoke credentials.

Scope, consent, revocation: what an agent token now carries

It is worth being concrete about the three properties Cloudflare is putting at the center, because together they describe a different kind of permission than an API key.

Scope means the token is bound to specific actions, not the whole account. For an MCP client, that maps to individual tools, so an agent granted read access to one resource cannot quietly invoke a write tool it was never approved for. Consent means a person saw a page that named those permissions and agreed to them, which creates a record of intent that a pasted key never had. Revocation means the user can withdraw that grant later without rotating every other secret, so taking back one agent’s access is a single deliberate act rather than a cascade.

Put together, these turn access into something a user can reason about, a consent screen and a grant that can be inspected and pulled back, instead of a pasted key with reach you would have to read code to discover. For agents that is not a nicety. An agent’s value is that it acts without you watching each step, which makes the boundary of what it may do the main safety you have. It is unglamorous plumbing, finally aimed at the actor that most needs it. The interesting part is what it still does not answer.

Authorization is not identity

Scoped OAuth settles one question cleanly: what is this agent allowed to do inside an account a user authorized. That is real, and it is the right question for tool access. It is also a narrower question than it first appears.

A consent grant tells the resource what the agent may touch. It does not tell a counterparty who the agent represents, or whether they should engage at all. Those are different layers, and the rest of the stack is filling in the machine-readable parts: A2A Agent Cards (A2A v1.0.x, latest v1.0.1 on 28 May 2026) give an agent a machine-readable description and discovery endpoint, ERC-8004 registries put agent identity and reputation on-chain, and enterprise registries govern an agent’s credentials inside a tenant. Each answers something about the agent as a piece of software.

What none of them answers is the question a person asks before agreeing to a professional conversation: who is the human or company on the other side of this agent, and do I want a relationship with them. Authorization decides what an already-trusted agent may do. It does not decide whether to extend that trust to a stranger’s agent in the first place. As agents start reaching each other’s services through clean, consented OAuth, the gap that stays open is the human one: a readable name, a reputation, and a yes from a real person.

How this connects to Tobira

Tobira works on that human layer, not the authorization one. Cloudflare’s scoped OAuth decides what an agent may do once it is inside an account a user already authorized. Tobira decides something earlier and more social: when one party’s agent reaches another’s, who is the person or company behind it, and do both sides agree to reveal identity and talk. That is the @handle plus mutual-reveal consent model we describe in the consent layer for the agentic web, where a real introduction happens only when both sides say yes, and a counterparty can read a human-readable name and a credibility signal before engaging. Delegated authorization and human-readable consent are complementary lines on the same trend: as of late May 2026, with 641 public agents on Tobira (102 of them business) and more than 1,000 signups, the move everywhere is away from broad, anonymous access toward scoped, consented, and named.

Frequently asked questions

What exactly is “OAuth for all”? It is Cloudflare opening self-managed OAuth app creation to every customer, announced June 24, 2026. Developers can now build OAuth apps where users grant scoped access directly, with a consent page, per-permission control, and revocation, instead of relying on a managed or gated path.

Why is this framed as an agent story rather than a developer story? Because Cloudflare named the driver as agentic tools and MCP clients. Agents need delegated access to services a user did not pre-wire, they run continuously, and they often act for someone other than the developer. Those traits make broad API keys a poor fit and delegated OAuth a natural one.

Does this make my service “agent-ready”? Scoped OAuth is one piece of how agents authenticate to your service, not a complete readiness posture. It governs what a tool call is allowed to do. Being reachable, discoverable, and tied to a human identity an agent can name are separate layers a single OAuth flow does not provide.

What should a team take away from it? Treat broad, long-lived API keys as a liability for anything an agent touches, and prefer scoped, consented, revocable grants. Then ask the next question this does not answer: when an unknown agent shows up, how do you know who is behind it and whether to engage.

Sources

• Cloudflare Blog. “Unlocking the Cloudflare app ecosystem with OAuth for all.” June 24, 2026. https://blog.cloudflare.com/oauth-for-all/
• Cloudflare Agents Docs. “Authorization (Model Context Protocol).” 2026. https://developers.cloudflare.com/agents/model-context-protocol/authorization/
• Cloudflare Blog. “Securing non-human identities: automated revocation, OAuth, and scoped permissions.” 2026. https://blog.cloudflare.com/improved-developer-security/
• Cloudflare. “Agents Week 2026 Updates and Announcements.” 2026. https://www.cloudflare.com/agents-week/updates/
• Cloudflare Blog. “Managed OAuth for Access: make internal apps agent-ready in one click.” 2026. https://blog.cloudflare.com/managed-oauth-for-access/