```
A report by The Hacker News, citing findings from security firm Glow, says AI coding agents asked to attach screenshots for code review have uploaded more than 13,000 internal company images to public GitHub repositories.
According to the report, the images came from developers at over 300 organizations, and the material was not confined to innocuous UI mockups — Glow's researchers described customer billing records and screens of features that have not yet been released among the files. In most cases, the report said, the images sat under developers' personal GitHub accounts rather than corporate-controlled repositories.
That last detail is what makes this story more than an anecdote about careless prompting. The exposure does not appear to be the result of a compromise or a targeted attack. Instead, it describes a mundane workflow habit: an agent is asked to produce a visual representation of a code change for review, and the resulting screenshot is then committed into a repository as if it were just another artifact. Agents are not reasoning about data classification, retention policy, or where a file ends up once it is pushed. They are satisfying an instruction, at speed, under a human developer's identity.
Why personal accounts change the risk profile
The shift to personal repositories is significant because it removes the safety nets organizations typically rely on. Corporate secret scanning, data-loss-prevention tooling, and repository governance apply to org-owned projects. A file committed under an individual's personal account, from a laptop that may or may not be enrolled in enterprise controls, largely falls outside that perimeter — and the takedown burden, if anything surfaces, moves onto the individual contributor.
The pattern also points to a category of risk that security teams are only starting to name: automated error entering software pipelines. Pull-request review practices have, historically, focused on diffs — on the lines of code that changed. But agent output is increasingly an action rather than a suggestion. Commits, uploads, and generated assets are now part of the output, and they inherit the developer's permissions without inheriting the organization's guardrails.
For IT and security teams across industries — including financial services, logistics, professional services and the public sector — where AI coding assistants are being adopted on developer machines, the practical implications are straightforward. The images that matter most are not usually in the diff.
Practical steps teams can consider
Drawing on the pattern Glow describes, several controls are worth weighing:
- Constrain agent identity and permissions. Determine what accounts and tokens agents can push under, and whether agent-initiated commits should be blocked on personal repositories by policy.
- Redact screenshots at the source. Where possible, prefer code or structured text in review artifacts; where screenshots are required, apply masking to anything containing credentials, customer data, or internal identifiers.
- Review attachments, not just diffs. Extend pull-request and code-review checklists to cover images, logs, and generated files alongside source changes.
- Scan personal and public repositories tied to employees. Treat externally visible developer activity as part of the organizational attack surface, using the identity data teams already hold about staff accounts.
- Log agent sessions. Capture what each agent executed, what it committed, and where, so that anomalous or misdirected output can be traced after the fact rather than discovered publicly.
The report did not confirm which specific organizations were affected or how long the images remained public — questions likely to follow as teams begin to audit their own developer activity.
The takeaway for the open-source community is less about one tool than about where review processes now stop short. If an agent can push a file, the review process needs to look at files — not just code.
```
據 The Hacker News 引述網絡安全公司 Glow 的研究結果報道，被要求為 code review 附上截圖的 AI 編程代理，已將超過 13,000 張公司內部圖片上傳至公開的 GitHub 倉庫。
報道指，相關圖片來自超過 300 個機構的開發者，而資料並非只限於無害的 UI 模擬圖：Glow 的研究人員在檔案中發現了客戶帳單紀錄，以及尚未推出的產品功能的畫面。報道又補充，在大多數情況下，這些圖片存放於開發者的個人 GitHub 帳戶，而非由企業控制的倉庫。
正是最後這一點，令這篇報道不只是關於粗心 prompt 所致的一宗個案。這次外洩並非由入侵或針對性攻擊造成。相反，它揭示了一種日常的 workflow 習慣：有人要求 agent 為審查生成某項代碼變更的視覺化呈現，隨後截圖便如同另一個 artifact 一般被 commit 進倉庫。Agent 不會思考 data classification、retention policy，或者檔案在 push 之後最終流向何處。它們只是以開發者身分，高速地執行一項指令。
個人帳戶如何改變風險面貌
轉移到個人倉庫的做法之所以關鍵，在於它移除了機構通常依賴的保護網。企業的 secret scanning、data-loss-prevention 工具及倉庫治理措施，只適用於機構持有的項目。在個人帳戶下 commit 的檔案，即使所用的 laptop 已納入企業管控，也可能基本上處於這防護範圍之外 —— 而一旦有問題浮現，跟進移除的責任便落到個人貢獻者身上。
這模式同時指向一類安全團隊才剛開始命名的風險：進入 software pipeline 的自動化錯誤。Pull-request 審查流程歷來聚焦於 diff，即有變動的代碼行。但 agent 的輸出正越來越不只是一項建議，而是一個行動。Commits、上傳及生成的資產如今都是輸出的一部分，它們承繼了開發者的權限，卻沒有承繼機構的防護機制。
對於各行各業的 IT 及安全團隊 —— 包括金融服務、物流、專業服務及公共部門 —— 在開發人員機器上採用 AI 編程助手的情況下，實際影響十分直接：最關鍵的圖片通常並不在 diff 裡。
團隊可以考慮的實務措施
參考 Glow 描述的模式，以下幾項控制措施值得權衡：
- 限制 agent 的身分及權限。 明確 agent 可以以哪些帳戶及 token 進行 push，以及是否應以政策禁止 agent 發起的 commits 進入個人倉庫。
- 在源頭處理截圖敏感內容。 在可行的情況下，審查 artifact 優先採用代碼或結構化文字；如必須使用截圖，則應對任何包含憑證、客戶資料或內部識別碼的內容加上遮蔽處理。
- 審查附件，而非只看 diff。 將 pull-request 及 code-review 檢查清單擴展至圖片、日誌及生成檔案，與源碼變更同等審視。
- 掃描與員工相關的個人及公開倉庫。 將對外可見的開發者活動視為組織攻擊表面的一部分，利用團隊現有的員工帳戶身分資料加以追蹤。
- 記錄 agent session。 記錄每個 agent 執行了什麼、commit 了什麼及 commit 的位置，令異常或誤導性的輸出日後可以追溯，而不是在公開層面才被發現。
報道並未確認具體哪些機構受影響，以及相關圖片公開了多久 —— 隨着各團隊開始審計自己的開發者活動，這些問題相信會陸續跟進。
對開源社群而言，這次的啟示與其說與某一個工具有關，不如說是關於審查流程如今止步於哪裡。如果 agent 可以 push 檔案，審查流程就需要審視檔案 —— 而不只是代碼。