編碼智能體為存放 13,000 張 PR 截圖建立公開儲存庫，gh 當時無法附加圖片

• 書籍： 系統設計袖珍指南：基礎
• 系列： 開發者袖珍指南 — 8 本涵蓋 Agent、RAG、提示詞、可觀測性、事件、資料庫及系統設計的短篇指南 — 整個系列
• 我的項目： Hermes IDE | GitHub — 一款為使用 Claude Code 及其他 AI 編碼工具開發並交付軟件的開發人員而設的 IDE
• 我： xgabriel.com | GitHub

一家員工超過 100,000 人的製造商，有名開發人員要求編碼 Agent 檢查內部帳單頁面的修正，並展示結果。Agent 擷取了畫面，在該開發人員的個人 GitHub 帳戶下建立了一個公開儲存庫，並把圖片貼在那裏，供審核人員查看。圖片顯示一家公用事業公司的帳單記錄。該儲存庫不屬於公司的 GitHub 組織，因此資訊保安團隊從未發現。研究人員通知該公司時，儲存庫仍然公開（Glow Labs）。

這是 Glow 報告中的其中一宗個案。報告於 9 月 29 日發布，並於翌日獲 The Hacker News 報道。Glow 統計出超過 13,000 張內部圖片，存放在 900 多個公開儲存庫，涉及 300 多個機構的開發人員。在 93% 個案中，圖片存放於員工以自己的用戶名稱建立的儲存庫。

沒有人發動任何攻擊。Agent 只是在照指示行事：把修改前後的截圖放到拉取請求中。它們手上的工具做不到這一點，於是便另找方法。

六年來的「讓我從終端機上傳圖片」

編碼 Agent 透過 shell 運作；在 GitHub 上，這主要是指 GitHub CLI，gh。六年來，gh只能在拉取請求中加入文字，別的都做不到。

這項要求由來已久。cli/cli#1895 的標題是「將檔案上傳並嵌入 PR／議題／留言」，於 2020 年 9 月 22 日提出。一名維護者解釋，瀏覽器上傳會經過一項上傳政策，像 gh 這類 API 用戶端無法取得該政策；該項要求於同年 11 月被關閉，理由是短期內不太可能開發。

最直接的替代方法，是把 PNG 提交到分支，再連結該檔案。這在公開儲存庫行得通，但在私人儲存庫則不行。cli/cli#13256 於 2026 年 4 月 21 日提出，解釋了原因：在私人儲存庫中，連結檔案的 GitHub 原始網址會失效，因為 GitHub 的 camo 圖片代理「無法對私人內容進行驗證」，所以圖片會無法正常顯示。

因此，當時一個在私人儲存庫工作的 Agent 被要求向審核人員展示截圖，眼前有三個事實：

1. gh pr create 和 gh pr edit 只能處理文字。
2. 提交到私人儲存庫的圖片，在拉取請求中會無法正常顯示。
3. 放在公開儲存庫的圖片則能正常顯示，任何人都看得到。

不難想像事情會如何發展。GitHub 於 2026 年 9 月 1 日推出修正：gh 2.99.0 加入可重複使用的 --attach 旗標，適用於 gh pr create、gh pr edit、gh pr comment 及相應的議題操作。這需要有該儲存庫的寫入權限。GitHub 的文件指出，在私人及內部儲存庫中，「只有具備該儲存庫存取權限的人，才能查看已上傳的檔案。」在此之前，Agent 至少從 7 月初起便一直在繞過這個缺口。

私人儲存庫無法顯示圖片，所以圖片被放到能顯示的地方。

Agent 當時的想法

Glow 在實驗室重現了這種情況。一名開發人員要求使用 Opus 5 模型的 Claude Code，在一個踩地雷測試專案中更改頁首顏色並展示結果。專案位於私人儲存庫 internal_sweeper。Agent 建立了一個新的公開儲存庫 sweeper-demo/pr-assets，並在其中放了兩張截圖，固定至某個 commit SHA。

報告引述了它的推理：「internal_sweeper 是私人儲存庫，而 GitHub 無法在 PR 説明中顯示來自私人儲存庫的圖片。」它得出的結論是，要讓審核者看到對方要求的內容，唯一方法就是「將 PNG 放到其他地方託管」。

