AI agent 資安風險最大的破口不在模型：你把 AI 做的報表轉給同事，等於把它讀過的資料庫一起轉出去

先講一個場景。

你叫 AI 去讀公司的客戶名單，整理成一份會員貢獻度分析簡報。它做得很好，圖表漂亮，結論清楚。你順手把簡報丟進部門群組，讓大家先看。

問題來了。

那份簡報裡面，到底有多少東西是本來只有你能看的？

你不知道。AI 也不會告訴你。

這件事是 Cloudflare 在 2026 年 8 月 5 日那篇公告裡順手講出來、但幾乎沒有人在轉的一段。大家都在轉「Cloudflare 開源了一套全公司在用的 AI 工作台」，我覺得那反而是比較不重要的部分。

這是廠商自己發的公告，所以我去查了

來源是 Cloudflare 官方部落格《Cloudflare OS: an open platform for agents, apps, and work》，2026 年 8 月 5 日發布。

它是產品公告，不是獨立評測。

裡面的「數千人每天在用」「跨所有部門、很多不是工程師」，全部是 Cloudflare 自己說的，沒有第三方核驗。他們資訊長 Sam Rhea 的 搭配貼文 數字更漂亮：業務團隊單月省下超過 10,000 小時、30 天內做出 4,000 多個小工具、程式碼審查 agent 四個月擋下 16,000 次合併。

漂亮歸漂亮，這些數字沒有對照組。你不知道同一段時間裡，有多少改善是別的原因帶來的。所以我不會拿它們當論據。

不過這篇跟一般廠商公告有一個差別：它說它開源了。而開源這種宣稱，是可以查的。

我去把它的 GitHub 整個翻了一遍，包括授權條款全文。結論放在文章後半，先講重點：設計拿來學，數字不採用。

好，交代完了，來講真正值錢的那一段。

破口：MCP 管得住工具，管不住資料

現在公司裡導入 AI，主流做法是接 MCP（Model Context Protocol，模型上下文協定）。

MCP 解決了一個很實際的問題：以前你要讓 AI 讀公司系統，得直接把 API key 交給它。有了 MCP，金鑰可以留在 MCP server 手上，只對外開放幾個定義好的工具。

聽起來安全多了。實際上也真的安全多了。

但 Cloudflare 這篇點出後面那半句：

MCP 只告訴你 agent「能呼叫哪些工具」，沒告訴你它「實際看過哪些資料」。

差別在哪？我用原文的例子。

一個 agent 去讀了資料倉儲裡一張很敏感的表，然後做成一個即時儀表板。這一步完全合法，因為你有權限。

接著你把儀表板分享出去。

那一刻，你等於把那張表也分享出去了。對方本來沒有權限看，現在透過你的儀表板看到了。

翻成台灣公司的日常：

你們家客服主管有全會員的消費紀錄權限，行銷企劃沒有。客服主管叫 AI 把高價值客戶的行為特徵整理成一份簡報，丟到行銷群組讓大家參考。

那份簡報裡有沒有夾帶到個資？有沒有夾帶到單一客戶就能被辨認出來的欄位組合？

沒有人檢查。因為以前的權限系統，管的是「誰能打開哪個系統」，不是「這份 PowerPoint 裡的東西是從哪裡來的」。

以前資料要外流，得有人主動去撈、去下載、去轉寄，過程中至少留下一道痕跡。

現在 AI 幫你撈、幫你整理、幫你美化，你只是按了一下分享。

整條路上沒有一個人覺得自己在做壞事。

想搞懂 MCP 這層到底管什麼、不管什麼，我之前寫過 MCP stateless 新規格解讀，那篇把協定本身拆得比較細。

解法一：權限跟著「看過什麼」走

Cloudflare 的做法，我認為是這篇最值得抄的觀念。

他們讓系統記錄 agent 觀察過的每一個資源。這份紀錄會黏在 agent 身上，也黏在它產出的東西上。

當另一個人要打開這個工作區、要跟這個 agent 對話、或是要看它做出來的東西時，系統會反過來驗證：那個人對這些原始資源有沒有權限。

