AIエージェント向け「llms.txt」にサプライチェーンリスク　未登録パッケージを正規文書が指示、Fortune 500環境でコード実行を確認

AIエージェント向けにWebサイトの情報を整理する「llms.txt」を巡り、正規の企業ドメインに掲載されたインストール指示が、未登録のパッケージ名や失効したドメインを参照していることで、第三者に乗っ取られる新たなサプライチェーンリスクが報告されました。

セキュリティ研究者Alon Hertz氏は、約1万5,000社を対象に調査し、6,214の稼働ドメインから8,565件のllms.txtを取得。インストールやセットアップ手順として記載されていたパッケージ名、ドメイン、サブドメインのうち、第三者が取得可能な状態だったものを237件超確認したとしています。

Hertz氏は影響確認のため、一部の未登録パッケージ名を取得し、インストールされた事実のみを通知する無害な検証用ビーコンを配置しました。その結果、同氏がFortune 500企業とする環境から4分以内に最初の実行通知が届き、1時間以内に別のFortune 500企業からも通知があったと報告しています。

さらに調査中、認証サービスClerkのAIエージェント向け文書から参照され得る名称と同じnpmパッケージを第三者が先に登録し、インストール時に端末情報を外部送信する悪性コードが配置されていた実例も確認したとしています。Clerkは通知を受けて文書を修正しており、現在の公式ドキュメントでは実行元の正規パッケージを明示する形式へ変更されています。

今回の問題は、llms.txt自体の脆弱性ではありません。AIエージェントが「正規サイトの文書＝信頼できる指示」とみなし、そこに記載された外部パッケージやドメインを追加検証せず利用することで、文書からコード実行までの信頼連鎖が攻撃面になる点が問題です。

llms.txtサプライチェーンリスクのサマリー

• llms.txtは、Webサイトの情報をLLMやAIエージェントが読み取りやすいMarkdown形式で案内するための「新しい慣習・提案」であり、IETFやW3Cの正式標準ではありません。
• Googleは2026年5月、Chrome Lighthouseの「Agentic browsing audits」でllms.txtの監査を追加し、Webサイトのルートなどへの配置方法を公式に案内しています。
• 研究者Alon Hertz氏は、約1万5,000社を調査し、6,214ドメインから8,565件のllms.txtを取得したと報告しています。
• その中で、インストールやセットアップ先として記載されながら、第三者が取得可能だったパッケージ名・ドメイン・サブドメインを237件超確認しました。
• 対象にはPyPI、npm、RubyGems、NuGet、crates.io、Packagistのパッケージ名や、Render、Vercel、Fly、Netlifyなどの未使用・失効サブドメインが含まれるとしています。
• Hertz氏は一部の未登録パッケージ名を取得し、無害な検証用ビーコンを配置しました。
• 同氏によると、Fortune 500企業内とする環境から4分以内に最初の実行通知が届き、1時間以内に別のFortune 500企業からも通知がありました。
• 研究では侵入、永続化、データ窃取は行わず、企業名も修正対応中のため公開していません。
• 5つのフロンティアモデル構成と2種類のエージェントCLIを使った検証では、ベンダー名だけを与えたタスクでも、エージェントが自律的に公式文書を探し、未登録パッケージをインストールするケースが確認されたとしています。
• Clerk関連では、正規ツールのコマンド名と同じ名称を第三者がnpmへ登録し、インストール端末の情報を外部送信する悪性パッケージが実際に存在していました。
• 現在のClerk公式ドキュメントは、@clerk/eslint-pluginを実行元として明示する形式へ修正されています。
• npm公式仕様でも、npxはローカルに対象パッケージがなければリモートのnpmレジストリから取得して実行できる仕組みです。
• この問題はプロンプトインジェクションだけではなく、正規文書に残った「未取得の名前」や「失効した参照先」を攻撃者が取得するサプライチェーン問題です。
• AIエージェント運用では、外部文書を信頼済み命令として扱わず、パッケージ導入・シェル実行・外部通信に技術的な制約と承認を設ける必要があります。

