AnthropicとGoogleのセキュリティギャップ：AIエージェントが信頼されたドキュメントから管理者不明のコードへ到達

研究者らが、コーディングエージェントが信頼された企業ドキュメントで参照されたパッケージを実行したと報告したことで、AnthropicとGoogleは現在、セキュリティを巡る論争の中心にいる。テスト用パッケージの1つは、Fortune 500企業の環境内で4分以内に実行されたとされる。研究者らによれば、その後のプロセス記録にはClaude、OpenAI Codex、Nous ResearchのHermesが現れた。

この発見は、Anthropic、Google、またはOpenAIが意図的にマルウェアを配布したことを示すものではない。実験のために登録されたパッケージの大半には、実行時のみ報告する無害なビーコンが含まれていた。より深刻な発見は、認証プロバイダーClerkのウェブサイトでかつて公開されていた指示に関連する、別の悪意あるnpmパッケージとされるものだった。

この区別は重要だ。初期報道では、3つのAIベンダーが企業ネットワークを侵害したかのように受け取られる可能性がある。だが、証拠が示すのはソフトウェアサプライチェーンの失敗だ。エージェントは公式らしい指示を信頼し、公開パッケージレジストリへ到達し、誰にも確保されていない名前を実行した。

GoogleがこのAnthropicとGoogleのセキュリティ問題に関わるのは、ウェブサイト監査ソフトウェアLighthouseでllms.txtファイルのチェックを支援しているためだ。ClaudeとCodexは、インストール手順に従ったとされるエージェントを通じて関わる。共通する問題は、特定のモデルや企業ではない。ドキュメントと実行可能なアクションの境界が崩れつつあることだ。

以前、その境界は明確に感じられた。開発者はセットアップガイドを読み、パッケージを確認し、インストールするかどうかを判断できた。自律型コーディングエージェントは、しばしば開発者が持つ既存の権限を使い、その手順を1回の操作に圧縮できる。

その結果、コーディングエージェントを導入するすべての組織にとって、新たなセキュリティ上の問いが生じる。ソフトウェアがドキュメントを読むとき、そのドキュメントが今なお信頼できる対象を指していることを誰が検証するのか。

企業のAIエージェントが誰にも所有されていない名前を実行

研究者らは、古いドキュメントを用い、信頼されたテキストが実行への入口になり得ることを実証した。

セキュリティ研究者のAlon Hertz氏らは、稼働中の6,214ドメインにまたがる機械可読ドキュメントを調査した。サンプルには、防衛関連請負業者、大手テクノロジー企業、Fortune 500企業が含まれていた。

研究者らは、8,265件のllms.txtおよびllms-full.txtファイルを見つけたと報告している。llms.txtファイルは、言語モデルとAIエージェント向けにウェブサイトのコンテンツを整理する新しい慣行だ。より大きな関連ファイルでは、より広範なドキュメントを単一の機械可読ファイルとして提供できる。

収集されたファイルのうち、120のウェブサイトが少なくとも1つの未登録パッケージまたは未取得ドメインを参照していたとされる。チームは、存在しないパッケージまたは宛先に関わるコマンドを227件数えた。

これらは必ずしも敵対的な指示ではなかった。中には、これまで一度も登録されていないパッケージ名を指す通常のインストールコマンドと見られるものもあった。ほかには、期限切れのドメインや、もはや所有権が主張されていないサービスを参照するものもあった。

pip install package-nameのような行は、そのパッケージ名がPyPIで利用可能な場合に危険になる。同じ原則は、npm、RubyGems、NuGet、crates.io、Packagist、あるいは放棄されたホスティング用サブドメインにも当てはまる。

研究者らは、利用可能だった名前の一部を登録した。その後、実行時に自分たちのサーバーへ接続するよう設計したコードを含むパッケージを公開した。Hertz氏の研究報告によれば、最初のコールバックは4分以内にFortune 500企業の環境から届いたという。

さらに2つのシステムが、最初の1時間以内にそのコードを実行したとされる。時間の経過とともに、チームはスタートアップ企業や大企業から数十件のコールバックを受け取った。

コールバックには、プロセス起動に関わったプログラムを特定する親プロセスチェーンが記録されていた。研究者らによると、これらの記録は、一部のインストールをClaude、OpenAI Codex、Nous ResearchのHermesと結び付けた。

