コーディングエージェントがAPI呼び出しについて常に最新情報を把握できるよう支援する新サービスは、大規模なサプライチェーンの脆弱性を見に呼び込むものになるかもしれません。

2週間前、AI起業家でありスタンフォードの非常勤講師でもあるアンドリュー・ン（Andrew Ng）氏が、コーディングエージェントにAPIドキュメントを提供するためのサービス「Context Hub」を立ち上げました。

「コーディングエージェントはしばしば古いAPIを使い、パラメータをでっち上げます」とン氏はLinkedInの投稿で書きました。「たとえば、Claude CodeにOpenAIのGPT-5.2を呼び出させると、新しいresponses APIではなく、古いchat completions APIを使ってしまいます。新しい方は1年も前から提供されているのにです。Context Hubがこれを解決します。」

たしかに、その可能性はあります。しかし同時に、このサービスはソフトウェアのサプライチェーン攻撃を簡単にすることで、コーディングエージェントをだます方法も提供しているようです。ドキュメントのポータルは、悪意のある指示でAIエージェントを汚染（ポイズニング）するために悪用できます。

lap.shという別のキュレーションサービスを作ったミッキー・シュムエリ（Mickey Shmueli）氏は、そのリスクを示す概念実証（PoC）攻撃を公開しています。 

返却形式: {"translated": "翻訳されたHTML"}

「Context Hubは、MCPサーバーを介してAIエージェントにドキュメントを提供します」こうShmueliは、説明的なブログ記事で書いた。「貢献者はGitHubのプルリクエストとしてドキュメントを提出し、メンテナーがそれをマージし、そしてエージェントは必要に応じてそのコンテンツを取得します。このパイプラインには、あらゆる段階でコンテンツのサニタイズ（無害化）がゼロです。」

開発者コミュニティでは以前から、AIモデルが時々パッケージ名を幻覚（ハルシネーション）することがあると知られており、この欠点は、セキュリティの専門家が示したように、作り出したパッケージ名の下に悪意のあるコードをアップロードすることで悪用できてしまいます。

ShmueliのPoCは、ドキュメント内で「偽の依存関係」を提示することで、幻覚のステップ自体を省いてしまいます。するとコーディングエージェントが、その偽の依存関係を取り込んで、設定ファイル（例：requirements.txt）や生成コードに反映してしまうのです。

攻撃者は単にプルリクエストを作成するだけです――リポジトリに対して送信される変更で、採用されれば汚染は完了します。現状、その可能性はかなり高いように見えます。閉じられた97件のPRのうち、58件がマージされました。

• 年齢確認がLinuxに忍び込む――systemdがDOBフィールドを持つ
• HPの“壁の耳”的なAIが、対面の会議を録音して後で要約できる
• Meta、AIへの支出へ切り替える中で約700人分の雇用を削減
• Google、ダークウェブにGeminiのAIエージェントを放つ

Shmueliは電子メールでThe Registerに対し、「レビューのプロセスは、安全性の確認よりもドキュメント量を優先しているように見えます。DocのPRは素早くマージされますが、中にはコアチームのメンバー自身によるものもあります。提出されたドキュメント内の実行可能な命令やパッケージ参照に対する自動スキャンがGitHubリポジトリで行われているという証拠は見つけられませんでした。ただし、内部で何が起きているのかについては確実には言えません」と述べた。

さらに、公開されている記録から「セキュリティへの貢献」が関与されていないことが示されていたため、Content Hubがどのように反応するかを確かめる目的でPRを出さなかったとも語った。そして、いくつかの未解決のissueと、プル リクエストのsecurity concerns（セキュリティ上の懸念）に関するものを挙げ、証拠だとした。

Ngは、コメント依頼に対してすぐには返答しなかった。

Shmueliは投稿の中で、「エージェントは[Context Hub]からドキュメントを取得し、汚染されたコンテンツを読み取り、プロジェクトを組み立てます」と述べた。「応答は完全に通常に見えます。動くコードです。きれいな指示です。警告はありません。」

これらのどれも、特に驚くことではない。AIモデルにまつわる、未解決のリスク――間接的なプロンプトインジェクション――の単なるバリエーションに過ぎないからだ。AIモデルがコンテンツを処理するとき、データとシステム指示を確実に区別することはできない。

PoCでは、汚染されたドキュメントを2つ作成した。1つはPlaid Link用、もう1つはStripe Checkout用で、それぞれに偽のPyPIパッケージ名が含まれていた。

AnthropicのHaikuモデルは40回の実行で毎回、ドキュメントに引用されている悪意のあるパッケージを、プロジェクトのrequirement.txtファイルに書き込んだ。出力にはそれについて何ら言及がない。会社のSonnetモデルはそれより良く、実行の48％（19/40）で警告を出したが、それでも悪意のあるライブラリをrequirements.txtに書き込んだのは53％のケース（21/40）だった。AI企業の最上位モデルであるOpusはさらに良く、警告を出したのは75％（30/40）で、requirements.txtファイルやコードに悪い依存関係を書き込むことには結局ならなかった。

ShmueliはOpusについて、「より良く学習されていて、より多くのパッケージで訓練されており、より洗練されています」と述べた。

つまり、高価格帯の商用モデルは“でっち上げ”られた依存関係を捕捉できるように見えるものの、この問題はContext Hubだけに限らない。Shmueliによれば、AIモデルにコミュニティが執筆したドキュメントを利用可能にする他のあらゆる仕組みも、コンテンツのサニタイズの面ではことごとく行き届いていないという。

信頼できないコンテンツへの露出は、開発者のSimon Willisonが“致命的トライアド（lethal trifecta）”AIセキュリティモデルで挙げた3つのリスクのうちの1つだ。したがって、精査されていないドキュメントが現状のままなら、AIエージェントにネットワークアクセスを与えないか、少なくともプライベートデータへのアクセスを与えないようにするのが賢明だろう。®

関連記事

• AI
• 開発
• セキュリティ

これに近いもの