項目	内容
公表時期	2026年8月下旬
研究者	Alon Hertz氏
主な対象	llms.txt、llms-full.txtなどAIエージェントが参照するWeb文書
調査規模	約1万5,000社
取得したllms.txt	8,565件
稼働ドメイン	6,214
未登録・取得可能な参照先	237件超
対象レジストリ	PyPI、npm、RubyGems、NuGet、crates.io、Packagistなど
対象ホスティング等	Render、Vercel、Fly、Netlifyなど
検証内容	未登録名の一部を取得し、無害なインストール通知ビーコンを配置
最初の実行通知	研究者によるとFortune 500企業内とする環境から4分以内
実害	研究実験では永続化・データ窃取なし
実在する悪性事例	Clerk関連名称を悪用したnpmパッケージ
Clerkの対応	文書を修正し、現在は正規パッケージを明示
問題の本質	正規文書から外部パッケージ・ドメインへの信頼連鎖
CVE	特定のCVEを悪用する攻撃ではありません

llms.txtとは　AIエージェント向けにWebサイトを案内するMarkdownファイル

llms.txtは、Webサイトの情報を大規模言語モデルやAIエージェントが利用しやすい形で提示するため、Webサイトのルートなどに配置するMarkdownファイルです。

Jeremy Howard氏が2024年9月に提案し、2026年8月にv2へ更新しています。

仕様では、サイトやプロジェクト名、概要、詳細情報、関連ドキュメントへのリンクなどをMarkdownでまとめます。AIエージェントはWebサイト全体をクロールする代わりに、llms.txtを入口として重要なドキュメントやAPI情報へ移動できます。

Googleも2026年5月、Chrome LighthouseのAgentic browsing auditsにllms.txt監査を追加しました。

Googleの公式説明ではllms.txtを「emerging convention」としており、現時点では配置自体も任意です。

そのため「Webの正式標準」ではありませんが、AIエージェント向けの文書配布方法として採用が広がっています。

なお、llms.txtはOpenAI CodexのAGENTS.mdやAnthropic Claude CodeのCLAUDE.mdのようなリポジトリ内の指示ファイルとは異なります。

今回の研究対象は主にWebサイト側が公開するllms.txtですが、「AIが外部コンテンツを読み、その内容を操作として実行する」という問題は、GitHubリポジトリ、Issue、チケット、メール、開発ドキュメントなどにも共通します。

8,565件のllms.txtを調査、237件超が未登録パッケージやドメインを参照

Hertz氏は、約1万5,000社を対象としてllms.txtの公開状況を調査しました。

その結果、6,214の稼働ドメインから8,565件のllms.txtを取得したとしています。

対象には大手テクノロジー企業、金融関連企業、防衛関連企業、Fortune 500企業などが含まれていました。

研究者が注目したのは、文書内に記載されたインストール指示や外部参照先です。

調査では、PyPI、npm、RubyGems、NuGet、crates.io、Packagistなどで、企業の公式文書に正確な名称が記載されているにもかかわらず、実際には誰も登録していないパッケージ名が確認されました。

また、期限切れドメインや、Render、Vercel、Fly、Netlifyなどで再取得可能なサブドメインも含まれていたとしています。

研究者は、こうした取得可能な参照先を237件超確認しました。

「タイポスクワッティング」ではなく公式文書に正しい名前が書かれている

今回の手法は、一般的なタイポスクワッティングとは性質が異なります。

タイポスクワッティングでは、正規パッケージに似たスペルの名前を攻撃者が登録し、利用者の入力ミスなどを狙います。

一方、今回のケースでは、企業自身の公式文書に記載された名前そのものが未登録でした。

AIエージェントから見ると、

• HTTPSで配信される企業の公式ドメイン
• AI向けに用意されたllms.txt
• 文書内に明示されたインストール方法
• npmやPyPIなど一般的な公式レジストリ

という信頼できそうな要素が連続します。

しかし、その最後に指定されたパッケージ名を正規ベンダーが確保していなければ、第三者がその名前を取得できます。

研究者はこの「文書上の信頼」と「名前空間の所有権」の不一致を問題視しています。

Fortune 500企業内とする環境から4分以内に実行通知

影響を確認するため、Hertz氏は企業文書に記載されていた未登録パッケージ名のうち、ごく一部をPyPIやnpmで取得しました。

登録した検証用パッケージには、インストールされたという事実のみを研究者の環境へ通知する無害なビーコンを入れたとしています。

研究者によると、最初の通知は公開から4分以内にFortune 500企業内とする環境から届きました。

1時間以内には別のFortune 500企業とする環境からも通知があり、その後もスタートアップや企業環境から数十件の通知を確認したとしています。

ただし、企業名は公開されていません。

研究者は責任ある開示を進めているため対象企業名を伏せており、外部から個別企業の影響を独立して確認することはできません。

また、この検証で永続化、資格情報窃取、ファイル取得などは実施していません。

したがって、本件を「Fortune 500企業が実際に攻撃され情報漏えいした」と表現するのは不正確です。

