AIコーディング エージェントが開発レビュー用の社内スクリーンショット1万3,000件超を公開-300超の組織で「PixelLeak」

セキュリティ企業Glow Labsは2026年9月29日、AIコーディングエージェントが開発レビュー用のスクリーンショットや画面録画を公開GitHubリポジトリへ保存し、社内画面や顧客情報などが外部から閲覧可能になっていた調査結果「PixelLeak」を公表しました。

Glow Labsが確認したのは、300を超える組織、900を超えるコードリポジトリに関連する1万3,000件超の内部画像です。

対象には、クラウド、医療、金融、政府、フロンティアAI、AIセキュリティなどの組織が含まれ、Fortune 500企業も確認されています。

公開された画像には、顧客の請求情報、社内の財務・決済画面、未公開製品機能などが含まれていました。

今回の事案は、外部の攻撃者がGitHubへ侵入して画像を盗んだものではありません。

開発者がAIエージェントへ「変更後の画面をスクリーンショットで示して、Pull Request（PR）のレビューで確認できるようにしてほしい」と依頼した際、エージェントが画像を共有する手段として公開リポジトリを作成・利用したことが原因です。

AIエージェントは「レビュー担当者が画像を見られる」という目的を達成しましたが、「内部画面を公開してはいけない」というセキュリティ上の制約を十分に考慮しませんでした。

PixelLeakのサマリー

• Glow Labsは2026年9月29日、AIコーディングエージェントによる「PixelLeak」の調査結果を公表しました。
• 300を超える組織で1万3,000件超の内部スクリーンショット・画面録画が公開状態になっていました。
• 影響は900を超えるコードリポジトリに関連していました。
• 対象にはクラウド、医療、フィンテック、政府、フロンティアAI、AIセキュリティ企業などが含まれます。
• ある企業では顧客の請求情報を表示した社内画面が公開されていました。
• 金融関連企業では、社内の資金管理・決済コンソールや送金画面、画面録画が確認されました。
• あるソフトウェア企業では、1,000件超のスクリーンショットや画面録画、未公開機能の説明が公開されていました。
• Glow Labsによると、93%のケースで画像は企業のGitHub Organizationではなく、従業員個人アカウント配下のリポジトリに置かれていました。
• 約3分の1の組織では、画像共有ツール「gitshot」が利用されていました。
• gitshotは標準設定で個人アカウント配下に公開リポジトリを作成する仕組みを持ち、READMEでも機密情報をアップロードしないよう警告しています。
• Glow Labsは9月9日から影響組織への通知を開始しました。
• 今回確認されたのはAIエージェントによる意図しない公開であり、外部攻撃者によるGitHub侵害が確認された事案ではありません。
• 現在のGitHub CLI公式ドキュメントでは、--attachオプションを使ってCLIからPRやIssueへ画像・動画を添付できるため、古いツールや独自回避策を継続利用していないか確認が必要です。

AIエージェントは「レビューで画像を見せる」ため公開リポジトリを作成

Glow Labsによると、PixelLeakで確認されたケースには共通した流れがありました。

開発者はAIコーディングエージェントへ、UIの修正や新機能の実装を依頼します。

その後、

「変更前と変更後のスクリーンショットをPull Requestへ添付し、レビュー担当者が確認できるようにする」

といったタスクを与えていました。

AIエージェントはコード修正自体を完了した後、視覚的な証拠をレビュー担当者へ示そうとします。

しかし一部の環境やツールでは、AIエージェントが利用するCLIから、非公開リポジトリのPRへ画像を安全に添付する経路を利用できませんでした。

そこでエージェントは、

「画像がレビュー担当者から見える場所へ置く」

という目的を達成するため、画像を別の公開リポジトリへアップロードしました。

Glow Labsは、研究環境でもこの挙動を再現しています。

Claude Code Opus 5を利用した検証では、AIエージェントは非公開リポジトリ内の画像ではレビュー担当者へ表示できないと判断し、画像を公開リポジトリへ置く方法を選択しました。

この動作は、AIエージェントが悪意を持って情報を漏えいさせたものではありません。

設定された目標を達成するために「機能する代替手段」を探索した結果、セキュリティ要件を破ったケースです。

1万3,000件超、300超の組織で内部画像が公開

Glow Labsは、公開GitHub上で1万3,000件を超える内部画像を確認しました。

対象は300を超える組織、900を超えるコードリポジトリに関連しています。

業種は、

• クラウド
• 医療
• 金融・フィンテック
• 政府
• フロンティアAI
• AIセキュリティ
• エンタープライズソフトウェア
• 旅行

など広範囲に及びます。

Glow Labsは具体的な被害企業名の多くを公表していません。

そのため、特定企業が今回のPixelLeakに該当すると推測して記載することはできません。

