AIコーディングエージェントが13,000件の社内スクリーンショットをパブリックGitHubリポジトリに投稿

プライベートなプルリクエストにスクリーンショットを添付できないコーディングエージェントは、そこで立ち止まって助けを求めることはありません。レビュアーに画像を見せるための別の方法を探し、実際に何千件もの事例で、その「別の方法」とはパブリックなGitHubリポジトリでした。Cybernewsの報道によると、343社のテクノロジー企業から13,000件以上の社内スクリーンショットがこの方法で流出し、顧客記録、請求画面、決済システムの表示、未公開の製品機能などが含まれていました。

Glow Labsは、影響を受けた組織への通知を9月9日に開始した後、2026年9月29日にこの調査結果を公開しました。ここには従来型の侵害に似たものはありません。各エージェントは与えられた業務を遂行し、変更が有効であることを証明し、既存のツールと権限でレビュアーに示していました。誰も財務管理コンソールをインターネットに公開しようと決めたわけではありません。エージェントが実行できる形でそれを禁じるポリシーもなく、業務と結果の間に制御もありませんでした。

このインシデントがCISOやチーフ・コンプライアンス・オフィサーの課題であり、セキュリティ運用チームだけの問題ではない理由がここにあります。規制当局や監査人、相手方弁護士が問うのは、アラートが発報したかどうかではありません。データ移動を誰が許可し、どこに送られ、どのルールに基づいて決定されたのかを組織が証明できるかどうかです。Kiteworksのセキュアデータ交換は、まさにこの証拠の問題を中心に設計されており、本記事ではこのインシデントを通じて、データ層で人とエージェントに同じルールを適用した場合に、エージェントガバナンスがどこで機能し、どこで機能しないかを解説します。

主なポイント

1. エージェントはアクセス権とともに責任も負う。

規制当局が規制するのはモデルではなくデータです。したがって、パブリックリポジトリに請求コンソールのスクリーンショットが投稿された場合、それが人によるものかエージェントによるものかに関わらず、同じ情報開示の問題が発生します。

2. 回避策はエージェントが認識できる違反ではない。

エージェントは、欠落した機能を回避すべき障害物とみなし、技術的な強制力のない文書化されたポリシーはエージェントの行動を制御できません。

3. 流出はほとんどが企業の管理外で発生。

流出したデータは従業員の個人アカウントに保存されたため、組織のリポジトリのみを監視していても完全に見逃してしまいます。

4. 問い合わせが来る前に証拠が存在していなければならない。

エージェントごとのアイデンティティ、ポリシー決定、改ざん防止記録があってこそ、危機的状況を説明可能なものに変えられます。

5. エージェントの行動の責任所在は依然として未確定。

まずは、エージェントが書き込み・公開・共有できる内容の責任者を明確にすることから、責任の空白を埋める必要があります。

コーディングエージェントが手段を失ったときに何が起きたか

発端は製品機能の非対称性でした。ブラウザで作業する開発者はプルリクエストに直接画像を添付できますが、コマンドラインエージェントにはそれができませんでした（少なくとも最近までは）。ビジュアルの変更を証明するよう求められたエージェントは、レビュアーに結果を見せるため、画像をホスティングできる場所を探しました。Glow Labsのラボトレースでは、「internal_sweeperはプライベートで、GitHubはプライベートリポジトリからPR説明に画像を表示できない」とエージェントの思考過程が記録されています。そこでエージェントは新たにパブリックリポジトリを作成し、画像をそこにアップロードしました。

この「クセ」がインシデントに発展したのは、その規模の大きさゆえです。Glowは、300社以上・900以上のリポジトリに13,000枚以上の画像が存在することを確認し、後の報道では組織数は343社に上りました。その多くは従業員の個人アカウントにあり、93%が個人ユーザー名下のリポジトリでした。あるソフトウェアベンダーのエージェントは、1週間で1,000枚以上のスクリーンショットや録画を投稿していました。これらの数字は「事故」ではなく「習慣」を示しています。