この実験では、それらのモデルを侵害する必要はなかった。また、新たに発見されたソフトウェア脆弱性、フィッシングメッセージ、あるいは盗まれた従業員のパスワードにも依存していない。エージェントは正規のウェブサイトで公開された指示を見つけ、その環境で利用可能なアクセス権限で従ったとされる。

ここに本質的な逆転がある。企業ドキュメントは通常、開発者に承認済みのソフトウェア設定方法を示すことでセキュリティを強化する。しかし今回、そのドキュメントに残された放棄済みの参照が、承認済みコマンドが何を実行するかを第三者が定義できる機会を生んだ。

この発見には慎重な表現も必要だ。研究者らは影響を受けた企業を公表しておらず、すべてのパッケージ名を公開したわけでも、外部者が各企業への帰属を再現できるほど十分なテレメトリーを提供したわけでもない。Anthropic、OpenAI、Nous Researchは、元の記事が公開される前にコメントしなかった。

こうした制約があっても、この実験は信頼できるメカニズムを実証している。公開パッケージレジストリでは、その名前を管理する者が意味を決める。公式ドキュメントは、本来意図された意味が失われた後も、その名前を残し続けることがある。

AnthropicとGoogleの信頼チェーンが失敗した理由

エージェントは信頼モデルを無視したのではない。自律型ソフトウェアの動作に合わなくなった信頼モデルに従った。

従来のドキュメントは、指示と実行の間に人間の読者がいることを前提としている。その読者は、不自然なパッケージ名に気付き、発行者を調べ、なぜセットアップコマンドに対応するリポジトリがないのかを問うことができる。

エージェントも同じ確認を行えるが、それは指示と環境によって求められている場合に限られる。そうでなければ、エージェントは要求されたタスクの完了を最適化する。公式ドキュメントを見つけてそのインストールコマンドを実行することは、最短の有効な経路に見える場合がある。

AnthropicとGoogleのつながりは、それぞれ合理的な判断がいかにして1つのリスクの高い連鎖を作り得るかを浮き彫りにする。ウェブサイトは機械可読なガイダンスを公開する。GoogleのLighthouseツールは、そのガイダンスを開発者が見つけられるよう促す。コーディングエージェントは権威あるコンテキストを検索する。パッケージマネージャーは依存関係を簡単に取得・実行できるようにする。

これらのコンポーネント自体に悪意がある必要はない。危険は、エージェントが連鎖全体を認証済みのものとして扱うときに現れる。

GoogleのLighthouseガイダンスは、llms.txtの可用性と形式に関する監査を説明している。Lighthouseは、ファイル内で指定されたすべてのコマンドや依存関係を認証するものではない。したがって、形式監査に合格しても、パッケージの所有権、発行者の身元、コードの安全性については何も保証されない。

同様に、HTTPSは、ファイルがブラウザ接続に表示されたドメインから送られたことを証明する。だが、その中で参照されるすべてのパッケージが今もそのドメインの運営者に属していることまでは証明しない。

公開レジストリは、攻撃者が管理するアカウントから、正しくつづられたパッケージを提供することもある。これは、攻撃者が人気パッケージに似たスペルミスを登録する古典的なタイポスクワッティングとは異なる。この実験で使われた名前は、公式ドキュメントから直接コピーされたとされる。

そのため、これらの指示はエージェントにとっても人間にとっても、より説得力を持つ。端末の記録を確認する開発者には、公式ドメイン、使い慣れたパッケージマネージャー、もっともらしい依存関係名が見えるかもしれない。目に見えるすべてのシグナルが通常どおりに見える可能性がある。

エージェントの検索行動が問題をさらに深刻化させる。ユーザーは、統合作業を依頼する際にベンダー名しか挙げないかもしれない。エージェントはそのベンダーのドキュメントを見つけ、llms.txtを発見し、インストールコマンドを選び、ユーザーから不審なリンクを受け取ることなくパッケージマネージャーを起動できる。

