シャドーITが再び台頭している。今回はAIエージェントが主役だ

ベンダー各社は、御社のデータにアクセスできるAIエージェントを導入しています。御社のTPRMプログラムは、こうしたエージェントを検知するようには設計されておらず、攻撃者たちはすでにそのことを把握しています。

---

御社のTPRMプログラムは、把握しているベンダーを評価します。セキュリティ態勢をスコアリングし、アンケートを送付し、外部への露出状況を監視します。しかし、ほぼ間違いなく行われていないのは、そうしたベンダーの1社がAIエージェントを導入した際に何が起こるかを追跡することです。AIエージェントとは、御社のデータへのアクセス権限を与えられ、サードパーティのAPIを呼び出し、セッション間でコンテキストをキャッシュし、御社のリスク評価が対象とする境界線の外側で完全に動作する自律システムのことです。

これが新たなシャドーITの問題です。そして、少なくともネットワークログ上で確認できた2010年代のSaaSの無秩序な拡大とは異なり、エージェント層は、現在の管理体制からは検知できないように設計されています。

「御社のベンダーが提供するAIエージェントは、御社が導入も評価も確認もしていない『第四の当事者』であり、すでに御社のシステムへの読み取り権限を持っている可能性があります。」

気づかないうちに、取引先がAIエージェントになっていた理由

エンタープライズソフトウェアにおけるAIエージェントの普及曲線は、近年の同種の技術変革の中でも群を抜いて急速に進んでいます。SaaSよりも、モバイルよりも、クラウドよりも速いペースです。その理由は単純明快です。統合の障壁がほぼ存在しないからです。ベンダーの開発チームなら、たった半日で自社製品にAIエージェントを組み込むことができます。わずかな設定変更を行うだけで、そのエージェントにAPIや顧客データのコンテキスト、外部ツールサーバーへのアクセス権限を付与することが可能です。

TPRMの観点から見れば、これは、18ヶ月前に取引を開始したベンダー――そのセキュリティ質問票を確認し、ペネトレーションテスト報告書を提出した相手――が、それ以来、実質的に異なるリスク主体へと変化してしまったことを意味します。彼らはそのことを通知しませんでした。通知する義務もなかったのです。そして、年次レビューのサイクルでは、リスクが存在してからかなり時間が経ってからでなければ、その事実に気づくことはできません。

従来のTPRMでは、すでに「第4者リスク」（つまり、自社のベンダーが利用するベンダー）への対応に苦慮しています。AIエージェントの登場により、この課題は飛躍的に複雑化しています。たった1つのエージェントを統合するだけで、ツールの呼び出し、MCPサーバーへの接続、コンテキストプロバイダーとの関係といった動的な連鎖が生じます。これらは、前回ベンダーを評価した時点では存在しなかったものであり、モデルの更新やプラグインの追加が行われるたびに変化し続けます。

現在のTPRMプログラムが抱える3つの課題

ほとんどのTPRMプログラムは、安定的で特定可能なベンダーの足跡を基盤として構築されてきました。エージェント層は、既存のフレームワークでは埋めるよう設計されていなかった3つの構造的なギャップを生み出します。

こうしたギャップは、ある共通のテーマに集約されます。TPRMフレームワークは、ベンダーをある時点における静的な存在として評価するものです。一方、AIエージェントは本質的に動的な存在であり、モデルの更新に伴い進化し、新たなツールの統合を行い、データへのアクセス範囲を段階的に拡大していきます。給与計算業者には有効な評価サイクルであっても、四半期ごとのレビューの合間に動作が変化し得るシステムには適さないのです。

なぜこれがソフトウェアのサプライチェーン危機を反映しているのか

2021年後半のLog4Shellインシデント当時、セキュリティ担当として従事していた方なら、「エージェント型リスク」というパターンに、不快なほど親近感を覚えることでしょう。 Log4Shellの脆弱性は、あなたのアプリケーションそのものには存在しませんでした。それは、たまたまアプリケーションが呼び出していたロギングライブラリに存在し、そのライブラリが、攻撃者が制御する文字列を実行可能な命令として解釈してしまったのです。影響範囲が甚大だったのは、まさにその依存関係が見えなかったためです。組織はLog4jを実行していることを知らず、つまり脆弱性があることさえ認識していなかったのです。

その仕組みは異なります――JNDI検索の代わりにプロンプトの注入、クラスパス読み込みの代わりにツールの呼び出しチェーン――が、構造的な問題は同じです。つまり、信頼された仲介者が、攻撃者が制御する入力を、それを実行するシステムに渡してしまうのです。そして、TPRMから得られる教訓は、サプライチェーンセキュリティが教えてくれたものと同じです。つまり、ベンダー自体だけでなく、ベンダーが関与するあらゆる要素によって生じるリスクについても、あなたが責任を負わなければならないということです。

プロンプトインジェクションとは、文書、APIレスポンス、またはWebページに埋め込まれた攻撃者が制御するコンテンツが、AIエージェントによって信頼できる指示として処理され、エージェントがその指示に基づいて動作してしまう現象を指します。エージェントがユーザーのデータやシステムへのアクセス権を持っている場合、その動作にはデータの持ち出し、不正な書き込み、あるいは横方向の移動などが含まれる可能性があります。これは単なる仮定上のリスクではありません。実際のAIエージェントの運用環境において、すでに実証されています。

エージェント時代における効果的なTPRMのあり方

TPRMプログラムをAIエージェントのリスクまで対象範囲に拡大するには、一から作り直す必要はありません。既存の3つの取り組みを、現在カバーされていない領域にまで拡大すればよいのです。

