The Third-Party Agent Problem: Why Security Built for AI You Chose Misses the Agents You Didn’t
2026/10/10 TheHackerNews — 2026 State of Agent Security Report の調査対象となった環境で明らかにされたのは、現時点で約 1,280 のサードパーティ製品に AI が組み込まれている状況である。そのうち、シングルサインオン (SSO) の管理下にある製品は約 282 に留まる。残る約 1,000 の製品は、デフォルトでは ID 管理基盤から可視化できない状態にある。これは、誰かが意図的に隠した結果ではない。ID 管理基盤が統制できるのは、その基盤を経由して認証する対象だけであり、多くのエージェントが、その認証経路を利用しないためである。
セキュリティ業界がようやく認識し始めた変化を、最も明確に示しているのが、このギャップである。ここ数年、AI セキュリティが対処してきたのは、企業が自ら導入を決定した AI に関する問題だった。企業が AI の利用を決定し、ライセンスを調達し、ゲートウェイの背後にモデルを展開すると、その導入対象に対してセキュリティチームがセキュリティ対策を適用してきた。
しかし、AI エージェントの導入経路は異なる。エージェントは、すでに企業が利用しているソフトウェアの内部に組み込まれて提供され、企業が明示的に導入を決定しない状態で利用環境へ入り込んでいく。
セキュリティ対策よりも導入の意思決定が重要だった理由は？
従来の自社導入型 AI に対するセキュリティ対策は、いずれも導入を判断するタイミングが存在することを前提としている。モデルのスキャンはモデルが選定されていることを前提とし、プロンプトの検査はゲートウェイが展開されていることを前提とし、利用許容ポリシーは承認対象となる AI の導入判断の存在を前提としている。
こうした意思決定の機会があったからこそ、セキュリティチームは導入前のレビューを実施し、監視／制御の対象を特定し、責任者を明確にできた。しかし AI エージェントは、その機会を経ずに導入される。
2026年8月に提供が開始された Salesforce の Slack Code では、ユーザーが任意の会話でコーディング・エージェントをメンションできる。エージェントは共有された会話の文脈を読み取り、コードを記述し、プルリクエストを作成する。
その発表では、「追加の IT 作業を必要とせず、初日から Slack に組み込まれたセキュリティモデル／権限／管理者向け制御を継承する」と、エージェントについて説明されている。
しかし、セキュリティチームの視点から見れば、これは GitHub や本番環境のインフラにアクセスする自律的なエージェントが、チャットツールのチャンネル・メンバーシップにより統制されることを意味する。
新たな導入の意思決定が行われていないため、監視／制御の仕組みを、セキュリティチームが事前に組み込む機会も存在しなかった。
3 つの導入経路と、共通する 1 つの到達点
セキュリティ責任者は、AI エージェントを「購入したもの」と「自社で構築したもの」の 2 種類に分類する傾向がある。しかし、実際には 3 つ目のカテゴリーが存在し、それが最も大きな割合を占めている。
- 継承型エージェント (Inherited Agents) は、既存のプラットフォームに組み込まれ、製品アップデートを通じて提供される。
- 設定型エージェント (Configured Agents) は、企業独自のプロンプトやロジックを使用する一方、実行環境／モデル／コネクタは外部事業者が提供するものを利用する。
- 自社構築型エージェント (Built Agents) は、企業がインフラ全体を管理する環境に、オープンなフレームワークを使用して構築される。
主要なアプリケーションが次々とエージェント・プラットフォームへと進化する中、最初の 2 種類が導入における圧倒的な多数を占めており、その数は指数関数的に増加している。
一方、3 つ目の自社構築型エージェントは、規模が最も小さく、増加ペースも最も緩やかである。ただし、ソースコードのリポジトリをスキャンし、ビルド工程にセキュリティ上の承認ゲートを設けられるのは、このカテゴリーだけである。
どの経路から導入されたとしても、エージェントが最終的に到達する環境は共通している。
CRM 内で利用され始めたエージェントが、データウェアハウスから情報を読み取り、チケット管理システムへ書き込むようになる。クラウド・プラットフォーム上で構築されたエージェントが、Salesforce／Slack／Drive にアクセスするためのトークンを保持するようになる。
これらのエージェントは、いずれも企業のアプリケーション層で動作するが、その活動範囲には固定された境界が存在しない。
あらゆるエージェントに適用できる 4 つの質問
すべての AI エージェントは、大きな括りで言うと 2 つの要素で構成される。
1 つは推論を担うモデルであり、もう 1 つは、そのモデルを実際に行動する主体へと変える周辺の仕組み (スキャフォールディング) である。後者は、エージェントの接続先／呼び出せる機能／行動するタイミングなどを決定する。
リスクの大半はモデル自体にあるのではなく、こうした周辺の仕組みと、それが組み込まれたエコシステムに存在する。
そのリスクは、次の 4 つの観点から評価できる。いずれも、モデルが単独で何をするかを問うものではない。
| 確認すべき領域 | 実際に確認する内容 |
|---|---|
| ID (Identity) | エージェントはどこかに登録されているか。「このエージェントの責任者は誰か」と尋ねたとき、担当者を明確に特定できるか。それとも、作成者の ID を使用して、明示されないまま動作しているか。 |
| 権限 (Permissions) | エージェントには何が許可されているか。その権限は必要以上に広くないか。作成時に誰の OAuth スコープ／ロールを継承したのか。また、その継承は意図的に承認されたものか。 |
| 接続性 (Connectivity) | エージェントが利用する製品／アクセス許可／データストア／ほかのエージェントを経由して、直接的／間接的にどこまでアクセスできるか。これは侵害時の影響範囲を把握するための重要な問いであり、エージェント自身の設定画面だけでは、ほとんどの場合、答えを得られない。 |
| 活動 (Activity) | エージェントは実際に何を行っているか。その行動は、本来の役割に照らして正常か。プロンプトに記載された説明ではなく、実際の行動に基づいて評価する。 |
特に接続性 (Connectivity) は、エージェント・セキュリティを、既存のセキュリティ製品と区別する重要な要素となる。
ベンダー向けのセキュリティ質問票／プロンプトフィルタ／モデルスキャナは、いずれもエージェントを個別に評価する。しかし、エージェントがどこまでアクセスできるかは、そのエージェント単体ではなく、稼働環境全体の構造によって決まる。
影響力の大きい企業の調達担当者は、すでに対応を変え始めている
JPMorgan Chase のグローバル CISO である Patrick Opet は、ソフトウェア業界に向けた 2025年の公開書簡の中で、サードパーティのサプライチェーンがシステム全体に及ぶリスクになっていると警告した。
その際に例として挙げられたのは、侵害されたサプライヤーを、同行が隔離しなければならないほど深刻なインシデントが発生したことである。その後に Patrick Opet 氏は、AI エージェントにも、同様の厳格な評価を適用するようになった。
理想的には、エージェントには ID を付与する一方、デフォルトでは権限を与えない。そして、エージェントが定められた境界の外にアクセスする前に、誰の代理として行動するのかを IT 部門が確認する必要があるという。
この規模の企業が、AI エージェントをサプライチェーン・リスクとして位置付ければ、ほかの企業が使用するセキュリティ評価質問票にも、今後の数カ月のうちに同様の確認項目が登場することになる。
規制当局も、同じ前提に基づいて動いている。
2026年にかけて段階的に適用される EU AI Act の義務は、企業が AI システムのインベントリを作成し、その責任者を特定し、監督体制を証明できることを前提としている。自社環境で稼働するエージェントを、網羅的に把握できない組織は、こうした要件を満たすことができない。
継続的な管理能力とは何か
50 のエージェントであれば、スプレッドシートと四半期ごとのレビューで管理できるかもしれない。しかし、その数が 500 になれば、同じ方法は破綻する。そして、500 のエージェントが、たった 1 回の製品アップデートによって 5,000 に増える可能性もある。
それに対応するには、以下の情報を継続的に更新し、最新の状態を常に把握できる仕組みが必要になる。
- 現在、どのエージェントが稼働しているのか？
- 各エージェントがどのような権限や設定を継承しているのか？
- 直接的な経路と複数の接続経路を通じて、どこまでアクセスできるのか？
- 実際に、どのような行動を取っているのか？
- それらの状態が、前日からどのように変化したのか？
現在、こうした関係性の可視化を目的とするプラットフォームが登場している。
代表例の 1 つが Reco である。同社の Reco Graph は、人間の ID／非人間 ID／アプリケーション／権限／エージェントの行動を、単一のリアルタイム・ビューに結びつける。これにより、個々の設定ではなく、実際のアクセス可能範囲を分析単位として扱えるようにする。
セキュリティ業界は過去 10 年にわたり、企業自身が導入を決定した AI を保護するための仕組みを構築してきた。
しかし現在では、企業が明示的に導入を決定していないエージェントの方が、数の上で大きな割合を占めるようになっている。
この記事における分析の基礎となった全 6 章のシリーズ「Into the Expanse」では、エージェントの導入経路／ガバナンスの方法／攻撃者による悪用／ランタイムの位置付け／優先的に投資すべき領域について解説している。
Reco のエージェント検出機能の詳細については、reco.ai/platform を参照してほしい。
企業環境における AI エージェントの可視化と統制の問題について解説する記事です。明示的な導入判断を経ない組み込みや過剰な権限継承に伴い、ID 非可視化／過大アクセス権限付与／不正データアクセスといった不具合が生じる危険性があります。対象となる製品は Slack／Salesforce／Reco Graph です。対応策として単一ビューによる一元管理／権限付与の厳格化／継続的なアクセス範囲確認が求められます。
You must be logged in to post a comment.