メインコンテンツへスキップ
  1. 記事一覧/

Claude・Codex・Hermesが企業ネットワーク内に不審コードをインストール

·5 分
著者
Alicia
AI・IT・ハードウェアの最新ニュースを自動配信するテックブログです。
目次
サムネイル

AIエージェントが企業ネットワーク内で「誰のものでもないコード」を自動実行
#

AIエージェントが企業の内部ネットワーク内で、所有者不明のコードを自動的にインストールするという深刻なセキュリティインシデントが明らかになった。AnthropicのClaude、OpenAIのCodex、Nous ResearchのHermesといった主要なコーディングエージェントが関与しており、Fortune 500企業を含む数十社が影響を受けたことが確認されている。


何が起きたのか? ── llms.txtという「新しい標準」の落とし穴
#

問題の発端となったのは、llms.txt および llms-full.txt と呼ばれるファイルだ。これらはウェブサイトがAIエージェント向けにサイトの内容や構造を機械可読な形式で提供するための新興の規格であり、検索エンジン向けの robots.txt に相当するものとして普及しつつある。

イスラエルのステルス系スタートアップの研究者チームが、防衛関連企業・Fortune 500・大手テック企業が所有する6,214のドメインをスキャンしたところ、計8,265件のllms.txt/llms-full.txtファイルを発見。そのうち120件(それぞれ異なるサイトに存在)が、登録されていないコードパッケージやドメイン名を参照していることが判明した。

これらのファイルには、PyPIやnpmなど各種パッケージレジストリに存在しないパッケージへのインストール手順が記載されていた。例えば pip install [パッケージ名]npm install [パッケージ名] といった形式の記述だ。パッケージ名が未登録であるため、攻撃者がそのスロットを取得してランサムウェアなど任意の悪意あるコードを仕込める状態になっていた。


実証実験で判明した衝撃の事実
#

研究者たちは未登録の名前を実際にいくつか取得し、アクセスしたマシンが自分たちのサーバーに「コールバック」するような検証用パッケージを配置した。1時間以内に、ある Fortune 500企業からコールバックが届き、その後も複数のFortune 500企業やスタートアップから同様のレスポンスが届いた。

コールバックのログには親プロセスの連鎖も記録されており、Claude・Codex・Hermesといったコーディングエージェントが実際にインストールを実行していたことが確認された。なお、Anthropic・OpenAI・Nous Researchは記事公開時点でコメントの要請に応じていない。


実在する攻撃事例:clerk.comのケース
#

理論上の脅威にとどまらず、実際の攻撃事例も確認されている。研究者たちは正規のウェブサイト clerk.com が提供するLLMファイル内に npx clerk-next-fix-auth-protection というコマンドが含まれているのを発見。npx はnpmのキャッシュにパッケージを取得して実行できるコマンドで、プロジェクトの依存関係リストに記録されない点が特徴的だ。

調査の結果、その空きスロットはすでに何者かに取得され、実際のマルウェアが配置されていたことが判明した。Clerkはその後この問題を解決済みとしており、同社によれば @clerk/eslint-plugin に含まれるバイナリをすでにインストール済みの場合は脅威はなかったとしているが、そうでない場合は悪意あるパッケージがインストールされる状態だったという。実際の感染被害が発生したかどうかは不明だ。


なぜセキュリティ対策が機能しなかったのか?
#

研究者の一人であるAlon Hertz氏は「信頼モデルが壊れている」と指摘する。AIエージェントはベンダーのドキュメントを「正しい情報源」として扱い、内容を疑わない。そして、それを監督する人間も同様だという。

AIエージェントがllms.txtを読む際、そのファイルは以下の要素をすべて満たしているように見える:

  • 企業の公式ドメインからHTTPS経由で配信
  • AI向けに設計された標準フォーマット
  • 企業自身またはその信頼するパートナーが公開

そのため、ファイルが pip install を指示すれば、エージェントはPyPI上でそのパッケージが実際に当該企業のものかどうかを確認しない。また、このトラスト(信頼)チェーンは推移的に機能するため、llms.txtが対象企業のサイトになくても、エージェントが信頼するサードパーティのサイトに置かれていれば同じ問題が発生する。

さらに深刻なのは、エンドポイント検知(EDR)やプロキシがこの挙動に対してアラートを発しなかった点だ。コーディングエージェントが pip install を実行することは、通常の開発作業と区別がつかないからだ。

研究者たちは「エージェントはページとコマンドを区別しない。読んだものすべてが入力であり、すべての入力が潜在的な命令になりうる」と述べている。


まとめ
#

今回の調査で発見された120件の誤設定ファイルには、合計227件の存在しないパッケージへのインストール命令や未登録ドメインへの参照が含まれていた。これらの誤った記述がどのように生まれたかは不明だが、研究者の見解によれば、多くはAI時代以前から人間が手動で作成したものであり、一部はAIが幻覚(ハルシネーション)を起こして生成したか、あるいはAIエージェント自身が正規と非正規の指示を区別できなかった結果とみられている。

筆者の見解: データと実行コードの境界が消失しつつある現在、llms.txtのような「AIへの指示ファイル」の管理責任を誰が担うのか、そしてAIエージェントにどこまでの実行権限を与えるべきかという問いは、企業のセキュリティポリシーにとって避けて通れない課題となるだろう。


出典: Claude, Codex, and Hermes installed unowned code inside corporate networks

関連記事