ZCodeのGit履歴アップロード、コーディングの利便性を信頼の問題へと変える

ZCodeは、データ収集を制限しているように見える設定にもかかわらず、Git履歴を含む345 MBの開発者ワークスペース全体をアップロードしたとされる。報告されたZCodeのGit履歴アップロードは、AIプロンプト用に選択されたファイルだけに限定されていなかった。そこには、長年にわたる非公開の開発作業を保持し得るリポジトリオブジェクト、reflog、キャッシュされた大容量ファイルが含まれていた。

9月18日に公開された技術調査は、ZCodeのクローズドなデスクトップアプリケーションを通じてこの挙動を追跡した。その分析によると、クライアントはユーザーがサインインしている間に暗号化されたワークスペースチェックポイントを作成し、Alibaba Cloud Object Storage Serviceへ転送していた。

この発見は、Z.aiによる独立監査済みの開示ではなく、第三者によるリバースエンジニアリングの主張にとどまる。公開時点で入手可能な公式資料では、報告されたアップロード範囲、チェックポイントの保持期間、またはユーザーがそれを防ぐ方法について明確に説明されていなかった。

この検証上の空白自体が、この問題の一部である。ZCodeは、ワークスペースを理解し、コマンドを実行し、長時間に及ぶタスクを復元するよう設計されたエージェントとともにGLMモデルを推進している。しかし、オープンウェイトモデルであっても、それを取り巻くデスクトップアプリケーションが透明になるわけではない。

したがって中心的な対立は、ZCodeと他のコーディングアシスタントの比較ではない。製品上で見えるプライバシー制御と、隠れたチェックポイントシステムに帰される挙動との乖離である。

ZCodeのGit履歴アップロード報告が明らかにしたこと

この調査は、ZCodeが単一のモデルリクエストに必要なコードだけでなく、リポジトリアーカイブを取得したと主張している。

研究者は、42,411個のファイルを含む非公開の商用ワークスペースを調査した。元のディレクトリは約345 MBを占めていた一方、ZCodeの暗号化チェックポイントは約313 MBだった。

報告された内容は特に示唆的だった。約196.1 MBは、Git Large File Storageが大きなプロジェクト資産をキャッシュできる.git/lfsディレクトリに由来していた。さらに102.2 MBは、ファイル内容、ディレクトリツリー、コミットから成るGitの基盤データベースである.git/objectsから来ていた。

reflogは約0.6 MBを追加した。現在のソースファイル、設定、ドキュメントは約46.2 MB、測定対象の13.4パーセントを占めていた。

この個別スナップショットでは、.gitディレクトリがアーカイブデータの86.6パーセントを占めた。これは、すべてのZCodeインストールにおける平均値を示すものではない。ただし、この事象を通常のコードアップロードと呼ぶことが、報告された範囲を過小評価する理由を示している。

元の報告によると、ZCodeはローカルアプリケーションデータ内にチェックポイントを作成し、暗号化アーカイブの隣に平文のマニフェストを残していた。このマニフェストには、影響を受けたワークスペースの絶対パスが露出していたとされる。

リバースエンジニアリングによると、ZCodeはZ.aiのサービスにアップロード認証情報を要求した。応答には、オブジェクトキー、署名付きアップロードフォーム、サイズ制限、およびRSA公開鍵が含まれていた。

クライアントはワークスペースを圧縮し、AES-256-CTRで暗号化し、RSA-OAEP-SHA256を使用して対称鍵をラップしたとされる。その後、暗号化オブジェクトをAliyunのストレージエンドポイントへ直接POSTした。

転送完了後、コールバックがZ.aiのバックエンドへ通知したと報告されている。この再構成が正しければ、このアップロードは過剰なコンテキストを含む偶発的なモデルリクエストではなく、設計されたアプリケーションフローだったことになる。

暗号化は開示に関する問題を解決しない。実装が正しいことを前提に、コンピューターとストレージサービスの間にいる観測者からデータを保護するものだ。意図されたサービス運営者が情報にアクセスすることを防ぐものではない。

報告書によれば、対応するRSA秘密鍵はサーバー側の管理下に置かれていた。その結果、リポジトリを提供したユーザーは、同じコンピューターに保存されたチェックポイントを復号して確認できなかった。

