9月1日、php-net.proが「Fake Packages Named in Official AI-Agent Files Ran Inside Fortune 500 Firms Within Minutes」と題した記事を公開した。AIエージェント向け指示ファイル「llms.txt」に仕込まれた未登録パッケージ名を悪用したサプライチェーン攻撃が、Fortune 500企業の内部で4分以内に実際に実行されていた——この衝撃的な実証結果は、「データがコードになった」時代における新たな攻撃面を鮮明に示している。
4分以内にFortune 500が踏んだ：研究チームが仕掛けた実験
セキュリティ研究者のAlon Hertzらのチームは、約1万5,000社（Fortune 500、テック企業、フィンテック、防衛関連企業を含む）からカタログ化された6,214ドメインにわたる8,565件のllms.txtファイルをスキャンした。
その結果、PyPI、npm、RubyGems、NuGet、crates.io、Packagistにまたがる237件超のパッケージ名・ドメイン・サブドメインが参照されていたにもかかわらず、実際には誰にも登録されていないことが判明した。失効した.devや.ioドメイン、放棄されたRender・Vercel・Fly・Netlifyのサブドメインも含まれていた。
研究チームはこれらの未登録名のうち数件を自分たちで登録し、無害な「電話帰宅ビーコン（phone-home beacon）」を仕込んだ。ビーコンを選んだのは、実際に悪意あるコードを使わずに「エージェントが自律的にパッケージをインストールする」事実のみを証明するための、倫理的な実証実験上の判断だ。すると最初のインストールコールバックがFortune 500企業の内部から4分以内に届き、1時間以内にもう1件、その後も大小さまざまな企業から数十件が続いた。
さらに、5種類のフロンティアモデル構成と2種類のエージェントCLIを使った別の検証では、ベンダー名だけを含む1行のプロンプト（URLなし、llms.txtへの言及なし）を100回実行したところ、エージェントは自律的にllms.txtを探し出し、偽パッケージをインストールしたという。
llms.txtとは何か
llms.txtは、ウェブサイトがrobots.txtと並べて公開する比較的新しい形式のファイルで、AIコーディングエージェントに対して「どのドキュメントを読むべきか」「どのAPIを呼び出すべきか」「どのパッケージをインストールすべきか」を指示するものだ。この仕様はJeremy Howard氏が2024年に提案したもので、以降急速に普及が進んでいる。GoogleのChrome DevToolsに組み込まれたLighthouseが「Agentic browsing」監査カテゴリとしてこのファイルをチェックする機能を持つとされており（※元記事ベースの情報。正式実装状況は公式ドキュメントを要確認）、採用するサイトが増加している。
AIエージェントが自律的にコードを書き、パッケージをインストールする時代において、このファイルは事実上「エージェントへの命令書」として機能する。その命令書に偽のパッケージ名が混入していた場合、何が起きるか——それを実証したのが今回の研究だ。
llms.txtを悪用したこの攻撃手法は、プロンプトインジェクションや従来のソフトウェアサプライチェーン攻撃と文脈を共有している。プロンプトインジェクションがモデルへの入力を汚染するのに対し、今回の手法は「エージェントが信頼する公式ドキュメント」そのものを攻撃面として利用する点が新しい。また、依存パッケージの名前空間を乗っ取るタイポスクワッティング攻撃とも類似するが、llms.txtを経由することでエージェントが能動的に誤ったパッケージを引きにいくという点で、攻撃の自動化度合いが一段高い。
実在する攻撃：MAL-2026-11069
実験にとどまらず、研究中に実際の攻撃がすでに野放しになっていたことも発覚した。
認証ベンダーのClerkが公開しているNext.js向けllms.txtには、以下のコマンドが記載されていた。
npx clerk-next-fix-auth-protection
このバイナリは本来、Clerkの正規パッケージ@clerk/eslint-pluginに同梱されている前提だ。しかし、そのパッケージがローカルにインストールされていない状態で上記コマンドが実行されると、npxは公開npmレジストリに名前解決しに行く。そこにはすでに無関係の第三者が同名パッケージを登録済みだった。
この不正パッケージは実際の機能を持たず、インストールのたびにインストーラーのユーザー名、マシン名、作業ディレクトリ、タイムスタンプを外部へ送信する。Google OSV.devおよびAmazon InspectorがこれをCWE-506としてMAL-2026-11069に分類・フラグ付けしている。Clerkのセキュリティチームへの通知後、問題は迅速に修正された。不正パッケージはClerkではなく外部の第三者が作成したものだ。
なぜ検出が難しいのか
研究チームが強調するのは、エンドポイント検出ツールがこの攻撃パターンをほぼ見逃す点だ。AIコーディングエージェントが意図的に導入されている環境では、pip installやnpm installのトラフィックは正常な業務として扱われる。
より本質的な問題として研究チームは「データがコードになった」と表現している。人間向けに書かれたドキュメント、フォーラムの投稿、チケットが今やAIエージェントに読まれ、実行される。受動的なコンテンツと実行可能なコードの境界が消えつつあるが、コードが本来持っているはずの完全性チェックはそこには存在しない。
この問題はllms.txtに限らない。AIエージェントが参照するあらゆる「信頼できるドキュメント」が潜在的な攻撃面となりうる。パッケージ名の登録状況を定期的に確認し、llms.txtに記載する名称は正規に登録済みのものに限定するという運用上の対策が、当面の現実的な防御策となるだろう。
詳細はFake Packages Named in Official AI-Agent Files Ran Inside Fortune 500 Firms Within Minutesを参照していただきたい。