ベンダー向け質問票にAIエージェントに関する開示項目を追加しましょう
具体的に次のように尋ねてください：御社の製品はAIエージェントを使用していますか？AIエージェントはどのようなデータにアクセスできますか？どのようなサードパーティ製ツールと連携していますか？データ処理に影響を与えるモデルの更新について、どのように開示していますか？多くのベンダーはこれまでこうした質問を受けたことがありません。つまり、リスク管理チームが対応できる形で、その情報が存在していないのです。

AIモデルの更新パイプラインをサプライチェーンリスクとして扱う
ベンダーが基盤となるモデルを更新することは、依存関係のバージョンアップと同等のサプライチェーン上の事象です。新しいモデルは、評価済みのモデルとは異なるデータ処理の挙動、ツール呼び出し機能、あるいはセキュリティ特性を有している可能性があります。ベンダーのインフラストラクチャを継続的に監視する際には、可能な限り、モデルのデプロイ活動からのシグナルも対象に含める必要があります。

ツール呼び出しの依存関係を含めるよう、サードパーティ・マッピングを拡張する
AIエージェントを利用するベンダーを評価する際、そのエージェントのツール連携は「サードパーティ・リスク」となります。これらをマッピングしてください。ベンダーのエージェントがお客様のデータコンテキストを用いて呼び出す、サードパーティが運営するMCPサーバーは、契約書に記載されているか否かにかかわらず、お客様のサプライチェーンにおける一要素となります。

AI対応ベンダーに対する評価頻度を高める
モデルの更新やエージェントのプラグイン追加のたびにリスクの範囲が変化するベンダーにとって、年1回のアンケート調査では不十分です。AI対応ベンダーには、継続的な外部モニタリングと、より頻繁な体系的な評価が必要です。これらは、単に暦上の時期だけでなく、インフラストラクチャや製品の動作における観測可能な変化に基づいて実施されるべきです。

エージェントへのアクセス権限について、契約上データ最小化の範囲を明確に定める
ベンダーのAIエージェントが特定のデータカテゴリへのアクセスを必要としない場合は、契約書にその旨を明記し、外部モニタリングによって確認してください。エージェントの権限範囲の拡大は、目立たず、徐々に進行します。契約上のデータ最小化要件と継続的な状態監視を組み合わせることが、制御層となります。

まだ誰も問いかけていないガバナンスの問題

この戦術的なチェックリストの背後には、より難しい問いが潜んでいます。それは、TPRMプログラムが多くの組織が予想するよりも早く答えを出さなければならない問題です。つまり、AIエージェントがセキュリティ侵害を引き起こし、その侵害がベンダーのサプライチェーンの4段階先で発生した場合、誰が責任を負うのか、という問いです。

規制の枠組みは変化しつつある――EU AI法、DORA、そして改訂されたNISTのガイダンスはいずれもこの問題への対応を示唆している――が、AIの普及ペースに比べればその動きは遅れている。当面の間、AIエージェントの開示、データアクセス範囲、インシデント通知に関する明確な契約上の義務を定めている組織は、エージェント型システムが登場する以前に作成された標準的なベンダー契約に依存している組織よりも、はるかに有利な立場に立つことになるだろう。

DORAのICT第三者リスク要件では、すでにすべての重要な情報資産の依存関係に関する文書化が求められています。規制当局が、AIエージェントがこれらの枠組みにおける「ICTサービス」に該当するかどうかを明確にし始めている中（初期のガイダンスでは該当すると示唆されています）、AIベンダーのインベントリを十分に整備している組織は、コンプライアンス対応において大きな先行優位性を得ることになります。監査上の指摘事項となる前に、今すぐそのインベントリを構築しましょう。

現在TPRMを導入している場合、これは何を意味するのか

実情としては、ほとんどのTPRMプログラムには、その実態がまだ把握できていないギャップが存在しています。これらのプログラムでは、ベンダーの対外的なインフラストラクチャをカバーし、アンケートを通じてベンダーの内部セキュリティ対策の一部を把握し、外部への攻撃対象領域を継続的に監視しています。 しかし、欠けているのは「エージェント層」に対する可視性です。つまり、ベンダーが展開しているAIシステム、それらのシステムが行っているツールの呼び出しチェーン、あるいはそのチェーンが生み出しているサードパーティの依存関係などです。

この隙を、敵対者は積極的に狙っている。彼らは、AIエージェントのエコシステムが、オープンソースのサプライチェーンを攻撃の標的として非常に魅力的なものにしたのと同じ構造的特性――すなわち、広く普及し、深く信頼され、かつほとんど監視されていない――を備えていることを理解しているからだ。

「シャドーITは可視性の問題でした。エージェント層は、自律的な意思決定が伴う可視性の問題であり、それは最も信頼しているベンダーとの関係の内部に存在しています。」

その対応策は、シャドーSaaSやソフトウェア・サプライチェーンのリスクに対して有効だったものと同じです。すなわち、体系的な発見、分類、そして継続的な監視です。全面的な禁止ではありません。SaaSの導入を阻止しようとした時と同様、そのような措置はもはや効果を発揮しないでしょう。むしろ、既存のTPRMフレームワークを、リスクが実際に存在する領域へと意図的に拡張していくことが求められます。

御社のベンダーはすでにAIエージェントを導入しています。問題は、御社のリスク管理プログラムが、それらのエージェントがどのような情報にアクセスできるかを把握しているかどうかです。