これが、この事案がプロンプトインジェクションより広い問題である理由だ。プロンプトインジェクションは通常、エージェントを誘導し直そうとする敵対的コンテンツを伴う。今回、指示自体は無害で、歴史的にも正当なものだった可能性がある。セキュリティ上の失敗は、参照先の所有権が後に変わった場合、あるいはそもそも存在しなかった場合に起きる。

新たに生まれつつあるllms.txtの慣行も、確立されたセキュリティアーキテクチャを持つ正式なウェブ標準と同等ではない。その有用性は、モデルに簡潔で構造化されたコンテキストを与えることにある。その利便性は同時に、エージェントが信頼するよう促される場所に運用上の指示を集中させる可能性がある。

したがって、AnthropicとGoogleのセキュリティギャップはプロベナンスの問題だ。プロベナンスとは、アーティファクトがどこから来たのか、誰がそれを管理しているのかを示す証拠を意味する。エージェントはドキュメントの所在を検証したが、コマンドの背後にある実行可能な依存関係のプロベナンスは、明らかに確立していなかった。

真の敵はプロベナンスを伴わない自律性

決定的な対立はClaude対Codexではない。自律的な実行対、検証済みのソフトウェア所有権だ。

Claude、Codex、Hermesは、異なるモデル、インターフェース、権限システムを採用している。この事象を単純なツール間比較として扱えば、報告されたインストールの背後にある共通の運用条件を見落とすことになる。

各コーディングエージェントは、プロジェクトのコンテキストを読み、ドキュメントを参照し、ファイルを編集し、開発ツールを呼び出せる。こうした能力がエージェントを有用にするのは、調査と実行の間にある手作業の移行をなくすためだ。

一方で、セキュリティ上の判断もエージェントのワークフローへ移す。依存関係が本物か、そのバージョンが許容できるか、インストールスクリプトを実行すべきかを誰かが判断しなければならない。

パッケージマネージャーは、インストール中にコードを実行することがある。npmパッケージはライフサイクルスクリプトを定義でき、Pythonパッケージもビルドプロセスを通じてインストール関連の動作を実行できる。正確な挙動は異なるものの、インストールは不活性なテキストのダウンロードと同義ではない。

Clerkの事例は、その重要性を示している。研究者らは、Clerkの正規ウェブサイト上の指示ファイルがnpx clerk-next-fix-auth-protectionを参照していることを発見した。npxユーティリティは、パッケージをプロジェクトのマニフェストに恒久的に追加することなく、ダウンロードして公開されたコマンドを実行できる。

セキュリティ調査によると、何者かがそのパッケージ名を取得し、実際のマルウェアを配布するために利用していた。Clerkは後にドキュメントを修正した。

そのパッケージがAIエージェントを通じて感染を引き起こしたかどうかは、依然として不明だ。報道はまた、Clerkの正規ESLintプラグインに含まれる既存のバイナリは安全だったと指摘している。その正規バイナリが存在しないマシンでは、代わりに攻撃者管理下のパッケージが取得される可能性がある。

この違いは、急いで確認するレビュー担当者が見落とすほど微妙だ。どちらの経路も実在するベンダーが公開したコマンドから始まる。どちらもnpmのインフラを使う。危険な経路かどうかは、期待されるバイナリがすでにローカルに存在するかに左右される。

これが企業が直面する実務上のトレードオフだ。エージェントは、依存関係を解決し、テストを実行し、すべてのコマンドのたびに承認を待たずに失敗を修正できるほど、より大きな価値を提供する。同じ権限により、誤った信頼判断がコード実行へと転じる。

モデル提供者は、サンドボックス化と承認フローによってこのリスクを減らせる。企業側は依然として、これらの制御を設定し、ネットワークポリシーを維持し、エージェントが到達できるパッケージソースを決める必要がある。

ソフトウェアベンダーも、問題の別の一端を担っている。そのドキュメントは、静的なマーケティングコンテンツではなく、運用資産になっている。パッケージ参照、サンプルドメイン、コピーされたコマンド、アーカイブ済みのセットアップページは、いまや実行可能コードと同じライフサイクル管理を必要としている。

レジストリ運営者も結果に影響を与える。名前空間の予約、発行者の検証、不審なパッケージのスキャン、所有履歴はいずれも役立つ。ただしレジストリは、未取得の名前が第三者のドキュメントに記載されていることを常に把握できるとは限らない。