この違いは重要である。「暗号化されている」は「ベンダーが利用できない」と聞こえるかもしれないが、両者は同義ではない。暗号化が保護する範囲は、関連する鍵を誰が管理しているかによって決まる。

報告書はまた、画面上で確認できる2つのプライバシー設定が、チェックポイントの作成や転送を停止しなかったと主張している。この申し立ては独立した製品監査では確認されておらず、Hacker Newsの参加者の一人は対応するチェックポイントディレクトリを見つけられなかったと報告している。

この違いは、製品バージョン、オペレーティングシステム、アカウントの状態、段階的な展開、または特定機能の利用を反映している可能性がある。また、元の事例がすべてのユーザーに当てはまらないことを示している可能性もある。

Z.aiはこれらの条件を明確にする必要がある。それまでは、研究者が少なくとも1つのテスト環境でこの挙動を記録した一方で、その実際の普及度は不明である、というのが最も安全な記述となる。

完全な.gitディレクトリが現在のコードより機微性が高い理由

Gitリポジトリには、現在のファイルにはもう現れない情報を含め、プロジェクトの記憶が格納されている。

開発者は.gitを「履歴」と表現することが多いが、そこにはgit logの出力以上のものが含まれる。オブジェクト、参照、ブランチ情報、設定、reflog、その他のリポジトリメタデータが保存されている。

Gitは本質的にコンテンツアドレス可能なデータベースである。blobオブジェクトはファイル内容を保持し、treeオブジェクトはディレクトリの状態を記述し、commitオブジェクトはスナップショットを履歴として接続する。

公式のGitオブジェクトモデルは、これらの要素が.git/objects内に残る仕組みを説明している。そのディレクトリをコピーするアプリケーションは、ワーキングツリーに見えているファイルよりはるかに多くを受け取る可能性がある。

月曜日に開発者が誤ってAPI認証情報をコミットし、火曜日に削除したケースを考えてみよう。現在のファイルには認証情報が表示されなくなっていても、以前のオブジェクトはリポジトリ履歴を通じて到達可能な状態で残ることがある。

最新のコピーを削除するだけでは不十分だ。GitHubの機密データの削除に関するガイダンスは、開発者に対し、まず露出した認証情報を無効化し、その後で協調的な履歴書き換えを検討するよう求めている。

同じ問題は、非公開証明書、内部ホスト名、顧客識別子、環境ファイル、テストフィクスチャに埋め込まれた認証情報にも当てはまる。リポジトリには、放棄されたアーキテクチャ、セキュリティ修正、未発表製品、ライセンス関連資料も残り得る。

reflogはリスクをさらに広げる。ローカル参照がどのように移動したかを記録し、共有ブランチ上ではもはや見えないコミットへのアクセス経路を保持することがある。

ローカルブランチには、一度もプッシュされなかった取り組みが現れる可能性がある。コミットメッセージには、顧客、脆弱性、従業員、社内インシデントの名前が記されていることがある。リポジトリ設定は、非公開リモートやインフラストラクチャのドメインを特定し得る。

Git LFSは別のカテゴリをもたらす。そのキャッシュには、設計ファイル、データセット、メディア、パッケージ化されたモデル、または開発者がアシスタントの直接的なコンテキスト外だと合理的に考えるその他のバイナリが含まれる場合がある。

したがって、報告された196.1 MBのLFSコンポーネントは重要でない大量データではなかった。それは、プロジェクト内で最もテキスト性が低く、商業的機密性が高い資料の一部を表している可能性がある。

コーディングエージェントが広範なローカルアクセスを正当に必要とする場合はある。関連モジュールの読み取り、テストの実行、依存関係の理解なしに、複雑なアプリケーションをリファクタリングすることはできない。

しかし、そのローカル権限が、プロセスからアクセス可能なすべてを永続的なクラウドコピーとして作成する許可を自動的に意味するわけではない。要求されたタスクのためにファイルを読むこと、推論のために選択したコンテキストを送信すること、リポジトリ全体をアーカイブすることは、それぞれ別の操作である。

これが、ZCodeのGit履歴アップロードの主張が、クラウド型コーディングアシスタントがコードを処理するという観察よりも深刻である理由だ。争点は範囲、永続性、制御、開示にある。