沒有，就看不到。

這就像從「看你有沒有大門鑰匙」，進化到「看你有沒有資格知道這件事」。

再換一個台灣人更熟的講法：產銷履歷。

以前的權限管理，管的是誰能進倉庫。產銷履歷管的是另一件事：這道菜端出來，它用了哪些食材、來自哪一批。菜可以端給誰吃，看的是食材，不是端菜的人有沒有廚房鑰匙。

Cloudflare 做的就是幫每一份 AI 產出貼上食材標籤，而且這張標籤撕不掉。

而且同一份紀錄還會往後管。一個 agent 只要讀過敏感資料，系統就可以限制它後續不准把資料往外送、不准邀請新的協作者、不准把工作轉交給另一個 agent。

如果你問我，這個設計最聰明的地方在於：它把責任從使用者身上拿走了。

你不需要教全公司每一個人「分享前請先檢查裡面有沒有機密」。這種教育訓練做了十年也沒用，因為人就是會忘。

它把這件事變成平台的預設行為。

解法二：別再發 API key 了

原文有一句講得很直白：大家開始在工作上用 AI，第一個要求幾乎都是「可不可以給我 API key」。

因為不給金鑰，AI 就碰不到公司系統，那就沒什麼用。

但金鑰這東西的問題是：權限通常過大、活得太久、難限制、難稽核。

你給行銷同事一把可以讀 GA4 的金鑰，他放在自己電腦的設定檔裡，半年後他離職了，那把鑰匙還在。這種事我相信不少台灣公司現在正在發生，只是沒人想去翻。

Cloudflare 的做法是兩層：

第一層，agent 預設權限為零。進來什麼都碰不到，要用什麼再申請，你核准它才拿得到。而且拿到的不是金鑰本身，是一個「代表這個權限」的代號。金鑰由他們叫做 Gatekeeper 的東西保管，agent 和它寫出來的程式碼從頭到尾碰不到。

第二層，Gatekeeper 的細緻度。這才是重點：

► 只給某一個 repo，不是整個 GitHub 帳號
► 只准讀 issue，不准讀原始碼
► 可以遮蔽特定欄位
► 可以限流
► 合併程式碼之前，要先跑審批

你看出差別了嗎？

以前你面對的是「給不給金鑰」的二選一。要嘛他用不了 AI，要嘛他拿到一把可以開全公司的萬能鑰匙。

現在你可以說：可以，但你只能看這一櫃，而且不能拍照。

換成電商的場景更好懂。你要讓 AI 幫你跑退貨分析，它需要的是訂單狀態和退貨原因，不需要收件人姓名、電話、地址。以前的做法是把整張訂單表開給它，因為分開太麻煩。現在你可以只開需要的欄位。

說到底，能不能這樣切，取決於你對自己的資料有多少控制權。這件事我在 AI Agent 時代新護城河 那篇談過。

還有一個小設計值得記：他們把「分享 app」跟「分享藍圖」分開。分享 app 是大家共用同一份資料一起做事；分享藍圖只給對方程式碼，不含資料、不含對話紀錄、不含憑證、不含已經連上的資源。對方拿到之後可以自己叫 AI 改成他要的樣子，不用開需求單排隊等你。

苦於內部需求塞車的人，應該對這句很有感。

開源是真的，但它不是今天就能用的產品

回到前面說要查的那件事。這段一定要講，不然就是幫廠商吹。

先講好消息，我實際查到的：

★ cloudflare/cloudflare-os：存在、公開。授權是 Apache-2.0，不是那種掛著開源名字、實際限制商用的授權（我把 LICENSE 全文拉下來確認過，尾段沒有附加條款）。2026 年 8 月 6 日查詢時是 4,598 顆星、333 個 fork、11 位貢獻者，TypeScript 程式碼約 5.6 MB，當天還有新的 commit，26 個 issue 開著。不是空殼，也不是只放一份 README 就叫開源。
★ cloudflare/cloudflare-os-starter：存在，同樣 Apache-2.0，但只有 188 KB，是示範部署用的殼。
★ cloudflare/capnweb（他們的 RPC 系統 Cap'n Web）：存在，MIT 授權，2025 年 6 月就建立了，不是為了這次公告臨時生出來的。
★ Sam Rhea 確實掛 Cloudflare 資訊長（CIO）。原文說為了這個專案新做的 Dynamic Workers 和 Durable Object Facets，官方文件也查得到，只是文件上沒寫是否已正式上線，也沒有價格。