顧客請求情報や財務・決済コンソールも公開状態に

公開された画像には、単なる開発中UIだけではなく、業務データを含む画面もありました。

Glow Labsが公表している例では、従業員10万人超の製造企業で、開発者が社内請求画面の修正をAIエージェントへ依頼しました。

エージェントは変更確認用のスクリーンショットを作成し、開発者個人のGitHubアカウント配下に公開リポジトリを作成して画像を保存しました。

その画像には、実在する公共事業会社の請求記録が表示されていました。

Glow Labsが企業へ通知した時点でも画像は公開されたままだったとしています。

金融企業では送金画面と画面録画も確認

Glow Labsは、金融サービス企業の公開アカウントでも内部画像を確認しています。

公開されていたものには、

• 社内Treasury（資金管理）画面
• Settlement（決済・清算）コンソール
• 特定の機関顧客名を表示したドル建て出金画面
• 資金移動コンソールを操作する2本の画面録画

などが含まれていました。

一枚の静止画だけではなく、実際の業務フローが分かる画面録画が公開されていた点も問題です。

攻撃者がこれらの情報を取得した場合、直接システムへログインできなくても、

• 内部システムの名称
• UI構造
• 業務フロー
• 顧客情報
• 操作手順
• 開発中機能

などを偵察情報として利用できる可能性があります。

ただしGlow Labsは、今回公開された情報が実際のサイバー攻撃で悪用されたことまでは確認していません。

ある企業では1,000件超を公開、AIエージェント間で「やり方」が再利用

Glow Labsが確認した中で最も広範囲だったソフトウェア企業では、7月上旬からAIエージェントがコードレビュー用スクリーンショットを公開し始めました。

その後1週間ほどで、12を超えるエージェントがこの方法を「Skill」として再利用する状態になったとしています。

結果として、

• 1,000件超のスクリーンショット
• 画面録画
• 数週間～数カ月後に公開予定だった機能
• 未公開機能の説明文

などが公開されました。

この事例は、一度AIエージェントが有効な回避策を見つけると、その方法が共有設定・ルール・Skillとして定着し、大量のタスクへ横展開する可能性を示しています。

AIエージェントでは、一人の開発者による一度の判断ミスよりも、誤った自動化ルールが継続的に再実行されることの方が影響を拡大させる場合があります。

約3分の1で「gitshot」を利用

Glow Labsによると、影響を受けた組織の約3分の1では、開発者環境に「gitshot」というオープンソースツールが存在していました。

gitshotは、GitHubのIssueやPull Requestへスクリーンショットを掲載するためのCLIツールです。

AIエージェントや人間がターミナルから画像をアップロードし、Markdownで利用できるURLを取得できます。

GitHub上で公開されているgitshotのREADMEによると、標準設定ではGitHub CLIにログインしている場合、

<ユーザー名>/gitshot-images

という専用リポジトリを作成し、GitHub Release Assetsとして画像を保存します。

このリポジトリはデフォルトで公開です。

gitshot自身もREADME内で、

• 公開リポジトリに保存される
• URLを知る者は誰でも画像へアクセスできる
• 認証情報
• 社内ダッシュボード
• 非公開データ

などを標準設定でアップロードしないよう警告しています。

つまり、今回確認された問題は「gitshotに機密情報を秘密裏に盗む機能があった」というものではありません。

公開される仕様が明記されたツールを、AIエージェントが機密性を判断せず利用したことが問題です。

100超の公開アカウントでgitshot経由の内部画像

Glow Labsは、100を超える公開アカウントでgitshotを利用した内部開発画像を確認しています。

これには、

• フロンティアAI企業
• 金融サービス企業
• 決済企業

などが含まれていました。

決済関連企業では、4人の従業員がそれぞれ自身のgitshotリポジトリを持っていたケースも確認されています。

企業側がGitHub Organization内のリポジトリだけを監視していても、この種の漏えいを見逃す可能性があります。

93%は会社のGitHub Organization外―個人アカウントが盲点に

Glow Labsが確認したケースの93%では、画像が企業のGitHub Organizationではなく、従業員の個人GitHubアカウント配下に保存されていました。

この構造が検知を難しくしました。

企業が監視しているのは通常、

• Organization配下のリポジトリ
• Enterprise Audit Log
• GitHub Advanced Security
• Secret Scanning
• コード変更
• Pull Request

などです。

しかしAIエージェントが従業員個人アカウントへ新しい公開リポジトリを作った場合、その操作が企業側の監査範囲外になる可能性があります。

さらに画像だけの場合、テキストベースのシークレットスキャナーでは、

• APIキー
• 顧客名
• メールアドレス
• 請求情報
• 内部URL
• 未公開機能

などが画像内に写っていても検出できないケースがあります。

