在現代的軟體整合中，OAuth 是一種標準的授權協議，讓第三方應用程式在不獲知使用者密碼的情況下，能代表使用者存取特定資源。為了定義應用程式可以做什麼，OAuth 使用了 Scope（權限範圍）的概念。例如，一個應用程式可能請求讀取使用者詳細資料的權限，或是寫入伺服器設定的權限。然而，在傳統的授權流程中，權限通常採取全有或全無的模式：使用者在授權畫面看到請求清單後，要麼全部同意，要麼全部拒絕。
這種機制在面對 AI 代理程式（AI Agents）時產生了嚴重的衝突。AI 代理程式與傳統應用程式的不同之處在於其功能的高度動態性。開發者在設計 AI 代理程式時，往往無法預測使用者會要求它執行哪些操作，因此傾向於請求一個較寬泛的權限集合，以確保代理程式在理論上能完成所有可能的任務。
然而，這導致了一個兩難困境。如果開發者只請求最小限度的權限，可能會導致某些進階功能無法使用；但如果請求所有可能的權限，使用者在看到權限清單時會感到不安，擔心 AI 擁有過高權限（例如：一個只需要比對產品庫存的 AI 卻請求修改價格的權限），進而直接放棄授權，導致使用者流失。
為了打破這個僵局，Cloudflare 推出了可選權限範圍（Optional OAuth Scopes）功能。這項更新允許開發者在配置 OAuth 用戶端時，將權限分為必要（Required）與可選（Optional）兩類。在授權畫面中，使用者不再是被迫接受整套方案，而是可以根據自己的信任程度，手動取消勾選那些被標記為可選的權限，而僅保留必要權限以維持基本功能。
從技術實作來看，開發者現在可以在配置中使用 optional_scopes 陣列來指定哪些權限是可以被捨棄的。需要注意的是，系統會根據單次授權流程中實際請求的權限來評估，而非對照用戶端配置的所有權限。例如，若一個用戶端配置了四個權限，但本次僅請求其中兩個，使用者也只會看到這兩個選項。
這項變動的核心在於將權限的最終決定權交還給使用者，但同時賦予開發者定義底線的能力。標記為必要的權限確保了應用程式運作的最低需求，而可選權限則提供了靈活的擴展空間。
雖然部分平台如 GitHub 或 Google 早已提供類似的粒度權限控制，但 Cloudflare 的做法是讓開發者能主動定義哪些權限是可被捨棄的。這在技術層面上並未改變 OAuth 2.0 的標準（RFC 6749 規範早已允許授權伺服器發放比請求範圍更小的權限令牌），而是將這種靈活性直接呈現在使用者介面上，以適應 AI 代理程式普及後的授權需求。
對於開發者而言，這意味著程式碼邏輯必須從假設權限全部獲取，轉向動態檢查權限。當使用者取消勾選可選權限時，發放的存取令牌（Access Token）將僅包含被授予的權限。如果應用程式在未檢查權限的情況下直接調用 API，將會觸發 403 錯誤。
Cloudflare 建議開發者採取優雅降級（Graceful Degradation）的設計模式：當發現缺乏某項寫入權限時，應用程式應直接禁用該功能並明確告知使用者，而非讓系統崩潰或顯示模糊的錯誤訊息。對於 AI 代理程式，理想的模式是將讀取權限設為必要，將寫入權限設為可選，在執行動作前先檢查權限集，若缺乏授權則停止操作，而非嘗試繞過限制。
這項更新是 Cloudflare 針對 AI 整合生態系一系列舉措的一部分。隨著 MCP（Model Context Protocol，模型上下文協定）等標準的演進，如何定義 AI 代理程式的身份、連接方式以及權限粒度，已成為確保 AI 安全部署的關鍵。透過降低授權門檻並提高透明度，開發者可以在維持功能強大與保護使用者隱私之間取得更好的平衡。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。