Grok Buildの送信問題、修正の時系列とプライバシー設定を読む

当初の報告は、どの環境で何を観測したのか

研究者の調査サイトは、Grok Build CLIの特定バージョンで、リポジトリやGit履歴を含むデータが送信された事案を、修正済みの項目として整理している。元報道が最初に扱ったのはv0.2.93と、一般消費者向けまたはSuperGrokのアカウントによる検証だった。

報告では、AIに開かないよう指示したファイルも含め、Gitで追跡されるデータがgit bundleという形で送信されたという。12GBの検証用リポジトリでは、調査を止めるまでに5.10GiB、約5.48GBが転送されたとされる。これは12GBすべての送信完了を示す数字ではない。

また、検証で認証情報を模した文字列が含まれたことと、実在の認証情報が第三者に悪用されたことは別である。研究者が示したのは送信されたデータの範囲であり、モデルの学習利用や、その後の外部流出が証明されたわけではない。

未追跡のファイルや、無視設定で除外したすべてのデータまで同じように送信されると一般化することも避けたい。どのデータが実験に含まれ、どの条件で通信が観測されたかが、この報告の射程になる。

7月13日の変更を、最初の状態と混ぜない

元記事の追記と研究者の記録によると、7月13日のサーバー側設定変更後、リポジトリ全体のアップロードは既定で停止した。これは、当初の問題が現在も同じ状態で続いているという説明とは異なる。過去の挙動を紹介するなら、修正の経緯も同じ本文に含める必要がある。

一方、研究者は、その後のバイナリにもアップロードの仕組みが残ると記している。ただし、コードが残っていることは、その機能がその時点で実際に作動した証拠ではない。サーバーから返る設定、クライアントの機能、観測された送信を区別して読む必要がある。

削除する方針が表明されたという報道も、外部の研究者が保存先のすべてを検査して削除を証明したこととは違う。利用者は、過去に何が送られた可能性があるかと、今後の利用条件を別々に確認することになる。

/privacyで変わったものは何か

研究者の追加検証記録は、v0.2.99で、設定を切り替えた二つの試行を比較している。7月13日18時17分UTC、日本時間では14日に行った検証だ。どちらの試行でも、リポジトリ全体のbundleは送られなかったと明記されている。

その一方、モデルの応答に必要な通信やセッションの記録、テレメトリーは送られた。研究者が一貫した違いとして挙げたのは、記録の送信先からの応答が、保存する側の200と、破棄する側の204へ変わった点である。

ここで分かるのは、オプトアウトが通信を端末の中に留める仕組みではなく、サーバー側での保持の扱いに関わるということだ。204という応答は観測できるが、サーバー内部の保存状態を外部からすべて検査できるわけではない、という限界も研究者は示している。

この追加検証を、リポジトリ全体の送信が続いた証拠として紹介すると誤りになる。全体送信の停止と、通常の推論・記録の通信が残ることは、同時に成り立つ別の結果だからである。

API、企業契約、一般アカウントを同じ条件にしない

Grok Buildの企業向け公式資料は、認証、ネットワーク、管理設定、データの流れを説明する。セキュリティFAQも、APIのデータ処理条件を調べる資料になる。ただし、これらの説明が、そのまま過去に検証された一般アカウントのすべての経路へ適用されるとは限らない。

特に、モデルの学習に使わない方針、推論のための送信、一定期間の記録、企業向けのZDRは、異なる契約や設定に属することがある。製品名が同じでも、認証方法や組織が変われば、適用される条件を確認し直す必要がある。

公式資料が説明する通信先には、推論や設定に必要なものと、追加機能に使うものがある。通信を止めれば必要な機能も止まる場合があるため、単に「全部遮断する」「全部許可する」の二択ではなく、使う機能とデータの流れを対応づける設計が必要になる。

過去の利用を確かめる際に見る範囲

当サイトの考察として、影響を確認する場合は、使用した時期、CLIの版、アカウント、対象リポジトリ、Git履歴を記録の単位にしたい。現在のフォルダーだけを見ると、過去のコミットにあった情報を見落とす可能性がある。

認証情報が送信された可能性がある場合、ファイルから文字列を消すことと、その認証情報を使えなくすることは異なる。状況に応じて失効や再発行、利用ログの確認を検討する必要がある。ただし、本記事だけで個別の漏洩や不正利用があったと判定できるわけではない。

今後の試験では、実際の秘密を入れず、送信されても問題のない検証用の素材から始める方法が考えられる。ツールへ渡すディレクトリを必要な範囲へ限定し、生成した成果物だけでなく、通信と保存に関する記録も評価する。製品が更新された場合には、以前の検証結果だけを使い続けない方がよい。

無視ファイルの設定を安全性の中心に置く場合も、その版で何を除外する仕様なのかを確認したい。モデルが読む対象から外す設定と、履歴や追加機能による送信から外す設定が同じとは限らないためだ。

プライバシーを、短い一語で済ませない

今回の経緯は、初期の問題報告、サーバー側の変更、追加検証という順序で読むことに意味がある。修正を無視して危険な状態が続くと断定するのも、設定が追加されたからすべてのデータが端末に留まると考えるのも、記録と合わない。

企業で導入する際には、何を送るか、何を保存するか、学習に使うか、削除をどう確かめるかを別々に質問したい。運営会社のRO合同会社の情報も参照し、コード生成の性能だけでなく、自社の情報をどこまで共有する仕組みかを確認する必要がある。

出典：イノベトピアと追記、cereblabの調査、/privacy追加検証、企業向け公式資料。過去の特定条件の観測と、現在の全利用環境の状態を区別した。