ZCode Gitスナップショットインシデント：AIコーディングエージェントが閲覧、アップロード、記憶できるもの

ZCodeのリポジトリアップロードインシデントは、1つのコーディングツールだけの問題ではありません。AIエージェントにプロジェクトへのアクセスを与える前に、開発者が答える必要性を増しているセキュリティ上の問いを浮き彫りにしています。「リポジトリへのアクセス」とは、現在のファイル、作業ツリー、それとも何年分ものGit履歴を意味するのでしょうか？

この区別が重要なのは、.gitには、現在のコードベースからは見えなくなった情報、たとえば削除済みの秘密情報、過去のソースコードのバージョン、reflog、LFSアセット、ローカルブランチの履歴などが含まれている可能性があるためです。ZCodeは影響を受けたアップロード動作を修正したと説明していますが、このインシデントは、AIコーディングエージェントには、単に「リポジトリへのアクセス」を許可するだけでなく、明示的なデータ境界が必要であるという教訓を残しました。

ZCodeで実際に何が起きたのか？

2026年9月18日、開発者のferstarは、アプリケーションのローカルデータディレクトリに予想外に大きなファイルがあることに気づき、ZCode 3.12.3のリバースエンジニアリング調査を公開しました。

元の調査によると、クライアントは、ソースファイルだけでなく、.git、Git LFSオブジェクト、reflog、リポジトリメタデータも含み得る、暗号化されたワークスペーススナップショットを作成していました。クライアントには、アップロード認証情報を取得し、暗号化アーカイブをAlibaba Cloud OSSへ送信するパイプラインも含まれていました。

その後ZCodeは、コードベースのインデックス作成とRepo Wikiに関連するリポジトリデータのアップロードを認め、謝罪し、動作は修正済みであると説明するとともに、オープンソース化と第三者レビューの計画を発表しました。当時の報道では、ZCodeの対応の主な内容が再掲されています。

これは最初に解消すべき重要な情報の空白です。インシデントは実際に発生しましたが、一部の拡散した要約では、転送に成功した内容が誇張されていました。

313MBのプライベートリポジトリは実際にアップロードされたのか？

いいえ。

