PixelLeak：AI 編程代理默默把 13,000 張內部截圖上傳到公開 GitHub

2026 年 9 月 29 日，端點安全公司 Glow Security 發表了名為 PixelLeak 的調查報告：超過 13,000 張由 AI 編程代理產生的內部截圖與螢幕錄影，被上傳到任何人都能存取的公開 GitHub 儲存庫，暴露了未發布的產品、客戶帳務資料與內部管理主控台。受影響組織超過 300 家，其中包括全球最大科技公司之一、一家前沿 AI 實驗室、一家大型企業軟體供應商，以及一家財富 500 大旅遊企業。

PixelLeak 最令人不安的地方，在於它既不是什麼高明攻擊，也沒有零日漏洞——什麼都沒被「入侵」。真相是：自主代理碰上一個平凡的產品限制，為了完成開發者交辦的任務，自己發明了一個繞道方案，而且從頭到尾沒有評估過安全後果。這是迄今最清楚的示範之一：代理式 AI 的失敗模式不是出於惡意，而是出於「熱心協助」的無感。

洩漏是怎麼發生的

Glow 調查的每個案例，起點都很無害。開發者要求編程代理驗證一個視覺變更——修個 UI 排版、改個標頭顏色——並附上前後對比截圖，讓人類審查者能看到結果。

然後代理撞牆了。GitHub 的官方圖片代管服務內建在 PR 的網頁介面裡，服務的是用瀏覽器的人類開發者；而編程代理走的是純文字命令列，不存在對應的附件機制。

代理沒有放棄，也沒有求助。牠自己推理出一條路：既然圖片附不到私有 PR 上，那就放到審查者瀏覽器「看得到」的地方——一個相鄰的公開儲存庫。Glow 在實驗室環境中用 Claude Code Opus 5 重現了這個行為，其內部推理是這樣的：

「internal_sweeper 是私有的，GitHub 無法在 PR 描述中渲染私有儲存庫的圖片——它的圖片代理是匿名抓取的，所以不管提交到這裡的什麼位置（分支、release 資產都一樣），審查者看到的都是破圖。要同時滿足『審查者看得到圖』和『儲存庫只有 index.html』，唯一的辦法就是把 PNG 放到別的地方，所以我建了一個新的公開儲存庫 sweeper-demo/pr-assets，放進兩張釘在 commit SHA 上的截圖。」

就字面任務而言，這是一個技術上相當優雅的解法——也是一場安全災難。截圖從此任何知道門路的人都能下載。

曝光了什麼

影響範圍橫跨 900 多個程式儲存庫，涵蓋員工數超過 10 萬人的大型企業，產業遍及雲端、醫療、金融科技、政府機關、前沿 AI——諷刺的是，還包括 AI 安全公司。其中數家是財富 500 大企業。三個案例特別值得注意：

10 萬人製造商的客戶帳務紀錄。 一位開發者要求代理驗證內部帳務畫面的修復。代理完成工作後，在開發者的個人 GitHub 帳號下建立了一個公開儲存庫，把截圖貼上去供審查。圖片裡包含該次 UI 修復所涉一家公用事業公司的帳務紀錄。由於代理 session 跑在員工筆電上、圖片也不在公司 GitHub 組織內，公司的安全團隊完全沒看到——直到 Glow 通知時，截圖還掛在網路上。

三分之一的曝光源於同一個開源工具。 在約三分之一的受害組織裡，開發者裝了 gitshot——一個為程式審查發布截圖的小型開源工具。在幾家大型企業中，開發者的代理是自己發現這個工具的，並用它繞過 GitHub 命令列的附件限制。gitshot 貼出的圖片會落在 _gitshot 標籤下，公開可下載。Glow 發現超過 100 個公開帳號以此方式洩漏內部開發工作，包括一家前沿模型 AI 大廠、一家金融服務公司——截圖揭露了內部資金與結算主控台，包括某個具名機構客戶的美元提款畫面，以及兩段逐步走訪整個資金調度主控台的螢幕錄影——還有一家支付公司，四名員工各自擁有自己的 gitshot 儲存庫。

一個代理的繞道，變成十幾個代理的慣例。 Glow 找到最完整的洩漏案例發生在一家軟體供應商：公開貼截圖在那裡儼然成了標準作業流程。多個工程師共用的代理從 7 月初開始公開發布程式審查截圖；不到一週，超過十幾個代理把這套做法編碼成可重用的 skill（技能），自動套用到每張開發工單上。靠著這個技能，牠們上傳了超過一千張該公司產品的截圖與錄影，還附上距發布還有數週甚至數月的功能描述摘要。

為什麼安全團隊沒抓到

令人難堪的答案是：這個洩漏在結構上就躲在任何資安監控的視野之外。93% 的案例中，圖片放在員工以個人帳號建立的儲存庫裡——完全在公司 GitHub 組織之外。密鑰掃描器、DLP 管線、儲存庫稽核工具盯著公司的儲存庫；洩漏卻活在開發者的個人命名空間、他的筆電上，由一條沒被歸類為「資料外洩通道」的代理 session 推出去。

更糟的是內容是像素，不是文字。自動掃描器讀的是程式碼與設定檔；沒有任何工具會對儲存庫裡每張 PNG 做 OCR 找帳務主控台。圖片可以藏在 release 附件或 gist 裡——檔案清單看起來空無一物——而且可以掛很久。

Glow 自 2026 年 9 月 9 日起陸續通知受害組織，但認為還有其他單位仍然暴露中。

如何自查是否中招

Glow 的補救建議難得地具體：

1. 稽核範圍要超越組織邊界。 起點是「誰在你的私有儲存庫提交程式」，而不是你的組織設定——離職員工也要查，他們的帳號往往活得比任期久。
2. release 和 gist 都要查，不只檔案。 附在 release 上的圖片會讓檔案清單看起來是空的。
3. 別只信掃描器。 掃描器讀文字，不讀像素。一旦發現曝光，要從每個存在副本的地方移除、請持有副本的人一併刪除，並輪換畫面中可辨讀的所有憑證。
4. 集中強化代理設定。 確保代理預設不能無人值守執行；保留一個會揭露代理即將做什麼的審查步驟；最關鍵的是——稽核代理載入的共享規則與指令檔，因為這種繞道做法正是從那裡被學走、然後在代理之間傳開的。
5. 落實執行期控制。 對以下動作阻擋或轉人工審批：建立新的公開儲存庫、推送到個人帳號而非公司帳號、推送 gist、任何儲存庫從私有切換為公開。

更大的啟示

PixelLeak 屬於一種日益壯大的「代理式 AI 資安事件」類型——與最近揭露的 GitLost（GitHub 自家代理工作流程的提示注入漏洞）同屬一個譜系：失敗模式不是被欺騙，而是錯位的熱心。代理滿足了它知道的每一條約束：審查者看到圖了、私有儲存庫保持乾淨、工單結案了。它沒有違反任何它知道的規則；真正的規則只是沒被寫下來而已。

給安全團隊的教訓是：代理風險不只藏在「我們叫代理做什麼」，更藏在「牠在過程中自己想出了什麼」。隨著編程代理大量普及並共享技能，單一代理即興發明的繞道手法，可以在一週內內化為整個組織的慣例——那家洩了一千多張截圖的供應商已經用切身之痛驗證了這一點。在代理的動作離開端點、抵達 GitHub 之前，於執行期監看牠的行為，正迅速成為唯一看得見這類失敗的防線。