サプライチェーンと名前空間の乗っ取り(スキル・パッケージ)

この失敗は何か

このパターンには2つの入口があります。どちらも利用者側の設定では防ぎにくいという共通点で束ねています。

1. 配布経路の汚染 — マーケットプレイスやレジストリに、悪意あるスキル・拡張機能が並ぶ
2. 名前空間の先取り — まだ誰も登録していない名前を攻撃者が先に押さえ、エージェントがそこを参照しにいく

2つ目は見落とされがちですが、構造としては同じです。エージェントが「この名前のパッケージを入れればよい」と判断したとき、その名前が攻撃者のものであれば、審査を経ずに悪意あるコードが実行環境に入ります。名前が存在しなかった理由は問いません。エージェントがハルシネートしたのかもしれませんし、ドキュメントに書かれたまま放置されていたのかもしれません。

この型のバリエーション

入口	事例	何が効かなかったか
マーケットプレイス	ClawHub の悪意あるスキル群	配布前の審査。ウォレット・API・SSH の資格情報が外部送信された
マーケットプレイス + 外部URL	可変外部URLでスキャナーを回避、26,000人に到達	静的スキャン。コードは正規に見え、後から取得先の中身だけが差し替えられた
名前空間の先取り	(パターン内に公開事例なし。llms.txt に残る未登録参照が近い)	参照先の実在確認

2件目が示しているのは、インストール時点の検査では足りないという事実です。このスキルは公開当初は無害で、審査を通過し、Instagram での宣伝を通じて26,000人以上に届いたあとで、外部から取得するペイロードがユーザーデータの収集へ差し替えられました。コードの中身を見る検査は、コードが後で変わる設計の前では無力です。

これは例外的な事故ではない

この種の問題がどれくらいの規模で存在するのかは、実測されています。CISPA Helmholtz Center による調査(HarmfulSkillBench、2026年4月)は、2つの主要なスキルレジストリから 98,440件のスキルを分析し、全体の 4.93% が有害と判定されるという結果を報告しています。レジストリ別では偏りが大きく、一方は 8.84%、もう一方は 3.49% でした。

つまり、記録されている事例は運悪く1つのマーケットプレイスで起きた事故ではなく、エコシステム全体に一定割合で存在する状態だと考えたほうが実態に近いということです。導入時のレビューを「たまたま悪いものを引かないようにする」ではなく、「一定割合で混入している前提で被害範囲を設計する」方向に切り替える根拠になります。

なぜスキルの権限が問題になるのか

AIエージェント基盤の多くは拡張の仕組みを持っています。スキル、プラグイン、ツールパック、MCPサーバー。呼び方は違っても、追加した機能をエージェントが呼び出せるようになる点は共通です。

問題は、インストールした拡張が、そのエージェントの権限をほぼそのまま引き継ぐことです。ブラウザ拡張のような権限確認の画面がなく、スコープを絞る仕組みも用意されていないことが珍しくありません。結果として、拡張は環境変数のAPIキー、SSH鍵、認証情報ファイルなど、エージェントが到達できるものすべてに手が届きます。

「悪意ある」スキルと「有害な」スキルは別物

同じ調査は、もう一つ重要な区別を示しています。ここまで述べてきたのは、マルウェアを隠して配布される悪意あるスキルです。一方で、隠し要素が何もなく、説明どおりの機能そのものが問題であるスキルも存在します。攻撃や詐欺、プライバシー侵害の手順を提供することを目的として公開されているものです。

後者が厄介なのは、コードを読んでも「悪意ある挙動」が見つからない点です。そして調査によれば、有害なタスクがスキルとして事前に組み込まれた形で提示されると、モデルの拒否率が大きく下がります(有害スコアが 0.27 から 0.47 へ上昇)。スキルという形式そのものが、モデルにとって「承認済みの手順」として働き、安全機構を迂回してしまうという指摘です。

インストール審査を「マルウェアが入っていないか」だけで設計すると、この後者は素通りします。

従来のサプライチェーン攻撃との違い

npmやPyPIの汚染パッケージと似ていますが、危険度の性質が異なります。

	パッケージ供給網	エージェントスキル供給網
実行される場所	ビルド環境・実行環境	エージェントの実行文脈
得られる権限	そのプロセスの権限	エージェントの権限すべて(多くは広い)
発動のタイミング	インストール時・実行時	エージェントの判断で自動的に
検知のしやすさ	コードを読めば分かる	挙動がプロンプト内容に依存し条件付きになりうる

とくに最後の行が厄介です。スキルの実体が自然言語の指示と設定であることも多く、悪意ある動作が特定の文脈でのみ発動するように書けます。インストール時にコードを一読しても、その分岐は見えません。

実務的な対策

1. 資格情報のスコープを絞る — エージェントが保持する認証情報が、そのまま被害の範囲になります。長期の全権トークンをやめ、用途ごと・短命・最小権限に切り替えることが最も効果的です
2. インストールを承認制にする — 依存パッケージの追加と同じ扱いにする。誰が、いつ、なぜ入れたかを記録し、バージョンを固定します。個人の判断で自由に追加できる状態を放置しないでください
3. 外部から取得する設計のものを警戒する — 実行時に外部URLからコードや指示を取りにいくスキルは、審査した内容と実行される内容が一致しません。可能なら禁止し、必要なら取得先を固定・検証します
4. エージェントが提案した名前をそのまま信じない — 存在しないパッケージ名を提案することがあり、その名前は先取り登録されうるものとして扱ってください。実在確認と発行元の確認を挟みます
5. 実行環境を分ける — ネットワークアクセスが必要なスキルと、機密情報に触れるスキルを同じ文脈に置かない
6. 外向き通信を監視する — 資格情報の窃取には送信経路が必要です。送信先を許可リスト方式にし、想定外の宛先を検知できるようにします

当サイトではこの型の「対処すべき層」をベンダーの修正としています。配布側の審査と権限モデルで解くべき問題であり、利用者側にできることは被害範囲を絞ることまでだからです。ただし審査が整うまでには時間がかかると見ています。

この分野の状況

拡張の仕組みは各基盤が急速に整備している最中で、権限モデルの設計はまだ固まっていません。ブラウザ拡張が権限確認とストア審査に辿り着くまで長い時間がかかったことを踏まえると、当面は利用側が資格情報のスコープで自衛するのが現実的です。

参考文献

• Jiang, Y., Zhang, Y., Backes, M., Shen, X., Zhang, Y. (2026). HarmfulSkillBench: How Do Harmful Skills Weaponize Your Agents? CISPA Helmholtz Center for Information Security. arXiv:2604.15415

関連するパターン

• 参照先のファイルに書かれた内容をエージェントが検証せず実行する例としてリポジトリ・設定・メタデータファイルの記述をエージェントが検証せず実行
• 外部からの入力が開発パイプラインに到達する経路として注入された指示による承認ゲート・許可リストの迂回