Grok Build事件「ソース公開」の2日前に何が起きたか

xAIが7月15日にコーディングエージェント「Grok Build」のソースコードを公開する2日前、深刻な問題が浮かぶ。一般ユーザーがホームディレクトリ全体をクラウドにアップロードされたと報告し、研究者がmitmproxyで実測したところ、エージェントが読んだ約192KBに対して5.1GBが送信されていた。27,800倍の転送量差だ。だが最も重要なのは、ユーザーが「ファイルを開くな」と指示したのに、そのファイルがgit履歴ごと復元できたという点。つまり送信されたのはエージェントが読んだファイルではなく、リポジトリ全体のgit bundleだった。

この事件の本質は「xAIがずさんだった」というゴシップではなく、AIエージェント全般に当てはまる3つの構造的問題を露呈させたことにある。第一に、プライバシートグルが「送信するか」ではなく「送ったあと学習に使うか」を制御していたこと、つまりUIの想定と実装の不一致。第二に、権限設定がモデルへの入力は制御するがクライアント自体の通信は制御しないという、2つのレイヤーの混同。これはxAI固有ではなくローカルで動くツール全般の構造だ。第三に「オープンソース化」が「監査できる」と「参加できる」を区別していないこと。論が立つほうは「コードが見える」であり「開発に参加できる」ではない。

明日やるべきは3点。7月13日以前にシークレットを含むリポジトリでGrok Buildを実行したなら、APIキーやDBパスワードをローテーションする。ただし「ファイルを消した」では不十分で、git履歴も対象。次に、手元のすべてのエージェントについて、研究者が公開した検証手順を試す。mitmproxyでHTTPS通信を傍受し、カナリアファイル（エージェントが読む理由のないマーカー文字列入り）を置いて「開くな」と指示して実行し、実際の送信内容にマーカーが現れるかを確認する。これで「エージェントが読んだもの」と「クライアントが送ったもの」の距離を自分の環境で測れる。最後に、使っているツールのドキュメントで「テレメトリにコード・プロンプト・ファイルパスが含まれるか」を明記している記述を探す。これが日常的な防御になる。