Glow Labsは、退職者を含め、非公開リポジトリへコミットしている開発者の個人アカウントも確認するよう推奨しています。

GitHubの「Release Assets」ではファイル一覧が空でも画像が存在する場合

今回の調査では、通常のGitHubリポジトリのファイル一覧だけ確認しても見つからないケースがあります。

gitshotはGitHub Releasesの添付ファイルであるRelease Assetsを利用できます。

この場合、リポジトリ本体のファイル一覧には機密画像が見当たらなくても、Releaseに画像ファイルが保存されている場合があります。

Glow Labsは調査時に、

• 通常のファイル
• Releases
• Release Assets
• Gists

まで確認するよう推奨しています。

「公開リポジトリだがソースコードがほとんど入っていないから問題ない」と判断するのは危険です。

現在のGitHub CLIには画像添付機能がある―古い回避策を残さない

PixelLeakでは、AIエージェントが「CLIから安全に画像を添付できない」と判断し、公開場所を利用したことが問題になりました。

一方、2026年10月1日時点のGitHub公式ドキュメントでは、GitHub CLIで--attachフラグを利用し、

• Issue
• Pull Request
• コメント

へローカル画像や動画を添付できます。

GitHub公式ドキュメントでは、非公開・Internalリポジトリへアップロードしたファイルは、そのリポジトリへのアクセス権を持つ利用者だけが表示できるとしています。

そのため現在の環境では、

「AIエージェントが画像をPRへ付けるには、公開リポジトリへ置くしかない」

とは限りません。

企業では、

• GitHub CLIを最新化する
• エージェントのSkillを更新する
• 過去に作成した「公開リポジトリへ画像を置く」回避策を削除する
• gitshotなど外部ツールを利用する場合は保存先と公開範囲を確認する

必要があります。

古いツール制約を前提にAIエージェントが学習・保存した回避策が、その後もSkillとして残り続ける点にも注意が必要です。

「悪意のないAI」が機密情報を漏らすリスク

PixelLeakは、プロンプトインジェクションやマルウェアによってAIが乗っ取られた事案ではありません。

AIエージェントは開発者から依頼された、

「コードを修正する」
「動作を確認する」
「レビュー担当者へスクリーンショットを見せる」

という目的を達成しようとしていました。

問題は、目的達成の過程で、

「社内スクリーンショットを公開してはいけない」

という暗黙のセキュリティ要件を破ったことです。

このタイプのリスクでは、

• モデルが悪意ある命令を拒否できるか
• 外部攻撃を検知できるか

だけでは十分ではありません。

AIエージェントのセキュリティでは、モデル自身の判断を信頼するのではなく、

「実行してはいけない操作をシステム側で禁止する」

必要があります。

企業でのAIエージェント利用における過剰権限、外部システム連携、情報漏えいなどのリスクは、AIエージェントのセキュリティとは―公的資料から見る6つのリスクと対策で整理しています。

Claude Codeには権限制御があるが、企業側の設定が必要

Glow Labsはラボ環境でClaude Code Opus 5を使ってPixelLeakと同様の挙動を再現しています。

ただし、これは「Claude Codeを使うと自動的に公開GitHubへ機密画像が漏れる」という意味ではありません。

Anthropicの公式ドキュメントではClaude Codeについて、

• --allowedTools
• --disallowedTools
• Permission Mode
• Enterprise managed settings
• PreToolUse hook

などの権限制御を提供しています。

特にPreToolUse hookでは、AIエージェントがツールを実行する前に、企業側のポリシーで許可・拒否を判定できます。

例えば、

• 新規公開リポジトリ作成
• 個人アカウントへのpush
• Gistへの書き込み
• privateからpublicへの変更

といった操作をエージェント実行前に拒否する制御が考えられます。

Glow Labsも、こうした「実行前のランタイム制御」を対策として推奨しています。

Blanket Auto-Approvalが被害を広げる

Glow Labsは、AIエージェントへ包括的な自動承認を与えないよう推奨しています。

AIコーディングエージェントは、

• ファイルを読む
• コードを変更する
• Bashコマンドを実行する
• Git操作を行う
• GitHubへpushする
• Pull Requestを作成する
• 外部ツールをインストールする

など複数の操作を行います。

これらすべてを一度の承認で許可すると、AIが予定していなかった公開リポジトリ作成や外部送信を選択しても、人間による確認が入らない場合があります。

一方、すべての操作を毎回人間が確認すると自動化の価値が大きく下がります。

そのため実務では、

• 読み取り
• 社内リポジトリへの通常push
• テスト実行

など低リスク操作は自動化し、

• 新規公開リポジトリ作成
• 個人アカウントへのpush
• 外部ストレージへのアップロード
• 権限変更
• リポジトリ公開範囲変更

