Cloudflare 有數千個內部應用程式，有些是自行開發的，有些則是由第三方開發、自行託管的軟體。從幾乎每位員工都會使用的關鍵業務系統，到各種實驗性的 side project 與 prototype，都涵蓋其中。
所有這些應用程式都受到 Cloudflare Access 的保護。不過當 Cloudflare 開始在程式撰寫以外的場景建置和使用 AI Agent，卻碰到了一道牆。 人員可以存取 Access 保護的應用程式，但他們的 Agent 做不到。
Access 部署在內部應用程式的前端。管理員定義好存取原則後，Access 會將未經驗證的使用者導向登入頁面，讓他們選擇驗證方式。
Cloudflare Access 登入畫面
這個流程對人類使用者來說運作順暢，但 Agent 看到的只是一個重新導向至登入頁面的回應，而它根本無法對此採取任何行動。
由於讓 Agent 能存取內部應用程式的資料非常重要，Cloudflare 立即為內部需求實作了一個臨時方案。他們修改了 OpenCode 的 web fetch 工具，使其針對特定網域觸發 cloudflared CLI，開啟一個授權流程以取得 JWT（JSON Web Token）。透過將這個 Token 附加到請求中，Agent 就能安全、即時地存取內部生態系統。
這個方案雖然暫時解決了困境，Cloudflare 今天正式告別這個臨時方案 ，並為所有人修復這個問題。現在進入公開測試版（Open Beta），每個 Access 應用程式都支援 Managed OAuth。只需一鍵即可為 Access 應用程式啟用，能說 OAuth 2.0（開放授權協議）的 Agent 就可以輕鬆探索如何進行驗證（RFC 9728）、引導使用者完成授權流程，並取回授權 Token（即初始方案中的那個 JWT）。
現在，這個流程對人類和 Agent 都能順暢運作。Cloudflare Access 提供免費方案。此外，建立在新推出的 Organizations 測試版之上，很快就能跨 Cloudflare 帳號橋接 IdP（Identity Provider）。
Managed OAuth 的運作方式
針對受 Cloudflare Access 保護的特定內部應用程式，只需一鍵即可啟用 Managed OAuth。
啟用後，Cloudflare Access 即作為 Authorization Server。它會回傳 www-authenticate 標頭，告知未經授權的 Agent 應到哪裡查詢取得授權 Token 的相關資訊。這些資訊存放於 https://<your-app-domain>/.well-known/oauth-authorization-server。有了這個指引，Agent 只需遵循 OAuth 標準即可：
以下為授權流程圖：
如果這個授權流程看起來很熟悉，那是因為它正是 Model Context Protocol（MCP） 所採用的流程。Cloudflare 最初是在 MCP server portals 產品中建置了對此的支援——該產品可代理並控制多個 MCP Server 的存取，使 Portal 能作為 OAuth Server 運作。現在，Cloudflare 將此能力擴展至所有 Access 應用程式，讓 Agent 不只能存取需要授權的 MCP Server，更能存取網頁、Web 應用程式與 REST API。
一次升級所有內部應用程式，讓它們支援 AI Agent
要將大量舊有內部軟體升級為支援 Agent，並不容易。理論上，為了讓應用程式具備「Agent 就緒」能力，每個內外部應用程式理想上都應提供可被探索的 API、命令列介面（CLI）、精心設計的 MCP Server，並採納各種新興的 Agent 標準。
AI 導入不能等待所有系統都完成改造。大多數組織都累積了多年來建置的大量應用程式 backlog。而許多內部「應用程式」只要讓 Agent 把它當成一般網頁來使用，就能運作得很好。以內部 Wiki 為例，只需啟用 Markdown for Agents、開啟 Managed OAuth，Agent 就擁有了讀取受保護內容所需的一切。
為了讓最基本的功能在最廣泛的內部應用程式上都能運作，Cloudflare 採用 Managed OAuth。只要將 Access 部署在舊有內部應用程式的前端，就能立即讓它們支援 Agent——無需修改任何程式碼，無需進行改造，而是直接獲得相容性。
這是使用者的 Agent，無需服務帳號與靜態憑證
Agent 需要在組織內部代表使用者行動，而目前最常見的 anti-pattern 之一，就是為 Agent 和 MCP Server 建立服務帳號（Service Account），並使用靜態憑證進行驗證。這在簡單的 use case 和快速 prototype 中有其價值，Cloudflare Access 也支援服務憑證（Service Tokens）以應對這類需求。
但當需要細緻的存取控制和稽核日誌時，服務帳號的做法很快就會暴露出其局限性。Cloudflare 認為，Agent 執行的每一個動作都必須能輕易歸因到發起它的人，且 Agent 只能執行其人類操作者同樣被授權執行的動作。 服務帳號和靜態憑證會成為歸因失效的節點，因此所有行動都透過服務帳號執行的 Agent，容易產生混淆代理人問題（Confused Deputy Problem），且稽核日誌中的行為來源看起來都是 Agent 本身，而非真正的人類操作者。
為了兼顧安全性與問責性，Agent 必須使用能夠表達「使用者—Agent 關係」的 Security Primitive。OAuth 是請求並委派第三方存取權的業界標準協議。Agent 就能以使用者身分與 API 溝通，Token 的範圍綁定至使用者身分，從而確保存取控制正確套用，稽核日誌也能正確將行為歸因至最終使用者。
標準為王：Agent 應如何在 web fetch 工具中採用 RFC 9728
RFC 9728 是讓 Agent 能探索驗證位置與方式的 OAuth 標準，它規範了這些資訊的存放位置與結構。這份 RFC 於 2025 年 4 月正式生效，並迅速被 Model Context Protocol（MCP）採納——MCP 現在要求 Server 端與 Client 端都必須支援它。
但在 MCP 之外，Agent 應該為一個更核心的 use case 採用 RFC 9728，向受 OAuth 保護的網頁發出請求，以及向一般 REST API 發出請求。
大多數 Agent 都有一個用於發出基本 HTTP 請求的工具，通常稱為 「web fetch」工具。它類似於在 JavaScript 中使用 fetch() API，通常還會對回應進行額外的後處理。這讓使用者可以把一個網址貼給 Agent，然後讓 Agent 去查詢其內容。
然而，目前大多數 Agent 的 web fetch 工具並不會對網址回傳的 www-authenticate 標頭採取任何行動。底層模型或許會自行解析回應標頭並找出解法，但工具本身並不會主動追蹤 www-authenticate、查詢 /.well-known/oauth-authorization-server，並在 OAuth 流程中扮演 Client 端的角色。事實上，Cloudflare 認為 Agent 應該直接沿用使用者原有的身分驗證機制，而這也是目前 Agent 以遠端 MCP Client 身分運作時所採用的模式。
為了示範這一點，Cloudflare 提交了一個 Draft Pull Request，修改了 Opencode 的 web fetch 工具以展示實際效果。在發出請求之前，修改後的工具會先檢查是否已有憑證；若有，則直接用於發出初始請求。若工具收到帶有 www-authenticate 標頭的 401 或 403 回應，它會請求使用者授權，以便進入伺服器的 OAuth 流程。
以下是 OAuth 流程的運作方式：若使用者給 Agent 一個受 OAuth 保護且符合 RFC 9728 的網址，Agent 會提示人類使用者授權開啟授權流程……將人類使用者導向登入頁面……然後進入一個同意對話框，提示人類使用者授予 Agent 存取權。
以下是 OAuth 流程的實際運作方式：使用者把一個受 OAuth 保護且符合 RFC 9728 的網址交給 Agent 後，Agent 會先提示使用者授權，接著引導他們前往登入頁面，最後出現同意對話框，讓使用者決定是否授予 Agent 存取權：
一旦人類使用者授予 Agent 存取權，Agent 就會使用收到的 Token 發出已驗證的請求。
從 Codex、Claude Code 到 Goose 等任何 Agent 都可以實作這套機制，且完全沒有任何 Cloudflare 專屬的內容，全部都是基於 OAuth 標準建構的。
Cloudflare 認為這個流程非常有力，而支援 RFC 9728 能幫助 Agent 完成的工作遠不止基本的 web fetch 請求。若某個 REST API 支援 RFC 9728（且 Agent 也支援），Agent 就擁有了開始對該 API 發出已驗證請求所需的一切。若該 REST API 同時支援 RFC 9727，Client 端甚至可以自行探索 REST API 端點目錄，無需額外文件、Agent 技能、MCP Server 或 CLI 即可完成更多任務。
這些元素在與 Agent 協作時各有其重要角色——Cloudflare 自身提供了適用於 Cloudflare API 的 MCP Server（使用 Code Mode 建置）、Wrangler CLI、Agent Skills 以及一個 Plugin。但支援 RFC 9728 能確保即使這些工具都未預先安裝，Agent 仍有清晰的前進路徑。如果 Agent 擁有執行未受信任程式碼的 sandbox 環境，它就可以直接撰寫並執行程式碼，呼叫人類使用者已授予其存取權的 API。Cloudflare 正在為自己的 API 推進這項支援，以協助 Agent 了解如何使用 Cloudflare。
即將推出：跨多個 Cloudflare 帳號共用單一身分提供者
在 Cloudflare 內部，應用程式部署在數十個不同的 Cloudflare 帳號中，這些帳號都屬於同一個組織——這是一種新推出的管理方式，讓管理員能夠跨多個 Cloudflare 帳號統一管理使用者、組態設定並查看分析資料。Cloudflare 面臨的挑戰和許多客戶相同，每個 Cloudflare 帳號都必須分別設定 IdP，因此 Cloudflare Access 使用的是自己的身分提供者。這項身分驗證政策必須在整個組織內一致執行，避免因個別帳號設定疏失而產生安全漏洞。例如，不應該出現某個 Cloudflare 帳號僅允許使用一次性密碼（One-Time PIN）登入，而未強制透過企業單一登入（SSO）驗證的情況。
為了解決這個問題，Cloudflare 目前正在開發跨帳號共用身分提供者的功能，讓組織能夠指定一個主要 IdP，供組織內所有帳號使用。
當組織內新建立 Cloudflare 帳號時，管理員只需一鍵即可設定與主要 IdP 的橋接，使跨帳號的 Access 應用程式都受同一個身分提供者保護。這免除了逐帳號手動設定 IdP 的必要，對於擁有眾多團隊和成員、各自管理自己帳號的組織而言，免除了管理麻煩，也很難隨著組織規模擴大而有效維護的問題。
後續展望
在各個企業中，來自各種角色與業務職能的人員，現在都在使用 Agent 建置內部應用程式，並期待 Agent 能夠存取來自內部應用程式的資料。Cloudflare 正回應這波內部軟體開發的跳躍式成長，持續讓 Workers Platform 與 Cloudflare One 更緊密地協同運作，以便更輕鬆地在 Cloudflare 上建置並保護內部應用程式。
期待更多即將推出的功能，包括：
- Cloudflare Access 與 Cloudflare Workers 之間更直接的整合，無需手動驗證 JWT 或記住特定 Worker 暴露的多條 route
- wrangler dev –tunnel——一個簡便的方式，讓使用者在建置新功能時，能在正式部署前將本機 dev server 分享給他人
- 適用於 Cloudflare Access 與整個 Cloudflare API 的命令列介面（CLI）
- 更多將在 Agents Week 2026 期間發布的公告
立即為 Cloudflare Access 後方的內部應用程式啟用 Managed OAuth
Managed OAuth 現已面向所有 Cloudflare 客戶開放公開測試版。前往 Cloudflare 儀表板，即可為 Access 應用程式啟用此功能。無論應用程式是建置於 Cloudflare Workers 之上，還是託管於其他地方，都可以使用。如果還未在 Workers Platform 上建置內部應用程式——這是團隊從零到部署上線（並受到保護）最快速的途徑。
若您有興趣為企業導入 Managed OAuth 或相關 AI Agent 安全治理方案，歡迎聯繫極風雲創技術團隊。