它對 GitHub 的説法沒錯，也是在嘗試協助審核者。根據 Glow 的説法，它沒有考慮到的是，公開儲存庫會帶來安全風險。Glow 表示，在許多受影響機構觀察到的情況中，這種推理都很典型；涉及的 Agent 使用了多種 AI 模型，但 Glow 沒有透露模型名稱（The Hacker News）。在實驗室以一個模型進行的一次測試，重現了這種行為，但不能證明任何特定供應商的 Agent 曾在實際環境中這樣做。

一項 skill 如何令權宜做法變成慣例

Glow 報告提到，在一家軟件公司，多名工程師使用的 Agent 於 7 月初開始公開發布程式碼審查截圖。一星期內，十多個 Agent 已將這種做法寫進一項適用於每張開發工單的 skill。這裏所説的 skill，是 Agent 載入並遵循的指令檔案。之後，這些 Agent 上載了逾 1,000 張產品截圖及螢幕錄影，並附上文字摘要，披露了原定數星期或數月後才發布的功能。Glow 稱這是調查中最全面的一宗外洩事件。

第二種途徑是使用工具。約三分之一受影響機構的開發人員使用 gitshot，一款用於發布程式碼審查截圖的小型開源工具。在數間大型機構，Agent 找到並使用這個工具，以繞過 CLI 限制。它可作為 skill 安裝在 40 多種編碼 Agent 中。The Hacker News 在 9 月 30 日檢視了它的程式碼；當時的版本上次修改是在 4 月：

• 登入 gh 後，它會在你個人帳戶下建立一個名為 gitshot-images 的公開儲存庫，並將圖片放在其中。
• 它不會使用私人儲存庫，也不會使用由機構擁有的儲存庫。
• 圖片會以版本發佈資產的形式儲存，而非儲存庫內的檔案，因此任何人都可以在未登入的情況下列出及下載圖片；儲存庫的檔案清單則可能看起來是空的。
• 它的 README 和 skill 都有警告，指出儲存庫是公開的，並提醒不要上載憑證或內部儀錶板。

警告確實存在。在一家金融服務公司，gitshot 的圖片包括內部財資及結算控制台，以及一名具名機構客戶的提款畫面。Glow 發現有逾 100 個公開帳戶透過該工具分享內部工作內容。

有關數字有三點需要留意。Glow 沒有説明除了其研究人員之外，是否有人下載過這些圖片，也沒有公開説明如何發現或統計這些圖片。Glow 亦有銷售其聲稱可阻止 Agent 採取此類行動的軟件。The Hacker News 提及了以上三點。

立即在你的機構執行 Glow 的檢查

因為 93% 的個案都出現在個人帳戶中，只檢查你的 GitHub 組織會漏掉大部分情況。Glow 的建議是：先找出曾向你的私人儲存庫提交變更的人（包括前員工），再檢查他們的個人帳戶。檢查發佈版本和 Gist，不要只看檔案；也要檢查 gitshot 等套件的端點。考慮到 gitshot 的運作方式，亦要搜尋帶有 _gitshot 標籤的發佈版本，以及名稱為 gitshot-images 的儲存庫；The Hacker News 在其程式碼中找到的預設名稱就是這個。不要只依賴掃描器；正如 Glow 的報告所言：「它們讀取的是文字，不是像素。」

以下是由有權存取私人儲存庫的人執行 gh 後得到的初步結果：

#!/usr/bin/env bash
# Usage: ./pixel-check.sh your-org/private-repo
set -u
repo="$1"
logins=$(gh api "repos/$repo/contributors" --paginate \
  --jq '.[] | select(.type == "User") | .login')
for u in $logins; do
  echo "== $u"
  gh repo list "$u" --visibility public --limit 500 \
    --json name,createdAt \
    --jq '.[] | "\(.createdAt)  repo  \(.name)"'
  gh api "users/$u/gists" --paginate \
    --jq '.[] | "\(.created_at)  gist  \(.html_url)"'
  if gh release view _gitshot -R "$u/gitshot-images" \
      >/dev/null 2>&1; then
    echo "FOUND: $u/gitshot-images has a _gitshot release"
  fi
done

它會列出每位貢獻者的所有公開儲存庫和 Gist，並附上建立日期，因此，團隊開始使用 Agent 的那一週建立的 pr-assets 儲存庫會特別顯眼。貢獻者端點只會識別電郵地址對應至 GitHub 帳戶的提交，因此應把輸出視為初步清單。對任何可疑儲存庫，也要執行 gh release list -R owner/name，因為發佈資產不會顯示在檔案樹中。

如果找到相關內容，Glow 建議依次處理：在所有地方將其移除，要求持有副本的人將其刪除，並更換任何在圖片中可見的憑證。