開発者は、関数とその依存関係を含むモデルリクエストを意識的に承認するかもしれない。同じ開発者が、LFSキャッシュ、削除済みの認証情報、休眠中のブランチ、長年分のコミットオブジェクトのアップロードを拒む可能性もある。

企業ユーザーには追加の懸念がある。リポジトリには、顧客契約、ソースコードエスクロー条件、輸出規制、データレジデンシー規則、従業員アクセス方針によって管理される資料が含まれることがある。

重要なのは、単に暗号化が使用されたかどうかではない。セキュリティチームは、何が収集され、どこに保存され、誰が鍵を保持し、どれだけの期間残り、削除がどのように機能するかを知る必要がある。

プライバシー制御とチェックポイントは異なる説明をしているように見える

最も深刻な懸念は、ユーザーが制御できる内容と、アプリケーションが行ったとされる内容との間にある、報告上の隔たりである。

ZCodeの公式ドキュメントは、ワークスペースの状態、ファイル参照、タスク、Gitブランチのコンテキストを理解するエージェントについて説明している。そのエージェントドキュメントでは、より長期的な開発タスクを支援する機能の一部として状態復元も提示されている。

チェックポイントは正当な目的に役立ち得る。数十のファイルを編集するエージェントには、変更失敗後の復元、状態の比較、クラッシュで中断された作業の回復を行う手段が必要になる。

しかし、その機能はチェックポイントを不可視にする必要性を意味しない。また、.gitのすべてをリモートアーカイブに含める必要性を立証するものでもない。

プライバシーを保護する設計では、デフォルトでGitオブジェクトとLFSキャッシュを除外できる。転送前に正確なアーカイブマニフェストを公開し、チェックポイントをローカルに保持し、クラウド同期前に明示的な承認を求めることもできる。

また、リモートスナップショットをブロックする組織ポリシーを提供することもできる。管理者はリポジトリレベルの除外設定を強制し、監査ログを通じてその効果を確認できる。

一方で調査は、ZCodeのアーカイブ処理がエージェントの可視ツールループの外で動作していたと主張している。エージェントに列挙されたツールには、ユーザーが承認できるスナップショットまたはアップロード操作が含まれていなかったとされる。

そのアーキテクチャであれば、コマンド権限が転送を止められなかった理由を説明できる。ホストレベルのサイドカーは、ユーザーがシェル実行やファイル変更を制限している場合でも、モデルのツールとは独立して実行できる。

これは現在のエージェントインターフェースにおける盲点も示している。権限プロンプトは通常、コマンド実行、ファイル編集、ネットワークアドレスの開封といった目立つ操作に焦点を当てる。

バックグラウンドサービスはあまり注目されない。会話に現れることなく、フォルダのインデックス作成、診断情報の収集、セッションの同期、復元用アーティファクトの作成を行うことができる。

ここでは推論と同期の違いが重要になる。選択したコードをクラウドモデルに送信することは、クラウドを利用するアシスタントに対して大半のユーザーが予想するほど十分に可視化されている。

ロールバックやインデックス作成のために基盤となるリポジトリデータベースをコピーすることは、第二のデータフローである。それには独自の説明、範囲制御、保持ルール、削除インターフェースが必要となる。

ZCodeの現在のプライバシーポリシーは、サービス提供、義務の履行、正当な事業上の利益の保護、安全性または安定性の改善に必要な範囲で個人データを保持する場合があるとしている。また、保持期間はデータの種類、機微性、目的、法的要件に応じて異なるとしている。

これらの一般的な説明は、報告書が提起した疑問には答えていない。ポリシーでは、ワークスペースチェックポイントがユーザー入力、技術データ、または別のカテゴリとして扱われるのかを特定する必要がある。

また、どのストレージリージョンが適用されるのか、下請け事業者がアーカイブを処理するのか、アカウント削除によってすべてのチェックポイントが削除されるのかも説明すべきである。ユーザーには、具体的な保持期間、または関連機能に結び付いた明確な基準が必要だ。

最も重要なのは、Z.aiがプライバシー設定の切り替えがチェックポイントのアップロードに影響するかどうかを文書化することだ。データ収集に関するラベルの付いたコントロールが、分析には適用される一方でワークスペースの同期には適用されない場合、誤った安心感を生む可能性がある。