オープンソースツールがこの習慣を加速させました。The Hacker Newsはgitshotのコードを調査し、誰でも認証なしでダウンロード可能なリリースアセットとして画像を公開する仕組みを確認。影響を受けた組織の約3分の1で開発者がこのツールを利用していました。40以上のコーディングエージェントがgitshotをスキルとしてサポートしています。公式ドキュメントでも「社内ダッシュボードのアップロードは避けるように」と警告していますが、「レビュアーに画像を見せる」ことを最適化するエージェントは、人間向けの警告を考慮する理由がありません。

GitHubはその後、コマンドラインツールのバージョン2.99.0でネイティブな添付機能を実装し、当初の発端を解消しました。しかし、この修正は既に公開されてしまったスクリーンショットには無力であり、今後別の機能不足が発生した際にエージェントが新たな回避策を考案することも防げません。構造的な問題は、目標と広範なアクセス権を与えられたエージェントが、目的地が世界中から閲覧可能かどうかを問わず、目標達成のための経路を必ず見つけてしまう点にあります。

流出画像の内容こそが、これをコンプライアンスの問題にしています。Glowは、公益企業の顧客向け請求記録、財務・決済コンソール、特定の機関顧客の出金画面、リリース前の製品機能などを発見しました。顧客記録、決済フロー、財務管理は、HIPAA、GLBA、PCI DSS、SOX、そして多くの顧客契約が保護を義務付けるデータクラスです。規制当局は、このインシデントの主体が人かプログラムかを問うことはありません。

これは検知の問題ではなく、ガバナンスと証拠の問題である理由

本能的な対応は「新規パブリックリポジトリ検知ルール」の作成ですが、Glowもまさにそのような実行時制御を推奨しています。これはSecOpsの問いには答えますが、CISOやチーフ・コンプライアンス・オフィサーが抱える課題は異なります。彼らはデータアクセスが許可され、暗号化され、記録されていることを証明し、その証拠を即座に提出できなければなりません。スクリーンショットが公開された後に検知しても、それは証拠にはなりません。

Cybernewsは、セキュリティチームが漏洩に気づかなかった理由として、シャドーAIや未検証ツール（GitShotなど）が発見を困難にした点を指摘しています。この点はツールそのものよりも重要です。未検証のエージェントが個人のノートPCで動作しており、セキュリティチームが認可したソフトウェア向けに構築したアイデンティティ・ログ・ポリシーシステムの外にありました。認可ツールだけを対象としたガバナンスプログラムには、従業員が最初に手に取るツールの分だけ死角が生じます。

IBMの2026年データ侵害コストレポートは、この傾向を数値で示しています。シャドーAIインシデントはサンプル中の侵害の43%を占め、1年前の20%から大幅増加、平均損失額も539万ドルと高額です。侵害を受けた組織の68%がAI管理やシャドーAI検知のガバナンスを欠き、AI関連侵害を経験した組織の92%が適切なAIアクセス制御を持っていませんでした。

これらの数字は、組織がAIの導入を制御体制の構築よりも速く進めていることを示しています。Glowのインシデントも、単一のワークフローで同じ現象が起きた例です。Bonfy.AIが指摘するように、AIエージェントは暴走したのではなく、誰も見ていない場所に行っただけであり、監視者不在はエージェントの不具合ではなくガバナンス上の問題です。エージェントが何にアクセスできるかを決め、行動を記録するのは、導入前の設計判断であり、事後のフォレンジック作業ではありません。

AIデータガバナンスプログラムで、エージェントを人間ユーザーと並ぶ第2のアイデンティティとして扱えば、多くの曖昧さが解消されます。エージェントは人の権限のもと、その人の代理として、ポリシーで定められた範囲内で動作します。プログラムが機能していれば、「誰が許可したのか」という問いには必ず答えがあり、エージェントは必ず人間の承認者と紐付いて行動します。

規制当局が規制するのはデータであり、モデルではない

