セキュリティ調査により、Claude、OpenAI Codex、そしてNous ResearchのHermesコーディングエージェントが、企業環境内で未請求のソフトウェアパッケージをインストールしていたことが関連付けられた。この活動は、エージェントを現在どの組織も所有していないパッケージやドメインへ誘導するドキュメントファイルを研究者がテストした際に明らかになった。

この結果が重要なのは、コマンドが通常の開発者向けセットアップ手順のように見え、しかも複数のケースで正規の企業サイトから来ていたためである。研究者によると、概念実証テストのために放棄されたパッケージ名とドメイン名をいくつか登録してから1時間以内に、Fortune 500企業からコールバックを受け取ったという。証拠は広範な侵害を示すものではないが、シェルアクセスを持つAIエージェントが古いドキュメントをソフトウェアサプライチェーンの侵入口に変え得ることを示している。

研究者が見つけたこと

Ars Technica AIによると、イスラエルのステルスセキュリティ企業が、防衛請負企業、Fortune 500企業、および大手テクノロジー企業に関連する6,214のライブドメインをスキャンした。チームは、ウェブサイトがAIシステム向けに機械可読な説明とナビゲーションを提供するために使う新興のllms.txtおよびllms-full.txt規約を使用している8,265ファイルを特定した。

それらのファイルのうち、別々のサイトにある120件が、未登録のパッケージ名または未請求のドメインを1つ以上参照していた。ファイル全体では、スキャン時点で所有されていなかったパッケージのインストールやドメインへのアクセスを行う227件のコマンドが数えられた。多くの参照は、PyPIやnpmを含む一般的なパッケージエコシステムに関するものだった。

リスクを検証するため、研究者は放棄された名前のいくつかを登録し、実行時に自分たちのサーバーへ接続するよう設計したパッケージをホストした。その結果得られたビーコンは、Claude、Codex、Hermesに関連付けられる親プロセスを特定した。研究者はまた、テストパッケージが処理された後、Fortune 500企業やスタートアップを含む数十組織からもコールバックを受け取った。

この調査は、これらの企業がマルウェアに感染していたことを示したわけではない。示したのは、各環境が概念実証コードを実行したか、あるいは研究者のインフラに到達したということである。Ars Technica AIによれば、掲載時点でAnthropic、OpenAI、Nous Researchはいずれもコメント要請に応じていなかった。

ドキュメントの問題が実行リスクになる

この露出は、AIコーディングエージェントがブラウジング、検索、コマンド実行を組み合わせる方法に起因する。エージェントはベンダーのドキュメントを読み、その内容を権威あるものとして扱い、その後ローカルまたは企業環境でセットアップコマンドを実行することがある。参照されたパッケージが未登録であれば、攻撃者は後からその名前を取得し、その名義で悪意あるコードを公開できる。

文書化されたパターンの1つは、存在しないパッケージに対してpip installまたはnpm installの指示を使っていた。別の例では、存在しないテストフレームワークのドメインを参照していた。したがって、このセキュリティ問題は、悪意あるWebサイトや意図的に汚染されたプロンプトに限定されない。ドキュメント作成者が数年前に誤った、古い、あるいは幻覚による依存関係を入力してしまい、その参照が他人に取得可能なまま残っていた可能性がある。

研究者はまた、ClerkのWebサイトに関する事例も説明した。llms.txtファイルに、後に取得され、実際のマルウェア配布に使われたパッケージ名に関連するnpxコマンドが含まれていた。npxはプロジェクトの依存関係マニフェストに追加せずにパッケージのバイナリを取得して実行できるため、このコマンドは実行への非常に直接的な経路を作り出していた。

その後、Clerkはこのドキュメント上の問題を修正した。同社は、関連パッケージ@clerk/eslint-pluginをすでにインストールしていたユーザーは、同社が説明した状況では悪意あるパッケージにさらされていなかったと述べた。Clerkをめぐる混乱が実際の感染を引き起こしたかどうかは依然として不明である。

従来の防御がシグナルを見逃す理由

この調査は、危険な判断が下される地点と、企業のセキュリティツールが通常不正利用を探す地点との間にあるギャップを浮き彫りにしている。既知のパッケージリポジトリに対してpipやnpmを実行するコーディングエージェントは、通常の開発活動に見える可能性がある。エンドポイント検知・対応ツールは、承認されたAIアシスタントが許可されたネットワーク接続を通じて見慣れたパッケージマネージャーを起動しているように見えるかもしれない。