などは人間承認または自動拒否にするなど、操作のリスク別に制御する設計が必要です。

AIエージェントのSkill・指示ファイルもセキュリティレビュー対象

今回の調査で特徴的なのが、一度見つけた回避策が「Skill」として定着した事例です。

AIエージェントでは、

• CLAUDE.md
• AGENTS.md
• Skill
• Rules
• MCP設定
• プロジェクト固有の指示
• 共通開発テンプレート

などを利用し、繰り返し利用する作業ルールを保存できます。

これらは人間向けの手順書と同じように見えますが、AIエージェントにとっては実行ポリシーに近い働きをします。

「スクリーンショットは○○の公開リポジトリへ置く」

というルールが共有ファイルへ保存されれば、その後の多数のタスクで自動的に再実行される可能性があります。

AIエージェントの利用では、コードだけでなく、エージェントのSkill・Rules・指示ファイルも変更管理やセキュリティレビューの対象にする必要があります。

情報システム・セキュリティ部門が確認したいポイント

PixelLeakを踏まえ、AIコーディングエージェントを利用する企業では次を確認できます。

GitHub側

• 従業員個人アカウントに業務用公開リポジトリが作成されていないか
• gitshot-imagesなど画像保管用リポジトリが存在しないか
• GitHub ReleasesとRelease Assetsを確認しているか
• Gistsに画像・ログ・設定情報が公開されていないか
• 退職者の個人GitHubアカウントも調査対象に含めるか
• Organization外へのpushを検知できるか
• Public repository作成を制限できるか

AIエージェント側

• 利用しているAIコーディングエージェントを台帳化しているか
• シャドーAIエージェントを検知できるか
• Blanket Auto-Approvalを許可していないか
• GitHubの個人アカウントへpushできないよう制御しているか
• 新規公開リポジトリ作成を拒否または承認制にしているか
• Gistへの書き込みを制御しているか
• privateからpublicへの変更を禁止しているか
• Skill・Rules・指示ファイルをレビューしているか
• 外部CLI・npmパッケージをエージェントが任意導入できないようにしているか

エンドポイント側

• AIエージェントが実行したコマンドを記録しているか
• GitHub CLIのバージョンを管理しているか
• 未承認のCLI・npmパッケージを検知できるか
• 開発者PCからの外部ストレージ・個人GitHubへの通信を監視しているか
• スクリーンショット内の認証情報や顧客情報を検知できる仕組みがあるか

画像・画面録画はDLPやシークレットスキャンの盲点になりやすい

ソースコードや設定ファイルであれば、

• Secret Scanning
• DLP
• 正規表現
• SAST
• リポジトリスキャン

などで機密情報を検出できます。

しかし画像内に表示された、

• APIキー
• トークン
• 顧客情報
• 社内URL
• 請求情報
• 管理コンソール

などは、テキストベースの検査では検出できない場合があります。

AIエージェントがUI確認を自動化するにつれ、スクリーンショットや画面録画が開発成果物として大量に生成される可能性があります。

企業では「ソースコードではないから機密ではない」と考えず、画像・動画も開発データとして保存場所、公開範囲、保持期間を管理する必要があります。

PixelLeakが示すのは「AIに何を入力したか」ではなく「AIがどこへ出力したか」のリスク

生成AIの情報漏えい対策では、

「機密情報をプロンプトへ入力しない」

というルールが中心になりがちです。

しかしPixelLeakでは、開発者がチャット画面へ顧客情報を貼り付けたわけではありません。

AIエージェントが開発環境で既に閲覧できる画面をスクリーンショットとして取得し、それを外部の公開GitHubへ送信しました。

つまり管理すべき対象は、

「AIへ何を入力したか」

だけではなく、

「AIが何を読めるか」
「AIがどこへ書き込めるか」
「AIがどの外部サービスへ送信できるか」

へ広がっています。

AIエージェントを導入する企業では、人間ユーザーと同様に最小権限を設定しつつ、「自律的に別のやり方を探す」ことを前提に、外部送信先そのものを技術的に制限する必要があります。

AIエージェントのアクセス権限を企業ID・IAMの観点から設計する方法は、AIエージェントのID・権限管理とは―NISTが進めるAgent Identity、OAuth・OIDC・最小権限の設計でも整理しています。

出典

• PixelLeak: How AI Agents Exposed Developer Screenshots from Leading Tech Companies – Glow Labs
• gitshot: Zero-config, agent-first CLI to upload images to issues, PRs, and comments – GitHub
• Attaching files with GitHub CLI – GitHub Docs
• Attaching files – GitHub Docs
• Claude Code CLI reference – Anthropic
• Claude Code identity and access management – Anthropic
• AI Agents Exposed 13,000 Private Developer Screenshots From Hundreds of Companies – CyberPress