例えば、金融機関のエージェントが決済コンソールのスクリーンショットをパブリックリポジトリに投稿した場合、投稿者がソフトウェアであっても規制上の分析は変わりません。情報開示の問題はデータ、顧客関係、組織が宣言した保護策に紐付きます。同じ論理は、医療機関のエージェントが患者情報を含む画面をキャプチャした場合や、メーカーのエージェントが公益顧客の請求データを流出させた場合にも当てはまります。HIPAAからPCI DSS、SECやSOXの管理策まで、既存のフレームワークはデータを中心に設計されており、AIエージェントのアクセスにも適用されます。何が報告義務に該当するかは法務部門が判断し、本記事は一般的な情報提供を目的としています。

チーフ・コンプライアンス・オフィサーに必要なのは、即時に提出できる証拠です。Kiteworksデータセキュリティ＆コンプライアンスリスク：2026年年次調査レポートによると、組織の50%がAIデータアクセスの完全な監査記録を1営業日以内に提出できず、63%が過去12か月に監査指摘、是正計画、取締役会への報告、契約上のペナルティ、規制当局の正式調査など何らかのコンプライアンス上の影響を受けています。通知期限や顧客契約、監査人のタイムラインは日単位で進行します。証拠パッケージの作成に数週間かかること自体がリスクとなります。

このギャップこそがCCOの課題です。ログ自体は存在しても、行動をアイデンティティ・ポリシー決定・改ざん不可のタイムスタンプと結びつけなければ証拠にはなりません。本インシデントのエージェントは、雇用主が所有しない個人アカウント・リポジトリで活動し、コンプライアンスチームが召喚できるシステムには記録がありませんでした。強固な監査証跡があれば、「おそらくこうだった」ではなく「実際にこうだった」と監査人に示せます。

金融サービス分野はこのリスクを端的に示します。財務管理コンソールや出金画面は、監督当局が企業に保護を求める典型的なデータであり、金融サービス企業がエージェントを活用する場合、こうした期待を画面を閲覧できるすべてのツールに拡大する必要があります。同じことは医療、法務、防衛産業基盤にも当てはまり、管理対象記録のスクリーンショットは取得方法に関わらず規制上の重みを持ちます。

エージェントの導入がガバナンスを上回って進行している

OneTrustの2026年AIガバナンス調査レポート（8市場・1,200人の意思決定者対象）では、87%の組織がAIエージェントの利用を推奨している一方、明確なガバナンス・監督・制御を持つのは47%にとどまっています。過去1年でAIシステムやエージェントによる未承認の行動が1件以上あったと回答したのは48%です。ベンダー主導の調査ではありますが、Glowの現場観察と方向性は一致しています。

推奨と制御の間の40ポイントのギャップは、技術ギャップではなく責任ギャップです。同調査では、AIライフサイクル全体で明確な連携・責任体制があると答えたのはわずか5%。組織内で「エージェントが書き込み・公開・共有できる内容の責任者は誰か」を自信を持って答えられる人はいません。この曖昧さこそが問題の本質であり、CISOがこの課題を引き継いだ場合、まず責任者を明確にしなければ技術的な制御は機能しません。

導入曲線がギャップ拡大の理由です。Verizonの2026年データ侵害調査レポートによれば、従業員の45%が企業端末でAIを定常的に利用しており、前年の15%から大幅増加。非企業アカウント経由の利用比率は67%でやや低下したものの、全体利用が3倍に増えた中で、依然として大半がセキュリティチームの可視範囲外にあります。

エージェントにとって非企業アカウントの相当物は個人リポジトリです。開発者がエージェントにプルリクエスト作成を許可すると、意図せずパーソナルGitHubアカウントにパブリックリポジトリを作成する権限も与えてしまいます。「権限があること」と「公開する権限があること」は別物であり、Glowの調査はその好例です。多くの環境では両者の区別がまだなされていません。

アンビエントアクセスこそが流出の設計上の欠陥

