公式 llms.txt が coding agent に所有者不在のパッケージをインストールさせ、ドキュメントのサプライチェーンが実行境界に

Pandex Research は、大企業、テクノロジー企業、防衛関連サプライヤーのドメイン6,214件をスキャンし、それぞれの `llms.txt` と `llms-full.txt` を解析した。研究者の元データによると、8,565件のファイルに、第三者が登録可能なパッケージ、ドメイン、クラウドサブドメインが237件超含まれていた。一方、Ars Technica は、8,265件のファイルのうち120サイトに、該当するコマンドが合計227件残されていたと報じている。この2組の集計値は、公開データセットや訂正情報によってまだ整合が取られていないため、正確な比率を確定的な結論として扱うべきではない。

チームは所有者不在の名称の一部を登録し、インストールイベントだけを返すビーコンを組み込んだ。最初の Fortune 500 企業の環境では、パッケージが4分以内に実行され、その後も企業から数十件のコールバックを受信した。親プロセスのチェーンからは、Claude、Codex、Hermes などの coding agent がインストールに関与していたことが示された。これはモデルがその場で架空のパッケージ名を生成した事例ではない。その名称はすでに HTTPS で配信される公式ドキュメントに記載されており、エージェントは単に「インストール手順を読む」という処理を `pip`、`npm`、`npx` の実行へ直結させただけだった。

実例は Clerk のドキュメントで確認された。当初掲載されていた、配布元を限定しない `npx clerk-next-fix-auth-protection` は、公共の npm registry に同名パッケージを登録することで横取りできた。悪意のあるバージョンは、インストール時の lifecycle hook を通じて、ユーザー名、ホスト名、作業ディレクトリを外部へ送信した。Clerk は現在、`npx --package @clerk/eslint-plugin ...` に変更し、binary を提供する scoped package を明示している。

エンジニアリング上の要点は、あらゆる外部ドキュメントを信頼できないデータとして扱うことだ。エージェントはインストールを実行する前に namespace、publisher、バージョン、digest を検証し、パッケージマネージャーには allowlist を適用する必要がある。shell、ネットワーク、永続的な書き込みの各権限も、個別に承認すべきだ。sandbox と EDR は依然として有用だが、正規のエージェントが許可された registry から能動的にプログラムをダウンロードする場合、エンドポイント検知では通常の開発フローにしか見えない可能性がある。次に注目すべきは、Pandex がスキャンツールとデータを公開した後、エージェントごとの挙動、権限モード、成功率を独立して再現できるかどうかである。