AIエージェントのセキュリティ対策：どこに構えるかで、守れるものが変わる
目次
去る2026年7月22日〜24日に開催された、Gartner Risk Management Summit 2026 に参加してきました。
各社が標榜する「AIエージェントを守る」製品は、守っている場所が製品ごとに違います。ネットワークの経路に割り込む製品、端末に番人を置く製品、SaaS のテナントに API で入る製品、ログを後から読む製品、ID を配る製品、どれも間違ってはおらず、構えている場所が違うだけですが、ひとつひとつトポロジーや制御の仕組みを把握しないと選定でつまずくと思います。
AIを守る製品は、守る対象を決めてから選ぶ
守る場所が違うだけで、どの製品も間違ってはいません。先に決めるのは製品ではなく、自社の AI が4つのどれなのかということです。
図1：決める順序（製品から入ると決め手が出ない／対象から入ると製品が決まる）
AIエージェントは、到達できなくても攻撃が通る
自社の業務に組み込んだ AIエージェントでは、外から到達できるかどうかだけでは、攻撃が成り立つかを判断できなくなります。
図2：攻撃の道筋の違い（開いた口を見つける／メールを1通送り、AIエージェントが読む）
通った指示を実行するのは自社の資格情報を持った AIエージェントで、被害の上限を決めるのは奪えた権限ではなく、あらかじめ与えた権限になります。
深掘り：守る側から見て、何が入れ替わるか
表1：守る側に残る違い
| 観点 | 従来の攻撃 | AIエージェントへの攻撃 |
|---|---|---|
| 面の数え方 | 到達できるものを数えて減らす | 読みに行く先が面になる |
| ログでの見え方 | 不審な通信や失敗したログイン | 正規のツール呼び出しと変わらない |
| 被害の上限 | 攻撃者が奪えた権限 | あらかじめ与えた権限 |
読み取りしかできないなら情報が漏れる程度で済みますが、更新や送信ができれば実際に業務が動きます。
社内の AI は、守る対象が4つに分かれる
社内の AI は、従業員が使うものと自社が組み込むものに分かれ、それぞれがさらに2つに分かれます。4つのうち統制の入口を持たないのはシャドーAI だけで、そこだけは存在の把握から始まります。
図3：守る対象の4分類（A 会社が配った AI／B シャドーAI／C クラウド／SaaS の上／D 自社アプリに組み込む）
深掘り：4つで何が違うのか
表2：対象ごとの統制の入口と記録
| 対象 | 統制の入口 | 記録 |
|---|---|---|
| A 会社が配った AI | 契約と設定 | 契約の範囲で決まる |
| B シャドーAI | 無い | 残らない |
| C クラウド／SaaS の上 | 提供元の管理画面と API | 提供元に出る |
| D 自社アプリに組み込む | 自分で書いた処理 | 作った側が用意しなければ無い |
B だけが統制の入口を持ちません。稟議も設計も通らないまま業務に入っているので、会社が把握していない以上、まず存在を把握するところから始まります。
AIを守る製品は、構える場所で10の型に分かれる
ブースで見た製品を、構えている場所で並べ直すと10の型になります。その場で止められるのは7つで、残る3つは数えたり試したりする型です。
図4：10の型が構える場所（通信の経路／端末／クラウド・SaaS の側／自社のアプリ／モデル）
深掘り：なぜ ID 基盤が自社アプリにも届くのか
自社で組み込んだ AIエージェントも、動くには鍵が要ります。接続情報を環境変数ではなく ID 基盤の金庫から取りに行く形にすれば、人ではない ID として台帳に載り、権限を消した時点で次の取得から止まります。
シャドーAI に手が届くのが①と②だけなのは、通信も端末も通らない貼り付けは誰にも見えないからです。型ごとの触り方と届く対象は記事の末尾にあります。
製品を入れる前に、4つの対象のリスクの順番を決める
製品を並べる前に決めるのは、どの対象にどれだけのリスクがあるかです。リスクの高い順番に取り組むことになるでしょう。
図5：4つの対象と、それぞれを数えられる場所の対応
契約と利用者、経費と請求、連携許可、権限と記録。どれも製品を入れる前に社内で数えられます。対象ごとに確かめることと、製品を入れる引き金は末尾の表にあります。
構えている場所は、製品名には書かれていない
製品名からも機能の一覧からも、その製品がどこに構えているのかは読み取れません。選定で確かめるのは3つだけです。どこに構えるか、どの対象に届くか、その場で止まるか。
図6：3つの問いと、返ってくるはずの答えの並び
ブースで一社ずつ聞いて初めて分かったことなので、カタログを並べるところから入ると、同じところでつまずくと思います。この10の型は、2026年7月の展示会に出展していた63社のうち、AIエージェントや AIセキュリティを掲げるブースを回り、各社の担当者に製品の制御対象と仕組みを個別に確認して、ペンタコン研究所が整理したものです。
PentaTrail は、外から見える会社の攻撃面を継続的に洗い出して、優先順位づけと是正までを扱う CTEM / ASM サービスです。機能の一覧は 機能紹介 に、導入の相談は お問い合わせ にあります。実際の発見プロセスは 14日間無料で試せます。
付録：型と対象の詳しい表
表3：10の型の触り方と、届く対象
| # | 構える場所とカテゴリ | どう触るか | 届く先 |
|---|---|---|---|
| ① | 経路（関所）／ SWG・CASB | 通信に割り込み、中身を見る | A/B |
| ② | 端末とツールの扉（門番）／ EDR・ブラウザ拡張 | 送信や呼び出しの直前で捕まえる | A/B |
| ③ | テナントの中（監査役）／ SaaS 側のポスチャ管理 | 別の会社の製品が、SaaS のテナントに API で入って設定と権限と履歴を読む | A/C |
| ④ | ログ（録画）／ SIEM・UEBA | 取り込んで事後に異常を見つける | A/C/D |
| ⑤ | ID 基盤（受付）／ IDaaS・IGA・PAM | 誰が何に入れるかを決め、権限を棚卸しし、資格情報を仲介する | A/C/D |
| ⑥ | プラットフォーム自身（大家）／ クラウド事業者の内蔵機能 | クラウドや SaaS の提供元が、自社の製品に ID・データ保護・検知を内蔵する | A/C |
| ⑦ | アプリの中（建材）／ ガードレール SDK | アプリの処理の中にライブラリとして入り、外に出ない呼び出しも見る | D |
| ⑧ | 任意のゲートウェイ（自主の関所）／ AI ゲートウェイ | 開発者が自分で立てた通り道に、AI への呼び出しを通す | D |
| ⑨ | クラウド全体（衛星写真）／ CNAPP・AI-SPM | クラウドのアカウントを走査して、AI の資産と過剰な権限を棚卸しする | D |
| ⑩ | モデルとテスト（警護と侵入テスト）／ レッドチーム・モデル検査 | 攻撃して弱点を探す | C/D |
表4：4つの対象のリスクと、自社で確かめられること
| 対象 | 主なリスク | 自社で確かめること | 製品導入のトリガ |
|---|---|---|---|
| A 会社が配った AI | 業務データが外部のサービスへ渡る | 契約している AI と利用者、入れているデータの機微度 | 機微なデータを入れる部署があるのに、入力の検査が一切ない |
| B シャドーAI | 会社が知らないまま社内データが外部へ出て、出た事実も残らない | 経費と請求から拾える個人契約、既存のプロキシや DNS のログ | どれだけあるか分からない。見えない範囲の大きさが分からないこと自体 |
| C クラウド／SaaS の上で動く AIエージェント | 連携許可が広すぎるまま残り、利用者が承認なしに増やせる | テナントの連携許可の一覧。誰が、どのスコープで、全社許可か個人許可か | 連携が手作業で追えない数になっている |
| D 自社アプリに組み込む AIエージェント | 更新や送信ができる AIエージェントが、読ませた文書で動かされる | 権限の一覧、承認の有無、記録の有無 | 書き込み権限があるのに、承認も記録もない |