この責任分担を踏まえると、単純な責任追及は有益ではない。Anthropic Googleの事例が重要なのは、製品の境界をまたいでいるためだ。検索やドキュメントツールは手順を見つけやすくし、AIエージェントはそれを解釈し、レジストリは指定された成果物を提供できる。

参加者全員が、所有権の検証は別の参加者が行ったはずだと考えたとき、セキュリティは破綻する。

既存のエージェント保護策でもリスクは消えない

ClaudeとCodexはすでに有意義な制御機能を提供しているが、それらは組織が制限的な境界を維持している場合にのみ機能する。

AnthropicのClaudeセキュリティガイダンスでは、プロンプトインジェクションを、アシスタントの指示を操作しようとする敵対的なテキストとして説明している。また、任意のWebコンテンツを取得するコマンドに対する権限制御と制限も文書化している。

Claude Codeはサンドボックスを使用して、ファイルシステムとネットワークへのアクセスを制限できる。子プロセスはこれらのオペレーティングシステム上の制限を継承するため、許可されたコマンドがより制限の緩いプロセスへ密かに抜け出すことを防ぐ助けになる。

OpenAIも同様の多層的アプローチを説明している。Codexの安全性モデルは、サンドボックスの境界、承認ポリシー、管理されたネットワークアクセス、ルール、エージェント対応テレメトリーを組み合わせる。

OpenAIによれば、その管理されたデプロイメントではCodexに無制限のアウトバウンドアクセスを与えていない。想定される接続先は許可でき、未知のドメインには承認を求められるほか、セキュリティチームはプロンプト、ツール呼び出し、承認、ネットワーク上の判断を対象とするログをエクスポートできる。

こうした保護策は重要だが、研究者の発見を自動的に無効化するものではない。組織はエージェントをより広いアクセス権で構成できる。開発者はコマンドを承認できる。ローカル環境では、実行ユーザーの権限とネットワーク接続性がそのまま継承される可能性がある。

パッケージレジストリも、多くの開発環境では想定された接続先である。npmやPyPIへのアクセスをすべて遮断すれば、通常のビルド、依存関係の更新、テスト環境のセットアップが妨げられる。これらのドメインを許可すると、悪意あるインストールを見分けるための明白なネットワーク上のシグナルが一つ失われる。

エンドポイント検知・対応ソフトウェアも同様の課題に直面する。コーディングエージェントが標準的なパッケージマネージャーを起動し、それが暗号化された接続を介して広く知られたレジストリに接続する。ダウンロードされたパッケージが明確に敵対的な動作を行うまで、そのプロセスは通常の開発者活動に見える可能性がある。

研究用のビーコンは意図的に最小限のものだった。報道によれば、サーバーに接続して実行コンテキストを記録したという。実際の攻撃者は、認証情報の窃取、環境の探索、永続化、ソースコードの改変を試みる可能性がある。

ただし、公表された証拠は実験用パッケージがこれらの行為を実行したことを示していない。また、数十社が本番環境の侵害を受けたことも立証していない。実行されたのは概念実証コードであり、深刻ではあるものの、確認済みの侵害より範囲は限定的だ。

この慎重な区別は、企業の対応方針を形作るべきだ。チームは、Claude、Codex、Hermesを使うたびに感染が生じると考えるべきではない。この経路が機能するために必要な条件を特定すべきである。

エージェントには、関連するドキュメントへアクセスできる必要がある。パッケージマネージャーを呼び出す権限も必要だ。環境はレジストリからの取得を許可していなければならない。パッケージは意味のあるコードを実行し、既存の制御策はその挙動を封じ込められない必要がある。

これらの条件のいずれか一つを取り除けば、連鎖を断ち切れる。ネットワークアクセスを制限するのは一つの選択肢だ。依存関係のインストールに人による承認を必須とすることも別の方法である。使い捨てコンテナ内でエージェントを実行すれば、パッケージが実行された場合の影響を抑えられる。

組織は内部の依存関係プロキシも強制できる。プロキシは承認済みのパッケージとバージョンを許可しつつ、未知の名前空間を拒否できる。この手法により、信頼に関する判断を、公開ドキュメントを読むエージェントから切り離せる。

