AI

Cloudflare OS：Cloudflare 開源內部 AI 工作空間，用 Gatekeepers 為 Agent 加上權限護欄

Monday

本內容僅供參考，詳細使用規則與工具安全性與否，建議要進行相關安全性測試與評估

企業導入 AI Agent 時最頭痛的問題，往往不是模型夠不夠聰明，而是「該給它多少權限」：讓它讀 Google Drive？發 Slack？改 GitHub？每多一個整合，就多一個風險。Cloudflare OS（cloudflare/cloudflare-os）是 Cloudflare 原本在內部使用的 AI 生產力平台，它的答案是：預設什麼都不給，每個資源都必須由使用者明確「引介」給 Agent。專案目前約 11.3k stars，近期登上 AI 開源趨勢榜。

1. 專案背景與定位

Cloudflare OS 採 Apache-2.0 授權，自稱是 AI 生產力的「作業系統」，提供三件事：

  1. 預載公司脈絡的 Agent 聊天介面
  2. 沙盒化的應用開發——Agent 幫你做的小型個人應用稱為 Gadgets
  3. 名為 Gatekeepers 的安全框架，為 Agent 與應用加上護欄

README 開頭就掛著「Early access」警告：專案正在大量開發中，v2 是完全重寫的版本（8 月釋出），「能力很強，但仍有許多粗糙之處」。

2. 技術架構與核心設計

  • 以作業系統比喻的分層：workshop-backend 是「kernel」、gatekeeper-* 是「drivers」、workshop-frontend 是「shell」。
  • 每個工作空間都是一個 Durable Object：每個 Gadget 也各自由 Durable Object 支撐，天生支援即時多人協作。
  • Gadget 的雙層沙盒：伺服器端程式碼跑在 Dynamic Worker 中，預設無法連網，只能透過明確授予的 binding 存取外部資源；客戶端程式碼跑在受 CSP 與 iframe sandbox 限制的 iframe 中，透過 Cap'n Web RPC 與伺服器溝通。
  • Gatekeepers：每個外部服務（GitHub、Google、Slack、Notion 等）都有獨立的 Worker 包裝，負責 OAuth、縮小存取範圍、記錄每個動作，並對有副作用的操作要求人工核准。
  • 延遲核准與模擬執行：等待核准時，Gatekeeper 可以模擬有副作用的動作，讓 Agent 繼續往下工作，不必卡住整個流程。
  • 能力式存取（Capability-based access）：Agent 與 Gadget 預設沒有任何權限，使用者必須逐一「引介」資源。
  • Code Mode Agent：Agent 透過撰寫並執行程式碼片段來完成任務，並使用 Pi（pi-agent-core）統一多家 LLM 供應商。
  • Blueprints：可分享的應用範本，接收者會拿到屬於自己的程式碼副本；Gadget 程式碼以 isomorphic-git 版本控管。

3. 社群熱度與生態採用

約 11.3k stars、1.3k forks、900+ commits。由於出自 Cloudflare 官方且在公司內部實際使用，可信度與參考價值都比一般新專案高。部署方式有三種：本機 pnpm run-local（非生產用途）、透過 os.cloudflare.app/deploy 部署到自己的 Cloudflare 帳號，以及「即將推出」的自架 workerd。

值得注意的是，README 明說目前不接受外部貢獻，只收非常小、容易驗證的 bug fix——這是一個「開放原始碼」而非「開放治理」的專案。

4. 局限性與潛在風險

  • 早期版本：官方自己說 v2 仍有很多粗糙之處，不適合直接用於關鍵業務。
  • 平台綁定：架構深度依賴 Workers、Durable Objects、Dynamic Workers 等 Cloudflare 專屬服務，自架 workerd 方案尚未推出，遷移成本高。
  • OAuth 憑證集中：Gatekeepers 為每個服務保管 OAuth 憑證，它本身就成為高價值攻擊目標，Workers 帳號的存取控管必須非常嚴格。
  • 使用者登入機制未說明：README 沒有描述終端使用者如何登入 OS 本身，企業導入前需要自行確認與 SSO 的整合方式。
  • 模擬執行的語意風險：在核准前「模擬」副作用讓 Agent 繼續工作，若最終被拒絕，Agent 後續基於假設結果所做的決策也需要一併回滾。

5. 應用價值與適用場景

對已經在使用 Cloudflare 的團隊，Cloudflare OS 提供了一套可直接部署的「安全 Agent 工作空間」：員工可以讓 Agent 做個人的小工具（報表、儀表板、自動化），又不必擔心這些小工具亂連外網或濫用權限。對於正在設計企業 Agent 平台的架構師，它更是一份完整的權限模型參考實作。

Monday 的觀點與架構建議

  • Gatekeepers 是這個專案最值得學的部分：把每個外部服務的權限收斂到獨立的代理層，在這一層做 OAuth、範圍縮減、稽核與人工核准，Agent 本身永遠拿不到原始憑證。這個模式不管用什麼平台都可以實作。
  • 「預設無網路、只透過明確 binding 存取」的沙盒設計，比事後用規則去擋要可靠得多，值得所有讓 Agent 執行程式碼的系統效法。
  • 若採用延遲核准與模擬執行，務必設計好被拒絕時的補償流程。
  • 大型基礎設施公司把內部 Agent 平台開源，代表「Agent 安全框架」正在成為下一個標準化的競爭領域。

參考來源