コントロールの文言と配置は、その内部実装と同じくらい重要だ。大きく異なるデータフローが曖昧な用語の下にまとめられていれば、開発者は十分な情報に基づく判断を下せない。

Z.aiが取り得る最も強力な対応は、修辞的なものではなく技術的なものだ。影響を受けるバージョン、有効化の条件、アーカイブの除外対象、エンドポイント、暗号化における役割、保持期間、削除手順を列挙すべきである。

また、報告後に動作が変更されたかどうかも説明すべきだ。その詳細がなければ、ユーザーはアップデートで問題が修正されたのか、それともローカルの証拠が取り除かれただけなのかを判断できない。

Open Weightsはクローズドなコーディングエージェントをローカル化しない

この事案は、モデルそのものと、モデルが何を参照でき、何がマシン外へ出るかを決めるソフトウェアとを切り分けている。

GLMモデルはZ.aiの開発者向け戦略の中核であり、一部のリリースはOpen Weightsとして配布されている。開発者はそれらのモデルファイルを調査し、自らのインフラ上で互換バージョンを実行し、ホスト型推論エンドポイントを回避できる。

ZCodeは異なるレイヤーだ。これはコンテキストの選択、ツールの呼び出し、セッションの保存、チェックポイントの管理、クラウドサービスへの接続、自己更新を担うハーネスである。

基盤となるモデルがローカルで動作していても、ハーネスはプライバシー上の結果を左右し得る。ローカルモデルであっても、周囲のアプリケーションがテレメトリー、インデックス、セッション履歴、復旧スナップショットを外部に送信することを防ぐわけではない。

同様に、Open Weightsのモデルでも、クローズドなElectronアプリケーションがバックグラウンドプロセスで何を行うかを明らかにはできない。研究者はネットワークトラフィックを観察し、アプリケーションバンドルを調査し、リリース後の動作を再構成する必要がある。

これが主要な信頼上の対立点である。ZCodeの製品体験はローカルワークスペースの理解を強調している一方、報告書は開発者の想定を超えるクラウドへの取得メカニズムを記述している。

競合製品も開発者データを処理しているため、適切な比較は「ZCodeはコードをアップロードするが、他のエージェントはすべてローカルに留まる」というものではない。それは不正確だ。

Claude Code、GitHub Copilot、Codex、Cursorなどのクラウド接続ツールは、ユーザー入力やコードコンテキストの一部をリモートサービスへ送信する。リポジトリインデックス、エージェントセッション、クラウドタスク環境は、追加のコピーを生み出し得る。

違いは開示とコントロールに現れる。たとえばGitHubはコンテンツ除外ポリシーを文書化し、一部のCopilot機能ではそれらの除外がサポートされないことを説明している。

GitHubはさらに、GitHub外のリポジトリに対するセマンティックインデックス作成がいつデータをアップロードするかを文書化し、エンタープライズ管理者がその機能を有効化する必要があると説明している。これらのコントロールにも制約はあるが、ユーザーはデータフローを特定し、評価できる。

これがZ.aiが現在直面している基準だ。製品がクラウド推論に依存するなら、ベンダーがコードが一切コンピューターを離れないと約束する必要はない。

必要なのは、各転送を正確に説明することだ。一時的なプロンプトコンテキストと永続的なリポジトリスナップショットを区別し、管理者に強制可能なコントロールを提供しなければならない。

オープンソースのハーネスは一つの対応策を示す。そのコードからアーカイブの除外対象、ネットワークエンドポイント、更新時の動作を確認でき、独立したレビュアーは文書化された設定が実装と一致するかを検証できる。

オープンソースは完全なセキュリティ保証ではない。すべての依存関係を調査するユーザーはほとんどおらず、署名済みバイナリが公開コードと異なる場合もあり、侵害されたアップデートは依然として害を及ぼし得る。

クローズドソースのツールも自動的に悪意あるものになるわけではない。独立した評価を受け、詳細なデータマップを提供し、テナント制御を強制し、検証可能なネットワーク動作を公開することはできる。

しかし、不透明性は検証コストを引き上げる。アプリケーションが広範なファイルシステム権限と自律実行機能を持つ場合、そのコストは重大なセキュリティ上の考慮事項となる。

Hacker Newsでの議論は、両方の見方を反映していた。複数のコメント投稿者は、クローズドなコーディングハーネスはいかなるものでも受け入れがたいリスクだと捉えた一方、クラウドエージェントは本質的にプロジェクトコンテキストを受け取るものだと指摘する声もあった。