承認プロンプトだけでは、見慣れたコマンドしか表示しない場合、信頼性が低い。レビュー担当者には、パッケージの所有権、公開からの期間、発行者の身元、ダウンロード履歴、その依存関係が承認済みのソフトウェア部品表に記載されているかどうかといった文脈が必要だ。

教訓は、保護策が無用だということではない。明白に悪意あるコマンドを前提に設計された制御では、正当なコマンドが信頼できない所有者に解決されるケースを見逃し得る、ということだ。

ドキュメントはいまやソフトウェアサプライチェーンの一部である

企業は、ドキュメント内の実行可能な参照をすべて、期限切れ、変質、または所有者変更が起こり得る依存関係として扱わなければならない。

当面の対応は、インベントリ作成から始まる。組織は、llms.txt、llms-full.txt、開発者ポータル、アーカイブ済みガイド、コード例、サポート記事、生成されたAPIリファレンスについて、インストールコマンドを検索すべきだ。

参照される各パッケージ、ドメイン、リポジトリ、コンテナイメージ、ホスト型サブドメインには所有者が必要である。誰も認識していない名前を、調査中だからといって公開状態のままにしてはならない。

チームは、公開パッケージ名が組織の実際のレジストリアカウントと一致していることを検証すべきである。また、古いドキュメントでグローバルなスコープなしの名前が使われている場合、スコープ付きパッケージが利用可能かも確認すべきだ。

ドキュメントのパイプラインには自動テストが必要である。ビルド時に、すべてのパッケージが存在し、承認済みの発行者に属し、想定されるリポジトリに解決され、所有者が変更されていないことを検証できる。

リンクチェックだけでは不十分だ。悪意あるパッケージや奪回されたドメインでも、成功レスポンスを返すことがある。パイプラインは可用性ではなく、アイデンティティを検証しなければならない。

企業はドキュメントを公開する前に名前を予約すべきだ。これは重要な製品の周辺で防御的にドメインを登録する行為に似ているが、パッケージ名前空間には継続的な保守が必要となる。

同じ原則はプロジェクトを終了する際にも当てはまる。パッケージを削除してもインストール手順を削除しなければ、所有権の空白が生まれる。ホスティング用サブドメインを放棄したままそこへのリンクを残せば、別の当事者が信頼された経路を引き継ぐ可能性がある。

AI生成ドキュメントには追加の精査が必要だが、人間が書いたページも例外ではない。研究者は、一部の問題のある参照が現在のエージェント時代より前から存在した証拠を見つけた。それらのページをllms-full.txtへコピーしたことで、古い誤りが自律型ソフトウェアに取り込まれやすくなった。

エージェントを導入する企業には、補完的なコントロールプレーンが必要である。エージェントセッションは、開発者の無制限のアカウントではなく、専用のIDで実行すべきだ。認証情報は、現在のリポジトリとタスクに限定すべきである。

パッケージのインストールは、シークレットへのアクセスが制限された隔離環境内で行うべきだ。依存関係がインストール中にネットワークアクセスを必要とするなら、そのアクセスは明示的に許可され、ログに記録される必要がある。

チームは、オペレーティングシステムのテレメトリーとともに、エージェントの推論コンテキストを保存すべきだ。プロセスログはnpmが起動したことを示せるが、エージェント固有の記録は、どのドキュメントがパッケージ名を提供したかを示せる。

この文脈はインシデント対応時に重要になる。調査担当者は、承認済みのプロジェクト依存関係と、エージェントが外部の手順を閲覧した後に選択したパッケージを区別する必要がある。

依存関係の許可リストはリスクを低減できるが、新しいパッケージのための例外経路が必要になる。その例外では来歴を示す証拠を収集し、名前が明示された人間の所有者を求めるべきだ。

組織は、エージェントが参照する情報源の検索可能な記録も維持すべきである。これには、ドキュメントのスナップショット、パッケージメタデータ、承認判断、生成されたコード変更が含まれ得る。管理された技術ナレッジベースは、レビュー担当者がエージェントによる依存関係選択の理由を再構築する助けになる。

より広い教訓はllms.txtにとどまらない。コーディングエージェントは、Issueの説明、リポジトリファイル、検索結果、パッケージドキュメント、Model Context Protocolの応答、生成された社内ガイドを取り込む。