確認されているのは、研究者が用意した無害な検証用パッケージが企業環境内とする場所で実行されたという研究者自身の報告です。

ベンダー名だけのタスクでもAIが自律的に文書を探して実行

研究者は、AIエージェントがどの程度自律的にllms.txtへ到達するかも検証しました。

5種類のフロンティアモデル構成と2種類のエージェントCLIを対象に、それぞれ100回のテストを行ったとしています。

タスクではURLやllms.txtの場所を直接指定せず、ベンダー名を含む開発作業だけを与えました。

その結果、エージェント自身がベンダーの公式情報を探し、llms.txtなどを参照し、そこに記載された未登録パッケージをインストールするケースを確認したと報告しています。

これは典型的な「悪意ある文章をAIへ読ませる間接プロンプトインジェクション」とは異なります。

文書を書いた企業にも、タスクを依頼した利用者にも悪意がなくても、過去に書かれたインストール指示の参照先が後から第三者に取得されるだけで、AIの自律動作が攻撃経路になり得ます。

Clerkの文書から実在する悪性npmパッケージを発見

研究中、Hertz氏は検証用ではない実際の悪性パッケージも確認したと報告しています。

対象となったのは、認証サービスClerkのNext.js向けツールに関連する名称です。

Clerkの正規機能では、clerk-next-fix-auth-protectionというコマンドラインツールが公式パッケージ@clerk/eslint-pluginの中に含まれています。

研究者によると、当時のエージェント向け文書では、このコマンド名を単独でnpxから実行する形で解釈できる記載がありました。

ところが、clerk-next-fix-auth-protectionという名称の独立したnpmパッケージはClerkが公開しておらず、第三者が同名パッケージを登録していました。

研究者は、この第三者パッケージがインストール時にユーザー名、ホスト名、作業ディレクトリ、時刻などを外部へ送信する悪性コードを含んでいたと報告しています。

同氏によると、パッケージはMAL-2026-11069として検出情報に登録されました。

Clerkは修正、現在は正規パッケージを明示

Clerkは研究者から通知を受けた後、問題となる文書を修正しています。

現在のClerk公式アップグレードガイドでは、Bulk Fixer CLIの実行元として@clerk/eslint-pluginを明示しています。

つまり、コマンド名だけを公共npmレジストリで解決させるのではなく、「どの正規パッケージに入っている実行ファイルなのか」を指定する形式です。

npmの公式ドキュメントでも、npxはローカル環境に必要なパッケージが存在しない場合、リモートのnpmレジストリからパッケージを取得して実行できる仕組みとされています。

AIエージェントにパッケージマネージャーを操作させる場合、この自動解決の利便性がそのまま攻撃面になります。

llms.txtそのものに脆弱性があるわけではない

今回の問題を「llms.txtの脆弱性」とだけ捉えると本質を見誤ります。

llms.txtはMarkdown文書であり、それ自体がプログラムを実行する仕組みではありません。

問題は、その文書を読むAIエージェントがシェルやパッケージマネージャーを操作できることです。

人間がREADMEを読んだ場合は、見慣れないパッケージ名を検索したり、発行元を確認したり、インストール前に違和感を覚えたりする可能性があります。

一方、自律実行型エージェントでは、「公式文書に書かれている」という事実を強い信頼シグナルとして扱い、その後のインストールやコマンド実行まで自動化する場合があります。

文書がデータとして読まれるだけでなく、実際の操作へ変換されることで、ドキュメントの完全性や参照先の所有状態がサプライチェーンセキュリティの一部になります。

EDRだけでは検知が難しい理由

研究者は、従来のエンドポイント監視だけでは今回のような活動を識別しにくいと指摘しています。

企業側から見ると、

• 正規のAIコーディングエージェントが親プロセス
• 正規のnpmやPyPIへHTTPS通信
• 企業の公式Webサイトに書かれたインストール指示
• 一般的なパッケージマネージャーによる実行

という通常開発とよく似た活動になります。

そのため、「悪性ドメインへの接続」「不審な実行ファイル」「未知の親プロセス」といった従来型のシグナルだけでは検知できない可能性があります。

対策ではエンドポイント側だけでなく、「AIが参照する情報」と「そこから実行する外部リソース」の信頼関係を検証する必要があります。

llms.txtだけでなくGitHub、Issue、メール、チケットも実行面になる

Hertz氏は、今回の問題がllms.txtだけに限定されないとしています。