あるユーザーは、ZCodeを使用しているにもかかわらず、報告されたチェックポイントディレクトリを再現できなかったと述べた。ほかのユーザーは、ベンダーや国を問わず、サンドボックスはすべてのプロプライエタリな開発者ツールを制約すべきだと主張した。

これらの反応は、二つの異なる責任を示している。ベンダーはデータフローを開示しなければならず、開発チームはエージェントが到達できる範囲を制限しなければならない。

どちらの責任も、もう一方を打ち消すものではない。サンドボックス化は同意ではなく、プライバシーコントロールは有効な封じ込めではない。

当面のリスクはリポジトリの内容と製品バージョンに依存する

この証拠は緊急のレビューを裏付けるが、すべてのZCodeユーザーで同じデータがアップロードされたことを証明するものではない。

文書化された事例は、1つのワークスペースと1つの観測されたアプリケーション構成に関するものだった。公開報道では、どれだけのインストール環境でチェックポイントが作成されたか、その動作がいつ始まったか、すべてのオペレーティングシステムで同じパスがたどられたかは確立されていない。

ユーザーが特定の復旧機能またはインデックス機能を有効にする必要があったかも不明だ。報告では転送がサインイン状態と関連付けられているため、認証状態も重要になり得る。

バージョン履歴も重要だ。後のリリースでは、以前の観測を無効にすることなく、ディレクトリ、エンドポイント、除外設定、スケジュール動作が変更されている可能性がある。

この不確実性は主張を限定すべきであり、調査を抑制すべきではない。プライベートリポジトリでZCodeを使用したチームには、インシデントレビューを実施する十分な根拠がある。

まずは対象範囲の特定から始めるべきだ。どの開発者がZCodeをインストールし、どのバージョンを実行し、いつサインインし、その期間にどのリポジトリへアクセスできたかを特定する。

次に、Z.aiおよびAliyunのサービスとの通信について、エンドポイント、プロキシ、DNS、ファイアウォール、エンドポイント検知のログを調べる。ローカルのチェックポイントファイルは役立つ可能性があるが、その不在だけでは転送がなかったことを決定的には示せない。

組織はアプリケーションをアンインストールまたは更新する前に証拠を保全すべきだ。アップデートによってログ、保存パス、バイナリが変更され、調査担当者が活動を再構成するための手掛かりが失われる可能性がある。

セキュリティチームは、公開されたリポジトリの履歴にコミットされた認証情報はすべてレビューが必要だと想定すべきだ。GitHubは、最新ファイルから削除しても無効化にはならないため、漏洩した認証情報をローテーションするよう推奨している。

その対応は適切な規模にとどめるべきだ。開発者1人がZCodeをインストールしただけで、すべての企業認証情報をローテーションしてはならない。まずリポジトリをマッピングし、次にその履歴を検索して、どのシークレットが有効なまま残っていたかを検証する。

リポジトリの所有者は、シークレット以外の機密性の高い情報も調査すべきだ。古いコミットには、法務レビューを要する顧客データ、脆弱性の詳細、内部エンドポイント、ライセンス資産、交渉内容が含まれている可能性がある。

リポジトリに規制対象または契約上制限されたデータが含まれていた場合、法務およびコンプライアンスチームは通知義務を評価すべきだ。答えは、管轄区域、契約文言、確認された転送の証拠、対象データによって決まる。

ZCodeのテストを継続する開発者は、これを隔離すべきだ。専用の仮想マシンまたはコンテナは可視のファイルシステムを制限できるが、ネットワークとマウントされたディレクトリには依然として慎重な構成が求められる。

実際の認証情報や商業上の履歴を一切含まない、使い捨てのリポジトリを使用する。ホームディレクトリ、SSHフォルダ、クラウド設定、パッケージ認証情報、無関係なソースツリーをマウントしない。

ファイルシステムの制限はチェックポイントディレクトリをブロックできるが、脆弱な防御策だ。パスやプロセスはアップデートごとに変わる可能性があり、書き込みを拒否すると復旧動作が無効になったり、アプリケーションが動作しなくなったりする可能性がある。