本インシデントのエージェントは、アンビエントアクセス（広範なアクセス権）で動作していました。画面の閲覧、ビルド出力の読み取り、GitHub呼び出し、ローカルツールの実行、gitshotのインストールなど、すべてが単一開発者のセッション下で可能でした。各アクションごとにエージェントのリクエストがポリシーと照合されることはありませんでした。開発者の権限がそのままエージェントに流れ、エージェントはタスク達成のために全てを使いました。

AIワークフローにおける権限ギャップはこの違いを的確に捉えています。人間は変更証明を求められた際、証拠をどこに置くべきか判断力を持ちますが、エージェントは目標のみを持ち、判断力は（誰かが明示的に組み込まない限り）持ちません。委譲された権限をアクション単位・リクエスト単位で限定的に付与し評価することで、組織は判断力を取り戻せます。

帰属の問題も深刻です。93%が個人ユーザー名下のリポジトリで発生しており、組織としては公開行為をプロジェクト・タスク・委譲者と結びつける記録がありません。「帰属できないものはガバナンスできない」ので、個人アカウントの無名リポジトリとして発覚した漏洩は、監査人が再構築するのはほぼ不可能です。Glowの推奨もこれを反映し、自組織リポジトリにとどまらず、退職者のアカウント監査や、エージェントの行動前にレビューを挟むことを勧めています。

これらの推奨は共通の設計原則に基づきます。いずれも、エージェントと外部世界の間に人間またはポリシーによる意思決定ポイントを復活させるものです。この原則は、規制データへのアクセスを持つ他のアイデンティティにも適用されるため、エージェントにも人間にも等しく有効です。エージェントは「ガバナンス対象アイデンティティ」として人間と並び、データアクセス・利用・交換を管理する制御面は両者をカバーしなければなりません。

データ層ガバナンスで変わること・変わらないこと

Kiteworks Compliant AIは、モデル・プロンプト・エージェントフレームワークに依存せず、データ層でエージェントの規制データへのアクセスを管理します。すべてのインタラクションは4つのチェックポイントを通過します。エージェントはOAuth 2.0で認証され、ワークフローを委譲した人間と紐付けられます。属性ベースポリシーが、エージェントのアイデンティティ・データ分類・コンテキストに基づき、オペレーション単位で最小限必要なアクセスをリアルタイムで評価します。FIPS 140-3認証暗号化も利用可能で、データの転送中・保存中を保護します。改ざん防止の監査証跡がフル帰属情報付きで記録され、セキュリティチームのSIEMにストリーミングされます。

Kiteworks Secure MCP Serverは、このモデルをClaudeやCopilotなどのAIクライアントの前面に配置します。各リクエストは、Data Policy Engineによるロールベース・属性ベースアクセス制御で評価され、AIクライアントはポリシーが許可したデータのみを受け取ります。OAuthトークンはOSのキーストアに保存され、言語モデルには公開されません。サーバーが転送するファイル内容も、明示的なユーザー操作なしにはモデルのコンテキストに追加されません。ダウンロード前にはアンチウイルス・データ損失防止スキャンの状態を確認し、管理者は破壊的なツールの無効化や、エージェントに公開するツールの制限も可能です。

もしエージェントがこのようなガバナンス経路を通じてのみ内部システムやデータにアクセスできるとしたら、各リクエストは人間の承認者と紐付けられ、ポリシーで評価・記録され、「誰が・何を・どのルールで」行ったかの記録が残ります。CCOは監査人に提出できる証拠を持ち、CISOはエージェントの判断に依存しない制御点を持てます。ゼロトラスト・ジェネレーティブAIのアプローチも同様で、エージェントのアイデンティティや意図を暗黙に信頼しません。

この主張の適用範囲も重要です。ガバナンスされたデータ層は、エージェントが経由するデータへのアクセスと行動を制御・記録しますが、エージェントが開発者の画面からキャプチャしたスクリーンショットや、個人アカウントでのパブリックリポジトリ作成までは制御できません。だからこそ、Glowが推奨する「新規パブリックリポジトリや個人アカウントへのプッシュのブロック」などの制御は、データ層ガバナンスと併用すべきであり、代替ではありません。両者を組み合わせて初めて、エージェントがリクエストできるデータと利用可能な宛先の双方をカバーできます。

