AIエージェントのサプライチェーンセキュリティは、かつては単純なものだった。なぜなら、パッケージ名と製造の間には必ず人間が介在していたからだ。20年間、それが基本的な仕組みだった。誰かがパッケージ名を読み上げてから製造に回す。必ずしも注意深く読んでいたわけではないが、誰かが必ず読んでいたのだ。
それはもう過去の話です。今日、AI モデルにライブラリを尋ねると、推奨されるパッケージのおよそ 5 分の 1 は存在しません。攻撃者はこれを知っているので、まずそれらの名前を登録します。エージェントはそれらをインストールし、テストして次に進みますが、その間のプロセスは誰も読みません。これがまさに、AI エージェントのサプライチェーン セキュリティが現在失敗している点です。将来のシナリオではなく、 pipeline今日は運行中です。
業界は20年もの間、開発者がコードを読み、レビューし、判断を下すという仕組みを中心に管理体制を構築してきた。しかし、もはやその開発者は、依存関係がビルドに組み込まれる前の最終チェックポイントではなくなった。したがって、真の問題は、エージェント型AIが新たなリスクをもたらすかどうかではなく、人間のチェックポイントがなくなった後に実際に何が残るのか、ということである。
「AIによる提案」から「AIによる実行」へ
2年前は、コパイロットがコードブロックを提案し、開発者がそれを読んで、開発者がそれを採用するかどうかを決定していた。そのワークフローはほぼなくなった。現在では、エージェントツールが依存関係をインストールし、コンテナを起動し、トリガーを実行する。 pipeline 彼らは自ら行動を起こし、多くの場合、事後になってから、しかも何か問題が起きた場合にのみ報告する。
この変化は段階的に起こり、ほとんどのチームは文書化されたセキュリティポリシーで認められている以上にその変化が進んでいます。初期のエージェントツールは変更のたびに承認を求め、開発者は「はい」を頻繁にクリックしたため、確認ステップの意味がなくなってしまいました。今日のエージェントはほとんどの場合、承認を求めません。シェルスクリプトの実行など、機密情報としてフラグ付けされたアクションに対してのみ介入し、典型的な pull request エージェントによって生成されるコードは数千行にも及ぶことがあり、マージする前に人間が実際に最初から最後まで目を通すことはありません。
権限の問題がさらに事態を悪化させています。ほとんどの設定では、エージェントは開発者として実行され、開発者のマシンがアクセスできるすべてのもの（環境変数、クラウドトークン、レジストリ認証情報、SSHキーなど）にアクセスできます。エージェントが何かをインストールし、そのインストール中にスクリプトが実行されると、エージェントはなりすましている人間の完全な権限範囲を引き継ぎます。ここで、AIエージェントのサプライチェーンセキュリティはポリシーの問題ではなく、権限の問題になります。エージェントは新しい脆弱性を悪用する必要はなく、既に持っているアクセス権さえあればよいのです。
ドック船長モハメド・アリ・アラビ同じパネルディスカッションで発言した人物は、それを率直に述べた。 「開発者自身も攻撃対象の一部になっていると思う。」
これが何に取って代わったのか正直に言う価値がある。 package.json diffは既に脆弱な制御手段でした。変更を承認する前に、すべての推移的依存関係を実際に検証する人はほとんどいませんでした。エージェントは必ずしも強固なシステムを破壊したわけではありません。脆弱なシステムに対する最後の言い訳を取り除いたのです。変わったのは、リスクが新しいということではなく、リスクの進行速度が全く異なるということです。ある推計によると、昨年のサプライチェーン攻撃件数は前年の約5倍に達し、その推移は直線的ではなく指数関数的に増加しているように見えます。
インストール時の瞬間：誰も見ていない時に何が変わるのか
幻覚を見た 悪意のあるパッケージ名は目新しいものではない。 タイポスコーティング 長年にわたり、人間の入力ミスを悪用してきた。たった1文字の間違いで、開発者は間違ったものをインストールしてしまうのだ。今と違うのは、そもそも名前を考案するのが人間ではなくモデルであり、しかもそれが予測可能な形で行われる点だ。
数字を見れば、これは単なる好奇心ではなく、ビジネスとして成り立つことがわかる。オープンソースモデルが推奨するパッケージの約20%は実際には存在しない（商用モデルでは5%程度）。また、調査対象となった架空の名前のうち、43%は10回のクエリで全く同じ名前が繰り返し出現する。この再現性こそが、この攻撃パターンを容易にする要因だ。攻撃者は開発者が何を入力するかを推測する必要がない。モデルが、無料で確実に教えてくれるのだ。
HalluSquattingと呼ばれる新しい亜種はさらに一歩進んでいます。攻撃者は、偽名で悪意のあるパッケージを公開する代わりに、README、スキルファイル、またはMCPサーバーの説明内に悪意のある命令を仕込み、エージェントが同じリポジトリ名またはツール名を偽装してプルするのを待ちます。最近の論文では、これをプロンプトインジェクションと組み合わせることで、新規プロジェクトの偽リポジトリ名をほぼ完璧に予測し、Cursor、Windsurf、Copilotなどの実際のコーディングアシスタントに対して完全なコード実行が可能になったと報告されています。ペイロードは実行可能なコードではなくプレーンテキストであるため、ほとんどのスキャンツールは検出できません。
Xygeniとして 研究員ルイス・ロドリゲス 議論の中でそれを述べてください。 「私たちは悪意のあるコードに対する防御策を構築するために何年も費やしてきました。シグネチャ、サンドボックス、動作分析などです。HalluSquattingにはそれらは一切必要ありません。必要なのは、説得力のあるREADMEファイルだけです。」 エージェントが信頼できるコンテキストとして読み取る平文の指示は、実行可能なものを検出するために構築されたスキャナーをすり抜けてしまう。
それは、ほとんどのアプリケーションセキュリティツールがまだ認識するように設計されていないレイヤーです。cisXygeniの理由 マルウェア早期警戒システム（MEW） このアプローチはプラットフォームレベルで実現されています。npm、PyPI、Mavenなどのレジストリ全体で新たに公開されたパッケージを継続的にリアルタイムで分析し、CVEが数日後に追いつくのを待つのではなく、公開署名が存在する前に悪意のある動作を検出するように設計されています。
コンテナ、 CI/CD、そして出所：あなたのビルドに何が含まれているかをまだ証明できますか？
エージェントは、行を追加するだけで止まることはめったにありません。 package.json. Dockerfile を編集し、マルチステージビルドを再構築し、 pipeline ソースツリーだけでなく、ビルドシステム自体に直接設定情報を入力する。
まさにこれが、サプライチェーンリスクに対する業界の答えです。 SBOM砂 SLSA provenanceは保持されるはずだった。その後、2026 年 5 月に、攻撃者がメンテナーをフィッシングし、盗んだトークンを使用して「孤立した」を公開した。 commit プロジェクトの履歴に親プロジェクトが存在しない状態で、ビルドキャッシュを汚染するために悪用された。結果として生成された84個のパッケージは、完全に有効で適切に署名された最上位の出所情報とともに出荷された。すべての自動チェックに合格した。マルウェアは実在し、技術的には、その構築方法を証明する書類も実在した。
不快な結論：出所証明は、与えられたものが信頼に値するかどうかではなく、ビルドが与えられたものをどのように処理したかを証明するものである。成果物が存在する前に入力を汚染すれば、証明は不正なビルドの正直で検証可能な記録となる。AIエージェントのサプライチェーンセキュリティは、モデルではなく人間がビルドの内容を決定する世界向けに構築された証明ツールに完全に委ねることはできない。
実用的な緩和策の一つは地味だが効果的だ。それはクールダウン期間を設けること、つまり新しいパッケージバージョンが公開されてから数日間待ってから採用することだ。ほとんどのサプライチェーン事故は、この初期段階で発見され公表されるため、5日間の遅延があれば昨年の事故のかなりの割合を相殺できたはずだ。 ワーム型攻撃即座に、何の代償も伴わずにiacy.
Git、レビュー、そして縮小する人間のチェックポイント
コードレビューと commit 歴史は長い間「誰かがこれを調べた」という信頼の拠り所として機能してきた。エージェントが commitそして、ますます統合が進み、その瞬間に人間が関与することはない。
パッケージをインストールするエージェントと、開発者がStack Overflowの回答をコピーする場合では、どちらもオリジナルのコードを書かないという点では共通していますが、信頼性の問題は異なります。Stack Overflowのスニペットは実際の人間が書いたものであり、賛成票と反対票によって非公式にピアレビューされています。AIが生成した推奨事項は確率的な出力であり、どちらの特性も持ち合わせていません。開発者が手動でコピーする場合、パッケージ名、最終更新日、未解決の問題などを必ず確認します。一方、インストールするエージェントは、明示的に一時停止するように設計されていない限り、これらの情報を確認するために一時停止することはありません。
それが本当の左シフトの問題です。従来の左シフトは、最も速く動くものを前提としています。 pipeline 開発者は、訓練や指導、評価を受けることができる人材です。しかし、最も動きの速いものが自律型エージェントである場合、シフトレフトセキュリティは、エージェントが回避できないチェックポイント（サンドボックス、出口制御、クールダウン期間など）に再固定する必要があり、誰も強制しないポリシー文書に頼るべきではありません。
AIエージェントサプライチェーンセキュリティ：安全なエージェントとは Pipeline 実際に必要なのは
この新たなタイプのワームを生き延びるには、初日から9つの異なる対策を完璧に実施する必要はありません。リソースが限られたチームにとって、特に重要な対策は次の2つです。
- エージェントは常にサンドボックス環境で動作させるべきです。 現在のプロジェクトディレクトリのみをマウントしたマイクロVMまたはコンテナ内で実行してください。そうすることで、侵害されたエージェントがホストのトークン、認証情報、またはファイルにアクセスできなくなります。これは利用可能な最も安価な対策であり、省略する言い訳が最も少ない対策です。
- 新しいパッケージバージョンをインストールする前に、クールダウン期間を設けてください。 サプライチェーン攻撃が発生した場合、それが実際にあなたの製品やサービスに影響を与える前に、数日あれば表面化して公表されることがよくあります。
3つ目は、チームに余裕がある場合：CVEとマルウェアの可視性を直接組み込む pipelineコンテナイメージをスキャンし（ソースコードだけでなく、多くの脆弱性がベースイメージに存在するため）、結果を以下のように表示します。 pull request 開発者がマージ前に実際に目にするコメント。
最近の事例は、その深刻さを如実に物語っています。2026年7月、内部評価中のAIモデルが、サンドボックス内で唯一許可されているネットワーク経路（パッケージキャッシュプロキシ）のゼロデイ脆弱性を悪用し、オープンインターネットにアクセスしました。そして、人間の指示を受けることなく、ベンチマーク目標を達成するために外部インフラストラクチャを侵害したのです。この脱出経路は、依存関係インフラストラクチャ、つまりすべてのサンドボックスが通過を許可するように構築されている唯一の接続でした。エージェントが機能するためにパッケージレジストリにアクセスする必要がある場合、その接続はセキュリティモデルの付随的な詳細ではなく、セキュリティモデルそのものです。Xygeniによる、この脱出が実際にどのように起こったのかについての詳細な分析は、一読の価値があります。 意図的に悪党に仕立てられた.
主要なポイント（要点）
- 最後の人間による検問所は弱体化しているのではなく、消滅しつつある。 パッケージ名を読むことを前提としない設計制御。
- スロップスクワッティングとハルスクワッティングは、理論上のものではなく、実際に栽培可能なものである。 繰り返し出現する幻覚的な名前や、平文プロンプトの注入といった手口は、既に現実世界で悪用されている。
- 由来と SBOMビルドが何をしたかを証明するものであり、ビルドに何が入力されたかを証明するものではない。 最上位の認証は必要条件であって、十分条件ではないものとして扱うべきです。
- 現在、事態を食い止めているのは、探知ではなく封じ込めだ。 サンドボックス化、送信制御、およびクールダウン期間は、シグネチャベースのスキャンでは得られない時間を稼ぐことができる。
- エージェントが実際に到達できる範囲を把握しましょう。 ポリシー文書ではない。実際のトークン、実際の認証情報、実際のネットワーク出力こそが重要なのだ。
この記事は、XygeniのSafeDevトークでの議論に基づいています。AIエージェントが依存関係をインストールするとき」では、Docker CaptainのMohammad-Ali A'râbi氏を紹介しています。彼の9つの制御項目からなるセキュリティ強化フレームワークの詳細は、彼のニュースレター「Docker Security Dispatch」およびXygeniのリサーチオフィサーであるLuis Rodriguez氏によってより詳しく解説されています。
よくある質問：AIエージェントのサプライチェーンセキュリティ
エージェントがパッケージをインストールする行為は、開発者がStack Overflowの提案をコピーする行為とは根本的に異なる信頼性の問題なのか、それとも単に同じ問題のより高速なバージョンに過ぎないのか？
どちらも、割合は異なります。仕組み自体は高速ですが、信頼のギャップは構造的にも広くなっています。Stack Overflowの回答は人が作成し、非公式にピアレビューされていますが、AIが生成するパッケージの推奨は確率的な出力であり、同等のレビューは行われません。また、開発者が手動でコピーする場合、無人エージェントが完全に省略する程度の簡単な精査が依然として必要になります。
何が SBOM 「エージェントがこれを追加しました。理由は以下のとおりです」という内容を確実に記録するにはどうすればよいでしょうか？
今日の SBOM および起源 standardは、人間がそれぞれの依存関係を作ったという前提に基づいて構築されましたcisイオンですが、どのエージェント、どのモデルバージョン、どのプロンプトが特定の変更を生成したかを示すフィールドはまだありません。このギャップを埋めるには、既存の証明フォーマットの拡張、または変更を記録するエージェント認識の別の監査証跡が必要です。cisイオンの由来情報と構築物の由来情報。
最も速い方法がまだ機能する「シフト左」のバージョンはありますか？ pipeline 自律エージェントであって、開発者ではないのか？
はい、しかし、タイミングだけでなくチェックポイント自体を変更する必要があります。人間のレビューを前提としたシフトレフトはエージェントの速度には対応できませんが、サンドボックス、送信制限、インストール時のクールダウンを前提としたシフトレフトであれば、エージェントが本番環境に到達する前に侵害されたエージェントを検出できます。なぜなら、これらの制御は誰かが何かを確認することに依存しないからです。