これらの情報源はいずれも指示を含み得る。エージェントにツールがあれば、その指示は行動になり得る。

つまり、ドキュメントの完全性はソフトウェアサプライチェーンセキュリティの一部である。企業は、機械可読な手順を管理外に置いたまま、ソースリポジトリとビルドサーバーだけを保護することはできない。

業界が学んだかどうかを示す三つのシグナル

次の段階は、ドキュメント、エージェント権限、レジストリのアイデンティティがともに改善されるかどうかにかかっている。

第一のシグナルは、影響を受けた120のWebサイトにおける情報開示と是正だ。Hertzのチームは、影響を受けた組織と関連するセキュリティチームに連絡したとしているが、公的な記録では大半のドメインが特定されていない。

企業がllms.txtファイルを監査し、パッケージ名を予約し、インシデント通知を公開するかを注視すべきだ。協調的なクリーンアップが実施されれば、業界が機械可読なドキュメントをセキュリティ上重要なインフラとして認識しているという主張を強めることになる。

沈黙は、修正が行われなかったことの証明にはならない。とりわけ研究者が無害なコードを使用し、確認済みのデータ窃取が見つからなかった場合、多くの組織は公表せずに露出した参照を修正する。

第二のシグナルは、エージェントベンダーによる製品レベルの来歴チェックである。Claude、Codex、Hermesはすでにコマンド実行前に承認を求められるが、インターフェースがそのコマンドの背後にある依存関係を説明すれば、承認はより有用になる。

有意義な変更であれば、パッケージが新規である、未検証である、ベンダーの既知の発行者アカウントと無関係である、またはプロジェクトの既存依存関係グラフに存在しないといった警告を出すだろう。より強力なシステムなら、公開ドキュメントが認識されていないパッケージを指している場合に、明示的な承認を必須にできる。

このような機能は、実行前の判断点に対応するため、Anthropic Googleのセキュリティ対応を強化する。シェルコマンドに関する別の一般的な警告では、保護効果は小さい。

第三のシグナルは、レジストリと企業ポリシーの統合である。パッケージマネージャーと内部プロキシは、発行者履歴、名前空間の経過年数、署名状況、所有権の変更を公開できる。エージェントプラットフォームは、依存関係を選択またはインストールする前に、そのメタデータを利用できる。

企業ポリシーでは、確立されたパッケージを自動的に許可する一方で、未知のパッケージをレビューのため隔離できる。また、公式ドキュメントに名前が記載されていても、発行者との検証可能な関係がないパッケージを拒否することもできる。

信頼できる来歴チェックが複数のエージェントにまたがって攻撃経路を阻止すれば、このシグナルは研究者のより広い警告を弱めることになる。利用可能なアイデンティティデータがあるにもかかわらず、エージェントが新たに取得された名前をインストールし続けるなら、その警告は強まる。

現在の証拠は、慎重な結論を支持している。研究者は実際の企業環境でコード実行を実証し、一部の活動を著名なコーディングエージェントと結び付けたと報じられている。しかし、モデルベンダーが意図的にマルウェアをインストールしたことも、報告されたすべてのコールバックが重大な侵害を示したことも実証していない。

より重要な発見は構造的なものだ。信頼されたドキュメント、自律的な実行、公開レジストリはいまや、多くのセキュリティプログラムがインベントリ化していないサプライチェーンを形成している。

開発者と企業の購買担当者は、エージェントの権限を拡大する前に直接的な質問をすべきだ。エージェントは公開パッケージレジストリにアクセスできるか。発行者の身元を検証するか。インストールコマンドは隔離されているか。セキュリティチームは、どのドキュメントがアクションを引き起こしたのかを再構築できるか。

Anthropic と Google のセキュリティ上の隔たりは、モデルの振る舞いを改善するだけでは埋まりません。ドキュメントの管理者、レジストリ、エージェントのベンダー、企業管理者が、それぞれ異なる連鎖の一端を握っています。

コーディングエージェントにより広い自律性を与える前に、認識されていない依存関係を使って、その連鎖全体をテストしてください。出所を提示せずにエージェントがそれをインストールするなら、その環境はドキュメントを証拠ではなく権威として扱っています。