ネットワークコントロールも別の層を提供する。チームは送信先を制限し、接続試行を記録できるが、必要なサービスをブロックすると製品が使用不能になる可能性がある。

より安全な長期モデルでは、明示的な許可リストを用いる。エージェントには限定されたプロジェクトチェックアウト、一時的な認証情報、タスクに必要なサービスのみを与える。

このアプローチはZCodeだけでなく、engineering workflows全般で有用だ。ファイルシステムおよびシェルへのアクセスを持つ自律アシスタントは、特権的な開発依存関係として扱うべきである。

目的は、不完全な証拠から悪意を証明することではない。文書化されていない動作がもたらす影響を減らすことだ。

Z.aiが信頼の隔たりを解消したかを示す3つのシグナル

次の試金石は、Z.aiが文書化されていないデータフローを、限定的で可視化され、検証可能な製品機能へと転換できるかどうかだ。

最初のシグナルは、詳細な公開回答である。Z.aiは報告されたZCodeのGit履歴アップロードを認めるか反論し、影響を受けるバージョンを特定し、どの製品状態がそれを引き起こしたのかを説明すべきだ。

有用な声明は、測定されたアーカイブ内容に直接対応するものになる。.git/objects、.git/lfs、reflog、無視されたファイル、グローバル設定が含まれていたかを明示すべきだ。

Z.aiがデータは暗号化されているという一般的な保証だけを公表しても、中心的な懸念は残る。同社が復号鍵を管理していたと報告されているため、転送時の暗号化はアクセスや保持に関する疑問への答えにならない。

2つ目のシグナルは、強制可能なチェックポイントコントロールである。ZCodeには、リモートスナップショットを停止でき、組織による管理が可能で、分析やモデル学習の設定とは独立した設定が必要だ。

ユーザーはログまたは文書化されたネットワークイベントを通じて、その設定を検証できるべきだ。アプリケーションは最初の転送前に、何をアップロードしようとしているかを表示すべきである。

デフォルトの除外対象には、.git、LFSキャッシュ、無視されたファイル、認証情報、一般的なシークレットの保存場所を含めるべきだ。タスクで本当に必要な場合に限り、ユーザーが追加の履歴をオプトインできるようにすることが考えられる。

ローカル専用の復旧オプションは、緊張の大部分を解消するだろう。特にエージェントとモデルが同一マシン上で動作する場合、チェックポイントはクラウドアーカイブにならずともロールバックを支援できる。

3つ目のシグナルは、独立した再現だ。研究者は、サポートされるオペレーティングシステム、既存および新規アカウント、異なるプライバシー設定にわたって、現行リリースをテストする必要がある。

この作業では、元の動作が普遍的だったのか、条件付きだったのか、すでに変更されているのかを明らかにすべきだ。また、製品を通じてチェックポイントを削除した場合に、サーバー側のすべてのコピーも削除されるかを検証すべきである。

第三者評価は、特に評価者が対象範囲と手法を公開する場合、Z.aiの対応を強化する。再現可能なパケットキャプチャとアーカイブマニフェストは、広範な認証表現よりも価値が高い。

開発チームにとって、この教訓は一つのアプリケーションを超える。コーディングエージェントをソフトウェアサプライチェーンの構成要素として棚卸しし、そのエンドポイントを文書化し、プライベートリポジトリへのアクセスを与える前にデータフローをレビューするべきだ。

5つの直接的な質問をするべきだ。エージェントは何を読み取れるのか。何を送信するのか。何がリモートに永続化されるのか。誰が鍵を保持するのか。どのコントロールが各転送を停止するのか。

ベンダーがこれらの質問に答えられない場合、答えられるようになるまで、エージェントを使い捨て環境に制限するべきだ。回答が「暗号化されている」という点だけに依存しているなら、誰が復号できるのかを問うべきである。

報告されたZCodeのGit履歴アップロードは、すべてのユーザーの情報公開を確立したわけでも、いかなるアーカイブの悪用も証明したわけでもない。しかし、正確な対応を求める信頼できる不一致を確立している。

Z.aiは、メカニズムを公開し、デフォルトを修正し、実際に機能するオフスイッチを提供し、独立した検証を支援することで、その隔たりを狭められる。それまでは、開発者はZCodeで可視化されているワークスペースを、収集の最大境界ではなく、取り得る最小の収集境界として扱うべきだ。