問題は、ドキュメントと依存関係の間の検証されていない関係である。エージェントは、ファイルが公式のHTTPSドメインから来ており、コマンドが標準的なレジストリを使用していることは確認できても、パッケージの所有権、公開者の身元、由来、あるいはその依存関係がプロジェクトで想定されているかどうかを確認できないことがある。そうした確認は、必ずしもエージェントのデフォルトワークフローに含まれていない。

これはプロンプトインジェクションに関連するが、重要な点でより広範である。一般にプロンプトインジェクションは、モデルを操作するために意図的に埋め込まれた指示を指す。しかし研究者が説明したシナリオでは、元の指示は本物で無害である可能性がある。危険は後から、放棄されたパッケージやドメインが攻撃者の利用可能になったときに現れる。

AIビルダーと企業チームにとっての意味

AIエージェントの開発者にとって、この結果は、取得したドキュメントをユーザーのコマンドの延長ではなく、信頼できない入力として扱うべきだという考えを強める。シェルコマンドを実行できるエージェントは、指示の読み取りと実行の承認を分離し、新しい依存関係には確認を求め、インストール前にパッケージの所有権と由来を確認すべきである。サンドボックス化とネットワークアクセスの制限は、これらの確認が失敗した場合の影響を軽減できる。

企業内でコーディングエージェントを展開する製品チームは、より差し迫ったガバナンス上の問題に直面する。つまり、アシスタントが内部リポジトリ、パッケージレジストリ、認証情報、本番に近いシステムへ同時に無制限アクセスを持つべきかという問題である。実用的な展開ポリシーとしては、隔離された環境でのコード生成とテストを許可しつつ、任意のパッケージインストールをブロックするか、承認済みの依存関係リストを要求する方法がある。

セキュリティチームは自社ドメイン上のllms.txtおよびllms-full.txtファイルを監査すべきだが、リスクはこれらの形式に限定されない。エージェントはREADMEファイル、ベンダーのSDKガイド、Issueスレッド、例示、第三者のドキュメントも取り込む。組織は、信頼できるパートナーやコミュニティプロジェクトを含め、取得の全経路にわたって依存関係の検証と由来管理を行う必要がある。

市場への示唆は、投機的というより実務的である。AIコーディングアシスタントには行動する権限がより多く与えられている一方で、ソフトウェアサプライチェーン防御は依然として人間の開発者と従来のビルドシステムを前提に設計されている。エージェントが自動的にツールをインストールする頻度が増えるほど、なぜその依存関係が選ばれたのか、どのソースがそれを承認したのかを記録する重要性が増す。

今後注目すべき点

最初のシグナルは、Anthropic、OpenAI、Nous Researchが、インストールコマンド、未登録パッケージ、取得した指示の扱いに関するエージェントの変更を公表するかどうかである。セキュリティ研究者や企業ユーザーは、放棄名の再利用をフラグ付けするパッケージレジストリの制御や、実行前に由来チェックを追加するエージェントプラットフォームにも注目すべきだ。

第2のシグナルは、企業が機械可読な文書を監査し、修正するかどうかである。研究者のスキャンでは、一部の不備のあるエントリがAI時代より前にさかのぼることが示されており、クリーンアップだけでは問題を解決できない可能性がある。チームは、ドキュメントが最初に公開された時点で依存関係を検証するだけでなく、時間の経過とともにパッケージの所有権を監視する必要がある。

最後に、インシデント対応担当者は、制御されたテスト外で同様のコールバックやパッケージ取得が起きた証拠を探すかもしれない。現在の報道は露出と、ドキュメント参照に関連する少なくとも1件の実マルウェア事例を示しているが、影響を受けた組織全体で確認された感染数を示してはいない。

Creati.aiの見解

この事件は、モデルの正確性だけでなく権限に関する警告である。AIエージェントは、技術的には正しいパッケージレジストリへの要求を行いながら、なお安全でない指示に従っている可能性がある。コマンドが公式ベンダードメインから発している場合、その違いは見落としやすい。

企業にとっての賢明な対応は、コーディングアシスタントをやめることではなく、実行できることを絞り込み、検証可能な依存関係の由来を要求することである。エージェントが参照資料と認可を確実に区別できるようになるまでは、あらゆる自動インストールをセキュリティ上重要な行為として扱うべきだ。