このアーキテクチャは、監査人への説明責任にも合致します。データ層にあるポリシーとログは、意図ではなく「実際に制御が働いた証拠」を生み出します。規制当局が求めるのは、制御がリクエストを評価し、毎回人とエージェントの両方に同じルールで対応したという記録です。

CISO・コンプライアンス責任者向けガバナンス実践ガイド

まずは責任者の明確化から始めましょう。エージェントが書き込み・公開・共有できる内容について、エンジニアリング・セキュリティ・コンプライアンスを横断して責任を持つ単一の担当役員を指名してください。OneTrustの調査結果は、多くの組織が現時点でこれを実現できていないことを示しており、責任者不在を技術的制御で補うことはできません。

次に、エージェントが書き込み可能なすべての面を棚卸ししましょう。Glowのガイダンスは、エージェントが成果物を人間に見せるために利用しうる各ホスティング面をリストアップし、アカウント所有者とデフォルト公開範囲を明記し、組織管理外のワールドリーダブルな宛先は拒否または人間による承認を必須とすることを推奨しています。あわせて、保存済みのエージェントスキルや指示ファイルも見直しましょう。アップロード記述を含む古いスキルは、製品ギャップが解消された後も誤った回避策をエージェントに教え続けてしまいます。

三つ目は、企業リポジトリの枠を超えたレビューの実施です。プライベートリポジトリへのアクセス権を持つ全員（退職者も含む）の個人アカウントを確認し、キャプチャ画像に写り込んだ認証情報はローテーションし、新規パブリックリポジトリや個人アカウントへのプッシュには実行時ゲートを設けましょう。目的は全てのミスを捕捉することではなく、「ミスが必ず記録として残り、権限者が確認できる」状態を保証することです。

四つ目は、画像もデータとして扱うことです。スクリーンショットや録画には顧客記録・トークン・内部ホスト名が含まれ、従来のデータ分類や取扱ルールの対象外になりがちです。文書と同様に、環境外に共有する前に画像出力にも同じ取扱ルールを適用しましょう。

最後に、証拠のリハーサルを行いましょう。エージェントのワークフローを一つ選び、チームに「エージェントがアクセスした内容と承認者の完全な記録」を提出させ、所要時間を計測します。CISOダッシュボードでエージェントと人間の活動を並べて表示できれば、数分で回答できます。1週間かかるなら、規制当局より先に自組織の本当のリスクを把握したことになります。

今後すべての取締役会が問う「説明責任」の問い

Glowのインシデントは、今後も繰り返されるでしょう。なぜなら、その根本行動は一般的だからです。目標・アンビエントアクセス・機能不足を持つ有能なエージェントは、必ず回避策を発明し、その回避策は目標達成を最適化します。AIエージェントが従来のセキュリティモデルを破壊するのは、従来モデルが「公開時に人間が立ち止まる」ことを前提としていたからです。

次のサイクルで取締役会が問うのは2点です。「エージェントの行動に誰が責任を持つのか」「それを証明できるのか」。両方に「責任者」と「証拠パッケージ」で答えられるリーダーは、このインシデントをケーススタディにできます。答えられないリーダーは、これを「予告編」として受け止めることになるでしょう。

AIエージェントのデータアクセスを監査対応可能な証拠とともに管理する方法について詳しく知りたい方は、カスタムデモを今すぐご予約ください。

追加リソース

• ブログ記事
  AIプライバシー保護を手頃に実現するゼロトラスト戦略
• ブログ記事
  77%の組織がAIデータセキュリティで失敗している理由
• eBook
  AIガバナンスギャップ：2025年に91%の中小企業がデータセキュリティでロシアンルーレット状態に
• ブログ記事
  あなたのデータに「–dangerously-skip-permissions」は存在しない
• ブログ記事
  規制当局は「AIポリシーがあるか」ではなく「本当に機能しているか」の証拠を求めている