關上這道門：接入、詢問，並留意核准流程

三項改動。

首先，為 Agent 配備合適的工具。確保每部機器都安裝了 gh 2.99.0 或更新版本（gh --version）。根據更新日誌，--attach 尚未支援 GitHub Enterprise Server，因此在 GHES 上，Agent 會觸發下文的停止規則。接着，將這項要求寫入 Agent 載入的指示檔，無論是 AGENTS.md 還是 CLAUDE.md：

## Screenshots in pull requests
- Attach images with `gh pr edit <number> --attach ./shot.png`.
- Never create a repo, gist or release to host an image.
- If --attach fails, stop and tell me. No workarounds.

指示檔本身無法強制執行任何規則，因此第二步，要讓高風險命令觸發詢問。在 Claude Code 中，acceptEdits 模式會自動接受檔案修改及常見的檔案系統命令，其他 shell 命令仍會要求確認（權限文件）。.claude/settings.json 中的 ask 規則會強制要求對執行發佈操作的呼叫顯示確認提示，即使有人已允許 Bash(gh *) 也一樣，因為 ask 規則會先於 allow 規則檢查：

{
  "permissions": {
    "ask": [
      "Bash(gh repo create *)",
      "Bash(gh repo edit *)",
      "Bash(gh gist create *)",
      "Bash(gh release create *)",
      "Bash(gh release upload *)"
    ]
  }
}

瞭解其限制。同一份文件提醒，限制引數的 Bash 模式「很容易失效」。為 gh repo create 設定的規則不會匹配 gh api，也無法攔截透過 curl 呼叫 REST API 的操作，或以自身名稱執行的 gitshot 等獨立工具。Glow 更進一步建議由安全團隊而非個別開發者負責 Agent 設定，而 Claude Code 的受管理設定正是為此而設：用戶無法覆寫的規則。

第三步，在提示出現時做好準備。我開發 Hermes IDE，請將這點納入考量。Hermes 會在各自獨立的真實終端機中執行每個 Agent，並顯示 Agent 自己的批准提示；它絕不會代你回覆權限提示。開始工作時按下 ⌘N（Windows 和 Linux 上按 Ctrl+Shift+N），系統會為該工作建立專屬的 hermes/ 分支和工作樹，並以該工作作為 Agent 的第一個提示詞。

Hermes 2.3.4 中的 ⌘N「新工作」面板：Claude Code 在新的 hermes/ 工作樹中以「接受編輯」模式執行，並預覽 Hermes 將執行的命令。

在這種設定下，像 Glow 實驗室測試中的 gh repo create 呼叫不會自行執行。工作階段會顯示「需要批准」，收件匣會將它計入數目，而按下 ⌘I（Ctrl+Shift+I）便會跳至等待時間最長的 Agent。任何內容離開你的電腦前，你都可以先看一行內容。只有在批准機制保持啟用時，這套做法才有效：Hermes 不會自行封鎖該呼叫，而以略過權限的方式啟動的 Agent，便沒有任何提示可供你查看。Glow也有同樣建議：避免一律自動批准。

事後檢視無法發現這件事。Hermes 會儲存每個 Agent 回合，而 Review Desk（⌘G, Ctrl+Shift+G）會在你的儲存庫中按回合或檔案顯示變更。個人帳戶中新建的公開儲存庫通常不會更改工作樹，因此該回合只會顯示標題顏色修正，沒有其他內容。

Review Desk 的「按回合」檢視（⌘G）：儲存庫中每個 Agent 回合的差異，以及根據各回合草擬的提交訊息。

因此，核准提示是你在新儲存庫公開前查看它的唯一機會。Hermes 免費，依據 BSL 1.1 授權提供原始碼，並可在 macOS、Windows 和 Linux 上執行。它與 Glow、GitHub、Anthropic 或此處提及的任何 Agent 供應商均無關聯。

如果這篇內容對你有幫助

瞭解資料離開系統的每一條路徑，包括輔助程序為完成工作而自行開啟的路徑，並非 Agent 時代才有的概念。System Design Pocket Guide: Fundamentals介紹從端到端分析系統所需的基本構成要素，包括系統可能失效之處。這是Pocket Guides 系列8 本短篇指南之一，內容涵蓋 Agent、RAG、提示詞、可觀測性、事件、資料庫和系統設計。

如果你想將所有 Agent 的核準提示集中到同一個收件匣，請下載 Hermes IDE；如有幫助，也可以在 GitHub 上為它加星。