商用プロジェクトのスナップショットには約42,000個のファイルが含まれ、約313MBの暗号化アーカイブが作成されました。研究者の9月19日の更新によると、それはローカルに残ったまま 保留中 アップロード制限を超えたため、564回の失敗後の状態。([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

別の小規模な公開リポジトリは、実際にサービスに到達しました。538個のファイルが含まれ、はるかに小さい暗号化ペイロードが生成されました。

したがって、正しい結論は「すべてのZCodeリポジトリがアップロードされた」ではありません。旧クライアントには、機能するリポジトリのアップロード機構が含まれており、実際に成功するかどうかはスナップショットに依存していた、ということです。

このインシデントで`.git`ディレクトリが最も重要な部分である理由

研究者が取得した大規模なスナップショットでは、ペイロードの大部分は現在のソースコードではありませんでした。

つまり、スナップショットの約86.6%は.gitから取得されたものでした。([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

これにより、セキュリティ上の解釈は完全に変わります。

AIエージェントが現在のソースツリーを読み取ると、開発者が現在意図的に残しているものを確認できます。Git履歴にアクセスすると、開発者がすでに削除したと思っていたものが明らかになる可能性があります。

過去に公開された可能性があるものには、次のようなものがあります。

• 削除されたソースファイル
• 古いAPIキーまたはトークン
• 以前の内部エンドポイント
• 放棄された機能
• 過去の設定
• ローカルブランチの活動履歴
• reflogにのみ存在する状態
• 大容量の過去のLFSアセット

Git reflogのドキュメントでは、reflogがローカル参照の以前の値を記録すると説明されています。対応する履歴がリモートリポジトリに一度もプッシュされていない場合でも、これらの記録がローカルに存在することがあります。

これにより、次のような有用なセキュリティルールが得られます。

「プロジェクトを読む」権限と「Git履歴を読む」権限は分けるべきです。

コードから削除したシークレットが残り続ける理由

最新のファイルから認証情報を削除しても、Gitから必ず削除されるとは限りません。

開発者が誤ってAPIキーをコミットし、次のコミットで削除して、現在のファイルが完全にクリーンになったことを確認する場合があります。それでも、以前のblobはリポジトリ履歴を通じて到達可能な状態で残ることがあります。

GitHubの機密データの削除に関するガイダンスでは、履歴を書き換える前に、公開された認証情報を失効またはローテーションすることを明確に推奨しています。

この順序が重要です。

1. 認証情報を無効にします。
2. 必要に応じて、機密性の高い履歴を削除します。
3. シークレットが再びコミットされるのを防ぎます。

AIコーディングエージェントにとって、これは履歴を認識する機能が、通常のエディター表示ではもはや公開されていないデータにアクセスできることを意味します。

これは、読み取り専用エージェントが自動的に低リスクになるわけではない理由も説明しています。ファイルシステムの対象範囲が広すぎる場合や、取得したコンテンツがリモートモデルに送信される場合、読み取り専用アクセスでも価値のある情報が漏えいする可能性があります。

モデルコンテキスト、テレメトリ、学習、リポジトリのアップロードは同じものではない

もう一つの重要な教訓は、1つの「プライバシー」切り替えだけでは、AIコーディングツールが持ちうるあらゆる種類のデータフローを表現できないということです。

影響を受けたZCodeのバージョンが重要なのは、研究者が、その最適化/学習オプションを無効にしても、別個のスナップショットパイプラインは無効にならなかったと報告しているためです。報告書ではさらに、そのバージョンではRepo Snapshot Indexingの切り替えを無効にしても、パッケージ化とアップロードの試行を阻止できなかったとされています。([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

このことから、ZCodeをはるかに超えて適用できる原則が導かれます。

「自分のデータを学習に使用しないでください」は、「自分のデータを送信しないでください」という意味ではありません。

クラウドモデルには依然として推論コンテキストが必要です。テレメトリが別のエンドポイントを経由することもあります。同期によって別のコピーが保持される可能性もあります。リポジトリのインデックス作成には、独自のデータ経路がある場合があります。

同じ区別は、ローカルAIエージェントがクラウドツールを使用する場合にも当てはまります。プライバシーはメインのエージェントプロセスがどこで実行されるかではなく、境界を越えて送信される具体的なデータに左右されます。

暗号化では、最も重要なプライバシーの問いには答えられない

影響を受けたZCodeのスナップショットは、アップロード前に暗号化されていました。

リバースエンジニアリングの報告書では、アーカイブにAES-256-CTR暗号化を使用し、対称鍵をRSA-OAEP-SHA256でラップしていると説明されています。RSA公開鍵はサービスから提供されていましたが、対応する秘密鍵はローカルに保存されていませんでした。([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

これはユーザー管理のエンドツーエンド暗号化とは異なる方法でデータを保護します。

つまり、「リポジトリは暗号化されていた」という説明だけでは不十分です。

より重要な問いは次のとおりです。

誰が復号できるのか？

この同じ原則は、プライベートRAG、クラウドバックアップ、AIメモリ、暗号化されているからデータが保護されていると主張するあらゆるシステムにも当てはまります。

コーディングエージェントには、実際にどの程度のリポジトリアクセスが必要なのか？

コーディングエージェントには、従来のオートコンプリートよりも多くのコンテキストが正当に必要です。リポジトリ全体にわたるリファクタリングでは、多数のファイルが必要になる場合があります。デバッグエージェントには、テスト、依存関係のメタデータ、Gitの状態、ビルド出力が必要になることがあります。

ただし、「エージェントには広範なコンテキストが必要かもしれない」ことは、「すべての機能にリポジトリ内のすべてのバイトを渡すべきだ」という意味ではありません。

これは、ツール実行の信頼境界で用いられている原則を、データアクセスに適用したものです。モデルが何かを要求できるからといって、周囲にあるすべてのものへのアクセス権や外部送信権限が自動的に与えられるべきではありません。

コーディングエージェントには、独立した2つの境界が必要です。

• 操作境界：エージェントが変更または実行できるものは何か？
• データ境界：エージェントが読み取ったり送信したりできるものは何か？

書き込み権限のないエージェントでも、読み取り権限とネットワーク権限が無制限であれば、深刻なプライバシー侵害を引き起こす可能性があります。

インシデント後、ZCodeは何を変更したのか？

このインシデントについて、現在のZCodeバージョンにも同じ挙動が存在すると分かっているかのように説明すべきではありません。

ZCode 3.14.0を追跡調査したところ、調査者は以前のアップロード用サイドカーが削除され、古い認証情報エンドポイントが404を返すようになったと報告しました。調査対象のパスには、以前のリモートアップロード機構なしでローカルのチェックポイント機能が残されていました。([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

現在のRepo Wikiのドキュメントでも、より限定されたデータ境界が説明されています。

Wikiコンテキストでは次の項目が除外されると記載されています。

• .git
• 依存関係ディレクトリ
• ビルド出力
• キャッシュ
• ローカルランタイム状態
• 対応 .gitignore 除外
• 機密情報を含む可能性のある設定ファイル
• シンボリックリンクのターゲット

Repo Wikiの出力は、リポジトリに書き戻されるコンテンツではなく、ローカルアプリケーションデータとして記録されています。

これは、バージョン3.12.3で報告されたスナップショットの挙動とは実質的に異なります。

オープンソースであればコーディングエージェントはプライベートになるのか？

いいえ。

オープンソースであればクライアントの監査は容易になりますが、オープンソースのアプリケーションでも、ソースコードをクラウドモデルに送信したり、テレメトリをアップロードしたり、状態を同期したり、プロバイダーが管理するストレージに依存したりする可能性があります。

より有用なチェックリストは次のとおりです。

そのため、プライベートAIアーキテクチャは、ソフトウェアライセンスがたまたまオープンソースかどうかよりも、そのデータフローによって定義されます。

開発者は新しいAIコーディングエージェントをどのように監査すべきか？

開発者がすべてのアプリをリバースエンジニアリングする必要はありません。しかし、新しいエージェントにとって、機密性の高い商用リポジトリを最初のテスト環境にすべきではありません。

1. データ取り扱いに関するドキュメントを読む。推論、テレメトリ、トレーニング、インデックス作成、同期、バックアップを分けて確認します。
2. 除外ルールを確認する。.git、.env、無視対象ファイル、依存関係、認証情報、シンボリックリンクを重点的に確認します。
3. 使い捨てのリポジトリから始める。まずは機密性のないコードを使用します。
4. ローカルアプリのストレージを調べる。予期しない大容量のキャッシュやスナップショットは、隠れたデータ範囲を示している可能性があります。
5. 外部送信トラフィックを監視する。ファイアウォール、DNS、プロキシ、ルーターのログから、リモートサービスを特定できます。
6. 無害なカナリアファイルを使用する。関係のないファイルがモデルやアップロードのコンテキストに含まれるかどうかをテストします。
7. まず最小限の権限を付与する。特定のタスクで必要になった場合にのみ、権限を拡大します。

ここでも、最小権限のエージェント設計が役立ちます。ただし、「読み取り専用」を、無制限のリポジトリ可視性ではなく、限定されたパスと制御された外部送信と組み合わせることが条件です。

ローカル優先のコーディングエージェントが異なる方法で行うべきこと

ローカル優先とは、すべてのタスクをオフラインで実行しなければならないという意味ではありません。

これは、デフォルトではローカルデータをローカルの信頼境界内にとどめ、外部への送信を偶発的ではなく意図的に行うことを意味します。

この原則はコーディングに限りません。真にローカルなAIワークフローでは、重要なデータ経路を最初から最後までローカルに保つ必要があります。埋め込み、インデックス作成、認証、ファイル処理のいずれかが、気付かないうちにリモートサービスに依存しているなら、モデルをローカルにインストールしただけでは不十分です。

ハイブリッドシステムでは、プライベートファイルをローカルサービスの背後に置き、承認済みのリモートツールには必要最小限のコンテキストだけを公開する方法が、より堅牢なパターンです。これは、ローカルファイルシステム全体を公開せずにクラウドサービスを利用するエージェントを設計する際にも使われるアプローチです。

より大きな教訓：リポジトリへのアクセスはセキュリティ権限である

ZCodeから得られる長期的な教訓は、「クラウドコーディングエージェントは決して使うな」ということではありません。リポジトリへのアクセス自体が、独立したセキュリティ権限になったということです。

現代のコーディングエージェントは、次の機能を組み合わせることがあります。

• プロジェクト全体の読み取り
• Git認識
• ターミナル実行
• ブラウザーアクセス
• リモートモデル
• バックグラウンドタスク
• 長期メモリ
• 自律的なファイル編集

つまり、開発者はエージェントが実行できるコマンドだけでなく、より広い範囲を確認する必要があります。

さらに、次の点も確認する必要があります。

• どのファイルを監視できますか？
• どこまで過去の履歴を参照できますか？
• そのデータのうち、どれがマシン外へ送信されますか？
• どのサービスが受け取りますか？
• どのくらいの期間保持されますか？
• 誰が復号できますか？

AIコーディングエージェントにおいて、プライバシーはもはや、モデルがコードでトレーニングされるかどうかだけの問題ではありません。エージェントのデータ境界が、実際に依頼したタスクと一致しているかどうかが重要です。