Closing the agent gap for internal apps
Cloudflare protects thousands of internal applications with Cloudflare Access — everything from company-critical tools to small prototypes. The standard Access flow works well for people: unauthenticated users hit a login page and pick their authentication method. But agents hit a wall. They only see a redirect to a login page they cannot act on.
The company initially patched this for its own use by modifying OpenCode's web fetch tool to trigger the cloudflared CLI for specific domains, which opened an authorization flow and fetched a JWT to append to requests. That workaround is now retired in favor of a general solution: every Access application now supports managed OAuth in open beta. When enabled for an app, agents that speak OAuth 2.0 can discover how to authenticate via RFC 9728, run the user through the auth flow, and receive an authorization token — the same JWT used in the original stopgap.
One-click OAuth for Access apps
Enabling managed OAuth on an Access application is a single toggle. Once active, Cloudflare Access operates as the authorization server, returning the www-authenticate header so unauthorized agents know where to find token information — at https://<your-app-domain>/.well-known/oauth-authorization-server. From there the agent follows standard OAuth procedures:
- The agent registers itself dynamically as a client via Dynamic Client Registration (RFC 7591)
- The agent walks the human through a PKCE (Proof Key for Code Exchange) authorization flow (RFC 7636)
- The human authorizes access and a token is granted to the agent for making authenticated requests on the user's behalf
This flow mirrors what the Model Context Protocol (MCP) already uses. Cloudflare initially built OAuth support into its MCP server portals product, which proxies access to MCP servers. By extending the same capability to every Access app, agents can now reach web pages, web applications, and REST APIs — not just MCP servers.
Making legacy apps agent-ready without a rewrite
Retrofitting the long tail of internal software for agents is a heavy lift if done app by app. Ideal agent-ready applications would have discoverable APIs, CLIs, and MCP servers — but that work cannot be completed before AI adoption begins. Many internal apps work perfectly well when agents treat them as straightforward websites. For an internal wiki, enabling Markdown for Agents plus managed OAuth is enough for an agent to read protected content.
Managed OAuth puts Access in front of legacy applications to make them agent-ready immediately — no code changes, no retrofitting, just standards-based compatibility.
User-attributed access beats service accounts
Agents must act on behalf of the humans inside an organization. The common anti-pattern of provisioning service accounts with static credentials for agents and MCP servers has real limits. While service tokens fit simple prototypes, they break down when fine-grained access controls and audit logs are required.
Every agent action should trace back to the human who initiated it, and an agent should never exceed what its operator is allowed to do. Service accounts and static credentials are where attribution collapses — they invite confused deputy problems and produce audit logs that look like they came from the agent itself. OAuth expresses the user–agent relationship properly: tokens are scoped to the user's identity, so access policies apply and audit logs attribute actions to the actual end user.
Teaching web fetch tools to handle RFC 9728
RFC 9728, standardized in April 2025, defines how clients discover where and how to authenticate. The Model Context Protocol adopted it quickly and now requires both MCP servers and clients to support it. The same standard applies to plain HTTP requests against protected web pages and REST APIs.
Most agents ship a "web fetch" tool — a basic HTTP client similar to the JavaScript fetch() API with some response post-processing. Today these tools typically ignore the www-authenticate header. A model might introspect the headers and improvise, but the tool itself does not follow the header to /.well-known/oauth-authorization-server and complete an OAuth flow. That is exactly what agents already do as remote MCP clients, and Cloudflare argues web fetch tools should do the same.
To demonstrate, Cloudflare has published a draft pull request adapting OpenCode's web fetch tool. The adapted tool first checks for existing credentials and uses them if present. On a 401 or 403 with a www-authenticate header, it requests user consent to run through the server's OAuth flow — sending the human to the login page, then a consent dialog, then using the received token for the authenticated request.
Any agent — Codex, Claude Code, Goose, or others — can implement this with no Cloudflare-specific code. RFC 9728 also helps with REST APIs: an agent that supports the standard can discover and authenticate against an API, and with RFC 9727 it can even discover available endpoints without extra documentation, MCP servers, or CLIs.
These tools remain useful — Cloudflare itself provides an MCP server for the Cloudflare API, the Wrangler CLI, and Agent Skills. But RFC 9728 support guarantees a path forward even when none of those are preinstalled. An agent with a sandbox for untrusted code can write and execute calls against an API the human has authorized. Cloudflare is working to support this for its own APIs.
Shared identity providers across accounts
Cloudflare's internal apps run across dozens of Cloudflare accounts, all grouped into an Organization — a recently introduced construct for managing users and configurations across accounts. Each account previously needed its own identity provider configuration, creating consistency risk: one account might accept a one-time PIN while another enforces single sign-on.
Cloudflare is building the ability to share an identity provider across accounts within an organization. Administrators will designate a single primary IdP and bridge new accounts to it with one click, so every Access application across all accounts is protected by the same identity provider. This removes the manual per-account IdP setup that does not scale for organizations where many teams operate their own accounts.
Closing the loop between Access and Workers
Internal developers are increasingly relying on AI agents to scaffold and ship applications. That shift puts pressure on the underlying infrastructure: agents need clean, programmatic access to the same internal tools that humans use via a browser. Cloudflare is responding by tightening the integration between its Workers development platform and the Cloudflare One security suite, with the goal of making internal apps both easier to build and easier to secure.
Work already underway in that direction includes a more direct hookup between Cloudflare Access and Cloudflare Workers — eliminating the need to manually validate JWTs or track which of many routes a given Worker is exposed on. Also in the pipeline is wrangler dev --tunnel, a way to share a local development server with collaborators before anything is deployed to production. A CLI for Cloudflare Access and the full Cloudflare API is on the roadmap as well, alongside further announcements during Agents Week 2026.
Managed OAuth for Access applications
The first concrete piece of this effort is now generally available in open beta. Managed OAuth lets any Cloudflare customer attach an OAuth-aware identity layer to internal applications sitting behind Cloudflare Access. The feature works whether the app is built on Cloudflare Workers or hosted elsewhere.
The practical effect is that an internal tool protected by Access can speak standard OAuth to an agent or external client — no per-app identity plumbing required. For teams that haven't yet built internal apps on the Workers platform, that path remains the quickest way to go from nothing to a deployed, protected production service.
