AI Landing Lab｜ZCode／Coding Agent 完整對談稿 建議主標題 Coding Agent 會不會「整庫打包回傳」？企業採購資安檢核 7 項怎麼用 備選標題 從智譜 ZCode 事件談起：影子 AI 之後，工具自己把整庫送走怎麼辦？ 開源權重≠開源 harness：企業怎麼查 Coding Agent 的資料邊界 本週只查兩項也行：Coding Agent 採購先看「資料範圍」與「關得掉」 Claude Code 源碼外洩 vs ZCode 整庫外送：方向不同，教訓相同 一、錄製定位 主持人： Casper 來賓： Max 目標觀眾： 企業主、IT 主管、資安／資管、採購、技術決策者 建議片長： 25～35 分鐘 對談風格： 延續影子 AI 集，以企業採購與治理為主軸，不做單品公審或模型評測 核心案例： 智譜 ZCode（約 2026-09-18 公開爭議）靜默打包工作區含 .git 上傳 OSS 輔助對照： 影子 AI（人貼資料）vs Coding Agent（工具背景整庫外送）；ZCode＝工作區可能被外送 vs Claude Code 包裝疏失＝廠商 CLI 源碼外洩（方向不同）；開源權重 vs 開源 harness（Codex CLI／DeepSeek Harness）；Cursor／Claude Code／GitHub Copilot 分級 核心結論： 官方已稱修復——本集強調的是產業模式與可驗證治理；帶走「Coding Agent 採購資安檢核 7 項」，並用 Top coding agent 填表當作業 二、Max 的回答原則 每一題建議依照以下順序回答： 1. 先講結論 2. 用白話解釋 3. 舉一個企業案例 4. 說明適用條件 5. 補充限制與風險 Max 可延續第一集常用的自然口吻： 「我這樣講好了……」 「如果用一個比較常見的企業情境來看……」 「這件事情要拆成幾個層次……」 「它不是完全取代，而是做分工……」 「真正的難度還是在流程怎麼定義……」 「但這裡有一個前提……」 「這個數字不能直接照搬，還是要用公司的資料測……」 「最後還是要回到這個任務的錯誤成本……」 注意：以下為回答架構與示範口吻。Max 應依公開還原、官方聲明與企業實務調整，避免把未親測的內容說成個人逆向經驗；爭議事件當引子，主軸放產業模式與檢查清單。 三、完整對談 開場 Casper 歡迎來到 AI Landing Lab｜企業 AI 落地研究所。 上一集我們和 Max 討論了影子 AI：工程師為了趕工，把客戶資料、合約、原始碼片段貼進個人帳號的對話框。那一集的重點是——人把資料貼出去，公司常常不知道。 這幾天工程與資安圈又在傳另一件事。 大約 2026 年 9 月 18 日前後，智譜的 AI 程式開發工具 ZCode 被揭露：登入之後，客戶端可能在背景把整個工作區打包，連完整的 .git 歷史一起加密上傳到雲端物件儲存。社群還原指出，介面上的隱私開關未必攔得住；加密金鑰的私鑰端在雲端。 官方很快回應，說問題與預設開啟的程式碼庫索引有關，並稱相關問題已修復，還承諾開源與第三方審查。 同類工具其實也出過事——例如約 2026 年 3 月底，Anthropic Claude Code 的 npm 包誤帶 source map，社群得以還原 CLI 原始碼；那是廠商自己的源碼因包裝疏失外洩，跟「把你的工作區送走」方向不同，但都提醒一件事：封閉 harness 很難事前審計，發布與外殼層會出包。 但今天我們不是來做單品公審，也不做 CVE 清單。 我們要問的是： 當 Coding Agent 變成工程師每天開著的「外殼」，企業採購與資安要查的，到底是模型強不強，還是 harness／桌面端把資料送到哪裡？ 這跟影子 AI 差在哪？開源權重、本地模型，是不是就等於資料不外送？開源的若是 harness／外殼，資安能不能讀碼檢視？企業能不能用一頁檢核表，在一週內先把風險降下來？ 今天再次邀請 Max，從企業落地與治理的角度，帶我們拆解。 Max，先跟大家打個招呼。 Max 大家好，我是 Max。 我覺得這波討論真正有價值的地方，不是再罵一個產品，而是它把一個產業模式攤在桌上： Coding Agent 很強的時候，它不是只讀你貼上去的那幾行，它可能讀整個工作區、跑指令、連網路——資料邊界是由「外殼」決定的，不是由模型排行榜決定的。 今天我們可以從事件本質、跟影子 AI 的差異、開源權重對上開源 harness、七項採購檢核，一路講到企業下週怎麼開始。 問題一｜為什麼現在要談「整庫打包回傳」？ Casper Max，為什麼是這個時間點，我們要專門談「整庫打包回傳」？ 是因為 ZCode 這一則新聞，還是因為企業本來就把 Cursor、Copilot、各種 CLI agent 裝進正式專案了，只是還沒有一套採購語言？ Max 回答示範 我這樣講好了，現在談這件事，我覺得有三個理由疊在一起。 第一，Coding Agent 已經從「玩玩看」變成「每天開著」。 很多公司的工程師不是偶爾貼一段程式碼問問題，而是把 agent 嵌進 IDE、CLI，甚至讓它讀 repo、改檔、跑測試。資料接觸面從「對話片段」變成「工作區級」。 第二，整庫加上 Git 歷史，風險形狀跟貼幾行 code 完全不同。 如果只傳當前檔案，你至少還知道範圍大概在眼前。可是完整 .git 可能含：舊版誤提交又刪掉的金鑰、歷史裡的憑證、LFS 大檔、reflog、甚至本地設定。社群還原裡有人拆過快照，.git 相關內容可以佔到封存的八成以上——這是公開報導整理的量級，企業要用自己的 repo 去想像爆炸半徑，不能直接照搬那個數字。 第三，企業缺的是採購語言，不是再多一篇罵戰。 影子 AI 那集我們講的是人的行為；這集講的是工具在背景做的事。兩邊都要治理，但控制項不一樣：一個靠核准工具與紅黃綠政策，一個靠合約、預設開關、egress 與可驗證關閉。 所以時間點不是「又一個陸廠出事」，而是：企業已經在用這類工具了，卻常常還在用「模型強不強」當採購標準。 Casper 收束 所以本集的定位很清楚：ZCode 是引子，主軸是企業怎麼查任何一家 Coding Agent 的資料邊界。 問題二｜用白話解釋，ZCode 事件本質是什麼？ Casper 如果聽眾不是做逆向的工程師，而是 IT 主管或採購，你會怎麼用白話講這件事的本質？ Max 回答示範 如果只用白話，我會說： 本質不是「AI 會寫程式」，而是「這個寫程式的外殼，可能在你不知情時，把整個專案目錄——含版本歷史——打包送上雲」。 拆成幾個層次會比較清楚。 第一層，觸發條件。 公開還原與報導整理的說法是：登入狀態下打開工作區，就可能走快照／索引相關路徑；不是你主動點「上傳這個檔案」那麼直覺。官方則解釋為預設開啟的程式碼庫索引，與 Repo Wiki 等雲端能力有關，並稱問題已修復。 第二層，上傳了什麼。 重點不是「有沒有加密」。加密可以保護傳輸途中被路人看，但如果私鑰只在雲端，使用者自己打不開那包，決策者要問的是：誰能解、留多久、拿去幹嘛。 第三層，開關與同意。 如果介面上的「體驗優化」「不要訓練」關了，仍擋不住工作區快照上傳，那對企業來說，這就不是隱私文案問題，而是控制項失效。採購要查的是：關閉之後，用網路、用檔案系統、用廠商書面，能不能驗證真的停了。 第四層，我們今天怎麼用這則新聞。 官方已稱修復、也談開源與審計。口播上我會強調：就算單一產品修了，產業模式還在——下一個 agent 仍可能用「索引／Wiki／檢查點」名義擴大資料範圍。企業要的是可驗證治理，不是對某一家永遠下禁令。 Casper 收束 所以決策者記住一句就好：查的是 harness 與資料路徑，不是只查模型名稱。 問題三｜這跟影子 AI、跟「對話裡貼程式碼」差在哪？ Casper 上一集影子 AI，是人把資料貼出去。這集是工具可能自己送。 請你對照給聽眾聽：知情程度、範圍、治理手段，差在哪裡？ Max 回答示範 如果用一個表在腦袋裡對照，大概是這樣。 影子 AI：誰發起？多半是人。範圍？單次對話裡貼上去的片段。知情？當事人通常知道自己貼了，公司可能不知道。治理？核准哪些工具、紅黃綠資料分級、DLP、教育訓練。 Coding Agent 整庫外送：誰發起？背景程序或產品功能路徑。範圍？工作區，甚至含 .git。知情？工程師當下常常不知道。治理？採購條款、預設與同意、端點白名單、關閉可驗證、企業版控制項。 我用一個常見企業情境講。 假設正式 repo 裡曾經有人誤把 .env 提交上去，隔天用 git 刪掉了。對話貼碼的風險，多半是「這次貼了哪一段」。整庫含歷史上傳的風險，是「以為刪掉的東西其實還在物件庫裡」。 但這裡有一個前提：不是說影子 AI 比較輕、整庫比較重，就可以只管一邊。兩邊會疊加——工程師用未核准 agent，又開著高權限工作區，爆炸半徑最大。 真正的難度還是在流程怎麼定義：哪些專案根本不准上雲端 agent、哪些可以進企業租戶、哪些只能 VDI 或地端。 Casper 收束 人貼片段 vs 工具整庫，治理工具箱不一樣；企業兩邊都要有門。 問題四｜開源權重≠開源 harness：本地模型等於資料不外送嗎？ Casper 現場一定有人會說：那我們改用開源模型、權重跑在自己 GPU，是不是就安全了？ 另外一派會說：那我們乾脆挑「有開源」的工具就好。開源到底開的是哪一層？ Max 回答示範 結論先講：開源權重不等於資料不外送；真正對企業資安有感的，常常是「外殼／harness 能不能讀碼檢視」。 這件事情要拆成兩層，不要混成一句「開源就安全」。 第一層，開源權重。 它解決的是「模型從哪來、能不能自己託管」。資料外送卻常常發生在「外殼、外掛、索引、遙測、自動更新、MCP、雲端 Wiki」這些層——權重開了，外殼仍可能整庫上傳。 第二層，開源 harness／外殼。 開源的是 CLI、桌面端、agent 執行框架，資安與工程才能讀碼檢視：有沒有整庫上傳、遙測預設開不開、奇怪的 egress、權限模型長什麼樣。這跟「開源權重」是兩件不同的採購加分。 我這樣講好了。你可以把 Coding Agent 想成三層： 模型層——誰推理； 工具層——誰讀檔、跑指令、連網； 同步／索引層——誰為了「更好用」把上下文送到別的地方。 公開對照上，OpenAI 的 Codex CLI 是開源的 harness（Apache-2.0），DeepSeek 也開源了 Harness（MIT，everything is a plugin）。口播重點不是幫誰背書，而是：企業採購時，能不能把外殼行為攤開來看，是重大加分——尤其對照封閉 GUI／閉源 CLI，出事之前更難證明「關得掉」。 但這裡有一個前提：開源≠自動安全。仍要看預設設定、實際網路、權限模型；可檢視只是讓你有機會查，不是免檢核。 企業案例上，我看過一種很常見的誤會：資安核准「可以跑開源模型」，工程師就裝了一個功能最全的 GUI agent，結果網路連線列表裡出現一堆不是模型推理的域名。那不是模型背叛你，是外殼功能超出你以為的邊界。 適用條件是：若公司真的要「資料不外送」，驗收項要寫成——預設關閉所有雲端索引／訓練／遙測；egress 白名單可查；關閉後可用封包或廠商證明驗證；正式專案禁止未審的 MCP 與自動更新通道。若廠商開源 harness，把「讀碼檢視＋對照實際流量」寫進驗收，比只看權重授權有用。 限制也要講清楚：本地模型還有供應鏈問題——權重來源、loader、外掛市集；開源 harness 也有被惡意 fork、假「leak／破解」包汙染的風險——只是今天主軸先放在資料邊界與可審計。 Casper 收束 開源權重≠開源 harness；可檢視的外殼是加分，仍要查預設與 egress。 問題五｜採購資安檢核 7 項，怎麼用？ Casper 本集要帶走的一頁檢核，請你把七項講清楚，並告訴聽眾怎麼填，而不是貼在牆上當標語。 Max 回答示範 這七項我建議當成採購與資安的共同語言，每一項都要能寫出「證據」，寫不出來就先不要進正式 repo。 第一，資料範圍。 對話片段、嵌入向量／索引，還是整庫、含 .git、含忽略檔？問法很具體：預設上傳的最小單位是什麼？ 第二，預設與同意。 預設開還是關？關閉路徑在哪？關閉後如何驗證——看設定、看網路、看本地是否還生成待傳包？ 第三，金鑰與可讀性。 加密是保護傳輸，還是使用者可持有金鑰？誰能解密？企業金鑰託管有沒有選項？ 第四，訓練與留存。 是否用於訓練？留存多久？刪除權怎麼行使？有無獨立稽核或 SOC 報告可對照——注意報告不等於你的開關有效。 第五，駐留與跨境。 資料去哪一區、哪家雲、哪類子處理者？對有主權或客戶合約限制的公司，這項常常一票否決。 第六，企業控制項。 SSO、RBAC、DLP、私有部署或專屬租戶、允許清單、完整稽核日誌——個人版能用，不代表企業版控得住。 第七，網路與端點。 egress 能否白名單？異常上傳量能否告警？桌面端是否長連一堆與任務無關的 OSS／遙測域名？ 怎麼用：找公司正在用的 Top 1～3 個 coding agent，七項各填「已知／未知／不可接受」。未知超過兩項，就不要只靠口頭保證上正式專案。 Casper 收束 七項不是考卷滿分才准用，而是逼出未知項，未知項就是治理債務。 問題六｜本週只能查兩項，先查哪個？ Casper 現實是 IT 很忙。如果本週只能查兩項，你會叫他們先查哪兩個？ Max 回答示範 先查兩項：資料範圍，以及關閉之後如何驗證。 為什麼不是先查訓練條款？因為很多爭議的爆炸點，不是「有沒有拿去訓練」，而是「根本傳了超乎預期的範圍，而且關不掉」。訓練條款重要，但若範圍與開關都糊，簽再漂亮的紙也救不了當下的外洩路徑。 白話一點：先問「它預設會碰我整顆 repo 嗎」，再問「我說不要之後，用什麼證明它真的停了」。 企業案例：有的團隊一週內做得到的最小動作是——對現況工具抓一次 outbound 連線清單、讀隱私權與企業版文件裡「codebase indexing／telemetry」章節、要求廠商書面回覆關閉後的驗證步驟。這兩項填得清楚，後面五項才有座標。 適用條件：若公司連這兩項都沒人負責填，代表 Coding Agent 還停在影子工具狀態，應該先指定 owner，而不是先辯論哪家模型比較強。 Casper 收束 本週最小可行治理：範圍＋關得掉；其餘列入下一週。 問題七｜Cursor、Claude Code、Copilot 怎麼分級，而不是一律禁？ Casper 現場主管很容易走向兩極：全面開放，或全面禁止。你怎麼建議分級？ Max 回答示範 這件事情要拆成幾個層次，不要用國籍或品牌一刀切。 第一層，依資料分級，不依產品迷因。 公開套件、內部工具、客戶正式專案、金流／個資／法規相關 repo——允許的 agent 能力應該不同。紅燈資料可以規定：不准雲端 agent，只准地端或 VDI，且禁用自動上傳索引。 第二層，依部署形態分級。 個人帳號打正式 repo，通常最糟；企業租戶＋SSO＋稽核次之；私有化或完全離線再嚴一等。同一品牌，個人版與企業版可能是兩種風險。 第三層，依能力分級，不只看補全。 只讀建議、可改檔、可跑终端、可連 MCP、可自帶瀏覽器——權限每升一級，檢核要加嚴。iThome 等報導也一路在談 AI IDE 攻擊面、規則檔後門、CI token 被濫用：這說明 agent 是高權限開發元件，不是可愛外掛。設計／漏洞脈絡——惡意專案設定導致 RCE、MCP 劫持之類——可以點到為止，本集主軸仍是資料邊界與可審計，不要變 CVE 清單。 順帶把方向講清楚，免得聽眾把兩種「外洩」聽成同一件事。 約 2026 年 3 月 31 日前後，Anthropic Claude Code 的 npm 包 `@anthropic-ai/claude-code` v2.1.88 被發現誤帶約 60MB 的 source map，社群得以還原 CLI 的 TypeScript 原始碼——公開整理的量級大約是五十多萬行、近兩千個檔；也有報導提到可經 map／物件儲存路徑拿到原始碼包。Anthropic 的定性是發布包裝疏失，不是客戶資料外洩，並稱沒有用戶資料、憑證或客戶 repo 外洩。後來還出現假借「leak」鏡像散佈惡意程式的供應鏈跟進——這提醒企業：不要去下載不明的「破解／leak」包。 對照今天的主案例：ZCode 爭議的方向是「使用者工作區可能被外送」；Claude Code 那次是「廠商自己的 CLI 源碼因包裝外洩」。方向不同，共同教訓卻很像——封閉 harness 難事前審計；發布、索引、外殼層會出包；企業要查外殼行為與供應鏈，而不是只看品牌安心。 第四層，一律禁的時機。 當你無法回答資料範圍、無法驗證關閉、無法限制 egress，又要碰紅燈資料——那就該禁雲端 agent，不是禁「某個名字」。 所以 Cursor、Claude Code、Copilot 不是「好／壞」兩格，而是填完七項之後，分別落在綠／黃／紅專案能不能用。黃燈專案可以 Shadow：先準用在非敏感 repo，日誌與網路觀察一週再放寬。對有開源 harness 的工具，可以把「讀碼檢視外殼行為」當成加分項寫進分級，但仍要用預設與實際網路驗證，不要把開源當成免死金牌。 Casper 收束 分級靠資料色燈與可驗證控制，不靠品牌愛恨。 問題八｜企業下週怎麼開始？何時根本不該上雲端 agent？ Casper 給一個下週就能做的動作清單。也請明講：什麼情況下，根本不該讓雲端 Coding Agent 碰正式專案。 Max 回答示範 下週可以從四步開始。 第一步，盤點。 列出公司實際在用的 coding agent Top 1～3——含「主管不知道但工程師裝了」的，必要時用軟體資產或網路日誌輔助，不要只問自願申報。 第二步，填表。 用七項檢核填一輪；強制兩欄：資料範圍、關閉後如何驗證。填「未知」就要指定誰在何時補齊。 第三步，先畫紅線。 客戶正式原始碼、金鑰倉、生產設定、個資與法規資料：未完成企業租戶與驗證前，禁止個人帳號雲端 agent。這條紅線比辯論模型分數重要。 第四步，給替代路徑。 只禁不給路，影子 AI 會更嚴重。要嘛企業版核准名單，要嘛地端／VDI，要嘛核准的程式問答管道——讓人有正門可走。 何時根本不該上雲端 agent？ 錯誤成本極高，且沒有人工或系統攔截； 資料主權或客戶合約明確禁止出境／禁特定子處理者； 產品無法證明資料範圍與可關閉； 環境裡充滿長期有效的憑證、生產存取，又沒有 secret scanning 與最小權限。 最後還是回到這系列的核心：企業不是先選最紅的 agent，而是先定義資料邊界與錯誤成本，再決定工具可以站在哪一層。 Casper 收束 作業很明確：Top agent 填七項；兩項關鍵空白，就先別碰正式 repo。 四、結尾 Casper 今天我們從 ZCode 事件談起，但沒有停在單一產品。 我幫大家整理四個重點。 第一，整庫打包回傳，是「工具背景外送」的產業模式問題，不是只靠罵一輪就能結束。 第二，它跟影子 AI 不同：一個是人貼片段，一個可能是程序送歷史；治理手段要分開設計，又要一起管。 第三，開源權重≠開源 harness：本地模型不等於資料不外送；可檢視的外殼是企業採購加分，但仍要查預設、索引、遙測、MCP 與 egress。同類工具的「外洩」也要分清方向——工作區被外送，和廠商 CLI 源碼因包裝疏失外流，不是同一件事。 第四，帶走七項檢核；本週至少查資料範圍與關閉可驗證。官方稱已修復，企業要的是可驗證治理，不是口頭安心。 Max，最後如果只能留一句話給正在評估 Coding Agent 的企業主管，你會怎麼說？ Max 我覺得最重要的一句話是： 模型可以很強，但外殼決定資料邊界；關不掉、驗不了的上傳路徑，就不要讓它進正式專案。 用七項檢核當正門，讓工程師有核准過的路可走——否則你禁得了產品名稱，禁不了產能壓力。 Casper 非常感謝 Max 今天的分享。 如果你是企業主、主管、資安或採購，正在評估公司的 AI 寫程式工具，歡迎訂閱 AI Landing Lab｜企業 AI 落地研究所。 也歡迎在留言區告訴我們： 你的公司現在允許哪些 Coding Agent 碰正式 repo？七項裡你最先查不清的是哪一項？ 我們後續也會繼續用實際案例，拆解企業 AI 從 Demo 到可治理上線的過程。 我們下一集再見，謝謝。 五、主持人現場快速提問卡 開場： ZCode 是引子；主軸是 Coding Agent 採購資安檢核，不是單品公審。可一句帶過：Claude Code 也曾因 npm 包裝疏失讓 CLI 源碼可被還原——方向是廠商源碼外洩，不是客戶工作區外送。 1. 為什麼現在談「整庫打包回傳」？ → Agent 已變日常外殼；Git 歷史爆炸半徑；缺採購語言。 2. 用白話解釋事件本質？ → 外殼可能背景整庫上傳；加密≠你能控制；開關要可驗證。 3. 與影子 AI／對話貼碼差異？ → 人貼片段 vs 程序送歷史；知情與治理工具箱不同。 4. 開源權重／本地模型＝不外送？開源 harness 呢？ → 權重開源≠不外送；harness 開源＝方便讀碼檢視（Codex／DeepSeek），仍要查預設／egress。 5. 採購資安檢核 7 項怎麼用？ → 範圍、預設、金鑰、訓練留存、駐留、企業控制、網路端點。 6. 本週只能查兩項先查哪個？ → 資料範圍＋關閉後如何驗證。 7. Cursor／Claude Code／Copilot 怎麼分級？ → 依資料色燈與部署形態，不一律禁；分清 ZCode 工作區外送 vs Claude Code 包裝源碼外洩。 8. 企業下週怎麼開始／何時不該上雲端 agent？ → 盤點→填表→紅線→替代路徑；關不掉驗不了就別碰正式專案。 每個案例一定追問： 1. 實際上傳或讀取的範圍是什麼？ 2. 關閉之後用什麼證明它停了？ 3. 若外洩，爆炸半徑落在哪個資料分級？ 六、Max 回答時可引用的資料 1. 電腦王阿達｜智譜 ZCode 事件整理 標題大意：ZCode 被爆靜默打包整包 Git 歷史上傳阿里雲，加密金鑰握在官方；官方稱與預設程式碼庫索引有關並稱已修復，承諾開源與第三方審查。 來源： https://www.kocpc.com.tw/archives/669544 2. ferstar 技術還原（一級技術源） 公開文章還原客戶端快照上傳流程：向 zcode.z.ai 取憑證 → 工作區打包加密 → 直傳雲端 OSS；並討論開關與 .git 佔比等觀察。口播時標明「社群還原／公開報導整理」，避免說成未親測的個人逆向。 來源： https://blog.ferstar.org/posts/zcode-silent-workspace-snapshot-upload/ 3. 官方回應（智譜／ZCode） 公開聲明方向：問題與預設開啟的 Codebase Indexing／Repo Wiki 等能力有關；稱上傳資料於相關流程後銷毀、問題已修復；並提及開源、第三方審查與用戶補償措施。細節以當時官方貼文／公告為準，口播保留「官方已稱修復」。 可對照產品說明／FAQ： https://zcode.z.ai/en/docs/qa 4. iThome｜Claude Code「源碼外洩」與後續供應鏈（方向對照，非 ZCode 同一事件） 約 2026-03-31，npm 包 `@anthropic-ai/claude-code` v2.1.88 誤帶約 60MB source map，可還原 CLI TypeScript 原始碼（社群整理約 51 萬行／約 1900 檔）；部分報導指可經 map／物件儲存取得原始碼包。Anthropic 定性為發布包裝疏失，非客戶資料外洩；稱無用戶資料／憑證／客戶 repo 外洩。口播務必分清：ZCode＝使用者工作區可能被外送；Claude Code 事件＝廠商自己 CLI 源碼因包裝外洩。 主報導： https://www.ithome.com.tw/news/174812 後續假「leak」鏡像散佈惡意程式： https://www.ithome.com.tw/news/174870 5. iThome｜Coding Agent／AI IDE 資安脈絡（產業補強，點到為止，勿變 CVE 清單） 說明 AI 程式助理與 AI IDE 已成高權限攻擊面與供應鏈議題，企業不應只當編輯器外掛。例： GitHub Copilot RoguePilot／CI token 風險： https://www.ithome.com.tw/news/174056 Rules File Backdoor（Copilot／Cursor 相關警示）： https://www.ithome.com.tw/news/168098 IDEsaster 攻擊鏈與 AI IDE 資料外洩風險： https://www.ithome.com.tw/news/172719 6. 開源 harness 對照（方便檢視資安，≠自動安全） OpenAI Codex CLI（Apache-2.0）： https://github.com/openai/codex DeepSeek Harness（MIT；everything is a plugin）： https://github.com/deepseek-ai/deepseek-harness 口播重點：開源的是 harness／外殼，才能讀碼檢視整庫上傳、遙測、預設索引、奇怪 egress；這與「開源權重」不同。開源≠自動安全，仍要看預設與實際網路。 7. 本系列相關訪綱 ZCode／Coding Agent 整庫回傳訪綱（結構對照）： https://zcode-coding-agent-outline.pages.dev/ 七、事實與措辭注意事項 建議說法 約 2026-09-18 前後，公開報導與社群還原指出 ZCode 可能在登入後於背景打包工作區（含 .git）並上傳雲端物件儲存；官方稱問題與預設程式碼庫索引有關，並表示已修復。 避免說法 我們實測證明 ZCode 現在仍一定會上傳（除非你有當下可出示的復現）。 建議說法 加密傳輸不等於使用者或企業可控制解密與留存；要問金鑰由誰持有、關閉後如何驗證。 避免說法 有加密所以沒資安問題。 建議說法 開源權重或本地推理，不等於桌面端／索引／遙測／MCP 不會外送資料；開源 harness（如公開的 Codex CLI、DeepSeek Harness）的價值是方便資安讀碼檢視，仍要查預設與實際 egress。 避免說法 開源就安全、本地就一定不外送；或把「開源權重」說成等同「外殼可審計」。 建議說法 約 2026-03-31 前後，Claude Code npm 包因誤帶 source map 讓 CLI 原始碼可被還原；Anthropic 稱屬發布包裝疏失、非客戶資料外洩。口播對照：ZCode 爭議是工作區可能被外送，Claude Code 事件是廠商源碼外洩——方向不同，共同教訓是封閉外殼難事前審計、不要下載不明 leak／破解包。 避免說法 把 Claude Code 源碼外洩說成「跟 ZCode 一樣偷傳客戶 repo」；或鼓勵聽眾去下載所謂 leak 鏡像。 建議說法 本集主軸是企業採購資安檢核與產業模式；單一產品官方稱已修復後，仍應用可驗證方式看待同類功能。 避免說法 未查證就持續指控特定產品「現在仍在偷傳」，或上升成地域／品牌全面抹煞。 建議說法 七項檢核用於逼出未知項與紅線；本週優先「資料範圍」與「關閉可驗證」。 避免說法 填不完七項就不准公司任何人碰任何 AI 工具（不給正門會把人趕去影子路徑）。 八、本集核心金句 模型可以很強，外殼決定資料邊界。 影子 AI 是人把資料貼出去；Coding Agent 爭議戳到的是——工具可能在背景把整庫送走。 開源權重≠資料不外送；開源 harness＝方便檢視資安，仍要查索引、遙測、MCP 與 egress。 ZCode 是工作區可能被外送；Claude Code 那次是廠商 CLI 源碼因包裝外洩——方向不同，教訓相近：要查外殼與供應鏈。 關不掉、驗不了的上傳路徑，就不要進正式專案。 本週先查兩項：資料範圍，以及關閉之後如何驗證。 企業不是先選最紅的 Coding Agent，而是先定義資料邊界與錯誤成本，再決定工具可以站在哪一層。