AIエージェントが参照する情報には、Web文書のほか、GitHubリポジトリ、Issue、コミュニティフォーラム、メール、チケットシステム、社内Wikiなどがあります。

従来、これらは「人間が読む情報」であり、内容を書き換えられても直接OSコマンドが実行されるわけではありませんでした。

AIエージェントがツール実行権限を持つと、文章の内容がパッケージインストール、API呼び出し、ファイル操作、クラウド変更などへ変換される可能性があります。

セキュリティ対策Labでは、外部Webページの内容によってAIエージェントが誘導される問題を「AIエージェントを狙う間接的プロンプトインジェクション」でも整理しています。

今回のケースは悪意ある命令文そのものを仕込む攻撃とは異なりますが、「外部コンテンツをエージェントの信頼済み命令として扱わない」という対策は共通します。

llms.txtを公開する企業が確認すべき項目

自社でllms.txtやllms-full.txtを公開している場合は、通常のWebコンテンツとは別にセキュリティレビュー対象へ含める必要があります。

特に確認したいのは、パッケージ名と外部URLです。

文書内にnpm、PyPI、RubyGemsなどのインストール方法を掲載している場合、そのパッケージ名が現在も自社または正規ベンダーの管理下にあるかを確認します。

将来利用する予定の名称を文書へ先に書く場合も、公開前にレジストリ側の名前空間を確保しておく必要があります。

独自ドメイン、サブドメイン、クラウドホスティングのURLについても、削除・移行後に第三者が再取得できる状態になっていないか確認します。

また、文書の変更を一般的なコンテンツ更新として扱わず、インストールコマンドや外部参照先の変更についてはコードレビューに近い承認プロセスを設けることも有効です。

情報システム・AI基盤部門への示唆

今回の研究は、AIエージェントに対する「入力」と「実行権限」を別々に管理する必要性を示しています。

第一に、Web文書やGitHub、メール、チケットなど外部から取得する内容は、正規ドメインから取得したものであっても非信頼入力として扱う必要があります。

第二に、パッケージインストールやシェル実行を無条件で自動許可しないことです。新しい依存関係の追加、初めて利用するパッケージ、外部スクリプトの実行などはHuman-in-the-Loopの承認対象にする方法があります。

第三に、AIエージェントのネットワークアクセスを制限します。英国NCSCも、AIエージェントをサンドボックス内で実行し、可能な限り外向き通信をデフォルト拒否にしたうえで、必要な接続先だけを許可するよう推奨しています。

第四に、エージェントへ渡す認証情報を最小化します。開発者の個人用GitHubトークン、クラウド管理者権限、SSH秘密鍵などをそのまま利用できる状態では、悪性パッケージが実行された場合の影響範囲が大きくなります。

第五に、AIエージェントによる操作をユーザー操作と同じように監査します。どの文書を根拠に、どのパッケージを取得し、どのコマンドを実行し、どこへ通信したかを後から追跡できるログが必要です。

第六に、パッケージの「名前」だけでなく発行元を検証します。スコープ付きパッケージ、固定バージョン、内部レジストリ、許可済みパッケージ一覧などを利用し、エージェントが任意の公共レジストリ名を自動解決しない設計が重要です。

NCSCは2026年8月のAIエージェント向けガイダンスで、プロンプトによる禁止指示だけに依存せず、サンドボックス、ネットワーク制御、監視、人間による監督、緊急停止機能を組み合わせるよう求めています。

セキュリティ対策Labでは「英NCSC、AIエージェントのサイバーリスク管理を提言」で実務対策を整理しています。

AIエージェントの普及によって、これまで「参考資料」だったWeb文書やREADMEが実行判断の入力へ変わりつつあります。企業側には、ソフトウェアコードだけでなく、エージェントが信頼して読むコンテンツと、その文書が指す外部リソースまでサプライチェーンとして管理する視点が必要です。

出典

• Data Became Code: We Ran Code Inside Fortune 500s Using Files They Published for AI Agents – Alon Hertz
• The /llms.txt file, v2 – llms-txt / Jeremy Howard
• llms.txt – Lighthouse / Chrome for Developers
• Migrate away from Middleware-based auth checks – Clerk Docs
• npx – npm Docs
• Managing the cyber risk of agentic AI – UK National Cyber Security Centre
• AI Agent Instruction Files Let Attackers Execute Code Inside Fortune 500 Networks – CyberPress
• AIエージェントを狙う間接的プロンプトインジェクション – セキュリティ対策Lab
• 英NCSC、AIエージェントのサイバーリスク管理を提言 – セキュリティ対策Lab