所以「開源」這兩個字，它是真的做到了。

壞消息在後面。

原文自己寫得很清楚：現在的狀態是自行部署。你需要一個 Cloudflare 帳號，還需要工程投入。「在 dashboard 上的全託管產品」還在做，容器支援還在做，Slack 整合也還在做。

更誠實的是他們自己的 GitHub README，那上面有一行公告裡沒寫的話：

WARNING: Early access

README 說這個 repo 其實是第二版，是把第一版學到的東西整個打掉重寫，「非常能用，但還有很多粗糙的邊角」。

還有，Cloudflare 同時推了兩家策略夥伴 Presidio 和 Happy Cog，說可以幫你客製導入。請注意那是付費的商業服務，不是免費支援。

最後補一個 Sam Rhea 貼文裡的自白，我認為它比前面那些數字有用得多。他們一開始只是把工程師的工具換個友善一點的介面丟給全公司，結果長出「一堆為了做而做、找不到問題可解的 vibe coded 小 app」。後來改成人工顧一個信箱、一件一件接需求，他自己形容那段過程「很痛苦」，但也就是那樣才問出真正該自動化的流程。

這段之所以值得信，是因為它對 Cloudflare 沒好處。

所以要抄的不是「趕快部署一套」，是「先用最笨的方法問出哪幾條流程真的值得自動化」。

那句值得記住的話

原文有一句用粗體強調，我認為是整篇對非工程師最重要的一句：

「如果你能自己做一個工具來完成某件事，agent 就能在你不在的時候用你的工具完成它。」

很多人聽到自動化，想到的是 AI 來取代你。這句話講的是另一件事：你把自己的判斷做成一個工具，這個工具在你睡覺、在你開會、在你休假的時候，繼續照你的規矩做事。

前提是，你得先把自己的規矩講清楚。這件事我在 Codex goal 指令怎麼寫 那篇展開過：agent 做不好，八成不是模型笨，是你的目標沒寫成可驗證的合約。

我在傳產學到的那件事，現在要重寫一次

我在雨傘產業待過七年，工廠、品牌、百貨專櫃都走過一輪，後來才從傳產轉到數位行銷。

那個年代還沒有 AI，但「這份資料可以給誰看」這件事一樣存在。成本結構、通路條件、哪個客戶拿到的價格比較好，哪些能攤在會議桌上、哪些只能主管之間講，靠的是人腦記得，還有嘴巴閉緊。

制度不是不存在。是它長在人身上。

現在團隊裡多了一個成員，它讀得比誰都快、整理得比誰都漂亮，而且完全沒有「這句話我不該說」的直覺。

所以權限這件事，第一次真的得寫成規則，不能再靠默契。

台灣公司這個月可以動的四件事

先別管要不要導入 Cloudflare OS。老實說，台灣多數中小企業不會自己部署這套，也不需要。

但下面四件事，不用任何平台就能做。

► 第一：把散在外面的 API key 抓回來。
去問行銷、問客服、問營運，誰手上有 GA4、廣告後台、電商後台、資料庫的金鑰？那把金鑰的權限範圍是什麼？多久沒換過？離職同事的那一把收回來了嗎？光是把這張表列出來，多數公司就會冒冷汗。

► 第二：回頭看最近一個月的部門群組。
挑三份 AI 做出來的報表或簡報，回頭問一句：這裡面的數字原始出處是哪個系統？群組裡每一個人，都有權限看那個系統嗎？

