> ## Content Index > Fetch the complete content index at: https://growthhackers.tw/llms.txt > Use this file to discover other available public pages before exploring further. # AI agent 資安風險最大的破口不在模型：你把 AI 做的報表轉給同事，等於把它讀過的資料庫一起轉出去 - URL: https://growthhackers.tw/blog/ai-agent-data-leak-permission/ - Published: 2026-08-08T01:00:00.000Z - Updated: 2026-08-08T01:00:00.000Z - Description: 你叫 AI 讀客戶名單做成簡報，順手丟進部門群組。那份簡報裡有多少東西是同事本來不該看的？你不知道，AI 也不會告訴你。MCP 只管 agent 能呼叫哪些工具，不管它實際看過哪些資料。解碼 Cloudflare 開源的 AI 工作台，附 GitHub 實查（Apache-2.0、4,598 stars）與現階段的但書。 - Author: Lewis wang - Tags: AI agent, AI 資安, 企業 AI, 開源, Cloudflare 先講一個場景。 你叫 AI 去讀公司的客戶名單，整理成一份會員貢獻度分析簡報。它做得很好，圖表漂亮，結論清楚。你順手把簡報丟進部門群組，讓大家先看。 問題來了。 那份簡報裡面，到底有多少東西是本來只有你能看的？ 你不知道。AI 也不會告訴你。 這件事是 Cloudflare 在 2026 年 8 月 5 日那篇公告裡順手講出來、但幾乎沒有人在轉的一段。大家都在轉「Cloudflare 開源了一套全公司在用的 AI 工作台」，我覺得那反而是比較不重要的部分。 ## 這是廠商自己發的公告，所以我去查了 來源是 [Cloudflare 官方部落格《Cloudflare OS: an open platform for agents, apps, and work》](https://blog.cloudflare.com/cloudflare-os/?ref=growthhackers.tw)，2026 年 8 月 5 日發布。 它是產品公告，不是獨立評測。 裡面的「數千人每天在用」「跨所有部門、很多不是工程師」，全部是 Cloudflare 自己說的，沒有第三方核驗。他們資訊長 Sam Rhea 的 [搭配貼文](https://blog.cloudflare.com/how-we-use-ai-with-cloudflare-os?ref=growthhackers.tw) 數字更漂亮：業務團隊單月省下超過 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 新規格解讀](https://growthhackers.tw/blog/mcp-stateless-core-spec/)，那篇把協定本身拆得比較細。 ![MCP 只檢查 agent 能呼叫哪些工具，沒有記錄它實際看過哪些資料](https://growthhackers.tw/content/images/2026/08/inline-mcp-blindspot-v1.png) MCP 只檢查 agent 能呼叫哪些工具，沒有記錄它實際看過哪些資料 ## 解法一：權限跟著「看過什麼」走 Cloudflare 的做法，我認為是這篇最值得抄的觀念。 他們讓系統記錄 agent 觀察過的每一個資源。這份紀錄會黏在 agent 身上，也黏在它產出的東西上。 當另一個人要打開這個工作區、要跟這個 agent 對話、或是要看它做出來的東西時，系統會反過來驗證：**那個人**對這些原始資源有沒有權限。 沒有，就看不到。 這就像從「看你有沒有大門鑰匙」，進化到「看你有沒有資格知道這件事」。 再換一個台灣人更熟的講法：產銷履歷。 以前的權限管理，管的是誰能進倉庫。產銷履歷管的是另一件事：這道菜端出來，它用了哪些食材、來自哪一批。菜可以端給誰吃，看的是食材，不是端菜的人有沒有廚房鑰匙。 Cloudflare 做的就是幫每一份 AI 產出貼上食材標籤，而且這張標籤撕不掉。 而且同一份紀錄還會往後管。一個 agent 只要讀過敏感資料，系統就可以限制它後續不准把資料往外送、不准邀請新的協作者、不准把工作轉交給另一個 agent。 如果你問我，這個設計最聰明的地方在於：**它把責任從使用者身上拿走了。** 你不需要教全公司每一個人「分享前請先檢查裡面有沒有機密」。這種教育訓練做了十年也沒用，因為人就是會忘。 它把這件事變成平台的預設行為。 ![權限跟著「看過什麼」走：每份產出都黏著一張它讀過哪些系統的履歷標籤](https://growthhackers.tw/content/images/2026/08/inline-traceability-label-v1.png) 權限跟著「看過什麼」走：每份產出都黏著一張它讀過哪些系統的履歷標籤 ## 解法二：別再發 API key 了 原文有一句講得很直白：大家開始在工作上用 AI，第一個要求幾乎都是「可不可以給我 API key」。 因為不給金鑰，AI 就碰不到公司系統，那就沒什麼用。 但金鑰這東西的問題是：權限通常過大、活得太久、難限制、難稽核。 你給行銷同事一把可以讀 GA4 的金鑰，他放在自己電腦的設定檔裡，半年後他離職了，那把鑰匙還在。這種事我相信不少台灣公司現在正在發生，只是沒人想去翻。 Cloudflare 的做法是兩層： 第一層，**agent 預設權限為零**。進來什麼都碰不到，要用什麼再申請，你核准它才拿得到。而且拿到的不是金鑰本身，是一個「代表這個權限」的代號。金鑰由他們叫做 Gatekeeper 的東西保管，agent 和它寫出來的程式碼從頭到尾碰不到。 第二層，Gatekeeper 的細緻度。這才是重點： ► 只給某一個 repo，不是整個 GitHub 帳號 ► 只准讀 issue，不准讀原始碼 ► 可以遮蔽特定欄位 ► 可以限流 ► 合併程式碼之前，要先跑審批 你看出差別了嗎？ 以前你面對的是「給不給金鑰」的二選一。要嘛他用不了 AI，要嘛他拿到一把可以開全公司的萬能鑰匙。 現在你可以說：可以，但你只能看這一櫃，而且不能拍照。 換成電商的場景更好懂。你要讓 AI 幫你跑退貨分析，它需要的是訂單狀態和退貨原因，不需要收件人姓名、電話、地址。以前的做法是把整張訂單表開給它，因為分開太麻煩。現在你可以只開需要的欄位。 說到底，能不能這樣切，取決於你對自己的資料有多少控制權。這件事我在 [AI Agent 時代新護城河](https://growthhackers.tw/blog/ai-agent-first-party-data-moat/) 那篇談過。 還有一個小設計值得記：他們把「分享 app」跟「分享藍圖」分開。分享 app 是大家共用同一份資料一起做事；分享藍圖只給對方程式碼，不含資料、不含對話紀錄、不含憑證、不含已經連上的資源。對方拿到之後可以自己叫 AI 改成他要的樣子，不用開需求單排隊等你。 苦於內部需求塞車的人，應該對這句很有感。 ![從一把萬能鑰匙，變成一組可以逐項調整的權限](https://growthhackers.tw/content/images/2026/08/inline-master-key-vs-gatekeeper-v1.png) 從一把萬能鑰匙，變成一組可以逐項調整的權限 ## 開源是真的，但它不是今天就能用的產品 回到前面說要查的那件事。這段一定要講，不然就是幫廠商吹。 先講好消息，我實際查到的： ★ `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 指令怎麼寫](https://growthhackers.tw/blog/codex-goal-command-verifiable-contract/) 那篇展開過：agent 做不好，八成不是模型笨，是你的目標沒寫成可驗證的合約。 ## 我在傳產學到的那件事，現在要重寫一次 我在雨傘產業待過七年，工廠、品牌、百貨專櫃都走過一輪，後來才從傳產轉到數位行銷。 那個年代還沒有 AI，但「這份資料可以給誰看」這件事一樣存在。成本結構、通路條件、哪個客戶拿到的價格比較好，哪些能攤在會議桌上、哪些只能主管之間講，靠的是人腦記得，還有嘴巴閉緊。 制度不是不存在。是它長在人身上。 現在團隊裡多了一個成員，它讀得比誰都快、整理得比誰都漂亮，而且完全沒有「這句話我不該說」的直覺。 所以權限這件事，第一次真的得寫成規則，不能再靠默契。 ## 台灣公司這個月可以動的四件事 先別管要不要導入 Cloudflare OS。老實說，台灣多數中小企業不會自己部署這套，也不需要。 但下面四件事，不用任何平台就能做。 ► **第一：把散在外面的 API key 抓回來。** 去問行銷、問客服、問營運，誰手上有 GA4、廣告後台、電商後台、資料庫的金鑰？那把金鑰的權限範圍是什麼？多久沒換過？離職同事的那一把收回來了嗎？光是把這張表列出來，多數公司就會冒冷汗。 ► **第二：回頭看最近一個月的部門群組。** 挑三份 AI 做出來的報表或簡報，回頭問一句：這裡面的數字原始出處是哪個系統？群組裡每一個人，都有權限看那個系統嗎？ ► **第三：做一張「AI 產出來源清單」。** 規定從今天起，凡是要往外發的 AI 產出，檔名旁邊要註明它讀過哪些系統。土法煉鋼，一行字就好。做兩週你就會看到，有些報表的來源根本沒人說得出來。大家都在擔心資料會不會被拿去訓練模型，但真正每天在發生的，是下游的轉發。 ► **第四：把「可以看什麼」跟「可以做什麼」分開設定。** 就算你用的只是 ChatGPT 加幾個連接器，這件事今天就能做：讀取權限開寬一點沒關係，寫入和對外發送的權限要卡死。AI 讀錯資料，頂多分析歪掉；AI 亂發東西出去，那是事故。 這四件事做完，再談要買哪個平台。順序反過來，你買的就只是一個更貴的破口。 如果你想看更完整的內部規範該長什麼樣，我整理過 [給電商老闆的三條 AI 治理](https://growthhackers.tw/blog/code-with-claude-london-2026-day2-recap/)，可以搭著看。 ## 常見問題 **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](https://blog.cloudflare.com/cloudflare-os/?ref=growthhackers.tw)，Cloudflare 官方部落格，2026 年 8 月 5 日。（請注意：此為 Cloudflare 自家產品公告，非獨立評測，文中成效宣稱均為該公司自評） - [How we use AI with Cloudflare OS](https://blog.cloudflare.com/how-we-use-ai-with-cloudflare-os?ref=growthhackers.tw)，作者 Sam Rhea（Cloudflare 資訊長）。（同為 Cloudflare 自述） - GitHub：[cloudflare/cloudflare-os](https://github.com/cloudflare/cloudflare-os?ref=growthhackers.tw)、[cloudflare/cloudflare-os-starter](https://github.com/cloudflare/cloudflare-os-starter?ref=growthhackers.tw)、[cloudflare/capnweb](https://github.com/cloudflare/capnweb?ref=growthhackers.tw)。授權條款、星數、貢獻者與最後更新時間為 2026 年 8 月 6 日實際查詢結果，數字會隨時間變動。 - Cloudflare 官方文件：[Dynamic Workers](https://developers.cloudflare.com/dynamic-workers/?ref=growthhackers.tw)、[Durable Object Facets](https://developers.cloudflare.com/dynamic-workers/usage/durable-object-facets/?ref=growthhackers.tw)。（文件未標示是否已正式上線，亦未列出價格） **協作聲明與免責** 這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 `[來源名稱](URL)` 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。 內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。