► 第三：做一張「AI 產出來源清單」。
規定從今天起，凡是要往外發的 AI 產出，檔名旁邊要註明它讀過哪些系統。土法煉鋼，一行字就好。做兩週你就會看到，有些報表的來源根本沒人說得出來。大家都在擔心資料會不會被拿去訓練模型，但真正每天在發生的，是下游的轉發。

► 第四：把「可以看什麼」跟「可以做什麼」分開設定。
就算你用的只是 ChatGPT 加幾個連接器，這件事今天就能做：讀取權限開寬一點沒關係，寫入和對外發送的權限要卡死。AI 讀錯資料，頂多分析歪掉；AI 亂發東西出去，那是事故。

這四件事做完，再談要買哪個平台。順序反過來，你買的就只是一個更貴的破口。

如果你想看更完整的內部規範該長什麼樣，我整理過 給電商老闆的三條 AI 治理，可以搭著看。

常見問題

Q：員工用 AI 會不會把公司資料外洩？破口通常在哪裡？
A：多數公司防的是「資料會不會被拿去訓練模型」，但實務上更常發生的是下游外洩：AI 讀了你有權限的資料，做成報表或簡報，你再把成品轉發給沒有原始權限的同事。這個過程完全不觸發任何資安警報，因為傳統權限系統管的是「誰能進哪個系統」，不管「這份檔案裡的內容來自哪裡」。

Q：接了 MCP 是不是就有權限控管了？
A：有一部分。MCP 讓金鑰留在 server 端、只對外開放定義好的工具，比直接發 API key 安全很多。但依 Cloudflare 這篇的說法，MCP 只描述 agent「能呼叫哪些工具」，不記錄它「實際觀察過哪些資源」。所以資料被 agent 讀出來之後往哪裡去，MCP 本身管不到。

Q：不給 AI API key 就不能用，給了又怕出事，怎麼辦？
A：這題本來就不該是二選一。Cloudflare 的做法是 agent 預設零權限，金鑰交給一個叫 Gatekeeper 的中介層保管，agent 和它產生的程式碼完全碰不到金鑰，只拿到「代表某個權限」的代號。Gatekeeper 可以限定到單一 repo、只准讀 issue 不准讀原始碼、遮蔽特定欄位、限流、要求合併前先審批。就算你沒有這套系統，觀念一樣能用：把讀取和寫入的權限分開，欄位能不開就不開。

Q：Cloudflare OS 真的開源嗎？授權是什麼？
A：是。經實查，cloudflare/cloudflare-os 與 cloudflare/cloudflare-os-starter 都採 Apache-2.0 授權，不是限制商用的 BSL 類授權；相關的 RPC 系統 cloudflare/capnweb 採 MIT。核心 repo 有實際的 TypeScript 程式碼（約 5.6 MB）與多位貢獻者，不是空殼。

Q：現在就能拿來用嗎？中小企業適合嗎？
A：現階段是自行部署，需要 Cloudflare 帳號加上工程投入，而且 repo 的 README 自己標示為「early access、還有很多粗糙的邊角」。dashboard 上的全託管版本、容器支援、Slack 整合都還在開發中。Cloudflare 另外推了 Presidio 與 Happy Cog 兩家付費夥伴協助導入。對沒有工程團隊的台灣中小企業，比較務實的做法是先照文末四件事盤點自己的權限現況，而不是急著部署一套平台。

資料來源

• Cloudflare OS: an open platform for agents, apps, and work，Cloudflare 官方部落格，2026 年 8 月 5 日。（請注意：此為 Cloudflare 自家產品公告，非獨立評測，文中成效宣稱均為該公司自評）
• How we use AI with Cloudflare OS，作者 Sam Rhea（Cloudflare 資訊長）。（同為 Cloudflare 自述）
• GitHub：cloudflare/cloudflare-os、cloudflare/cloudflare-os-starter、cloudflare/capnweb。授權條款、星數、貢獻者與最後更新時間為 2026 年 8 月 6 日實際查詢結果，數字會隨時間變動。
• Cloudflare 官方文件：Dynamic Workers、Durable Object Facets。（文件未標示是否已正式上線，亦未列出價格）

協作聲明與免責

這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 [來源名稱](URL) 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。

內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。