AIエージェントは、多くのセキュリティプログラムが対応できるよりもはるかに速いペースで企業環境に入り込んでいる。

AIエージェントはもはや、質問への回答やコンテンツ生成だけを行う存在ではない。メールの読み取り、SaaSアプリケーションへのアクセス、データベースへのクエリ実行、APIの呼び出し、MCPツールの利用、レコードの変更、ビジネスワークフローの実行まで行える。つまり、AIは「答えを生成する」段階から「アクションを実行する」段階へと移行しているのだ。

CISOやCレベルのリーダーにとって、これはセキュリティの議論の性質を変える。問題は単に「組織がAIを安全に使っているか」ではない。より重要な問いは「すべてのAIエージェントが次の特権的インサイダーになる前に、自信を持って識別・統治・監視・制御できるか」である。

以下は、セキュリティおよびビジネスリーダーが今すぐ問うべき問いだ。

特権的な人間のアイデンティティがなぜリスクになるかを考えてみよう

重要なシステム、機密情報、ビジネスプロセスへのアクセス権を持つから危険なのだ。だからこそ、管理者や特権アカウント、サービスアイデンティティには制御を設けている。

では、Microsoft 365、Salesforce、ServiceNow、クラウド環境、社内データベースに接続されたAIエージェントを考えてみよう。

そのエージェントは、情報の読み取り、意思決定、ツールの呼び出し、システムの変更を—場合によっては数秒で、個々のアクションを誰かが承認することなく—実行できるかもしれない。

エージェントは危険になるために悪意を必要としない。

過剰なアクセス権＋過剰な自律性＋不十分な監視＝インサイダー的リスクが生まれる。

Check Point社はこの変化をわかりやすく表現している。AIエージェントはエンタープライズの「働き手」になりつつある。テキストを生成するだけでなく、データを取得し、認証情報を使い、ツールを呼び出し、APIを叩き、ユーザーやワークフローに代わってタスクを実行する。

従来のIAMだけでは不十分

従来のアイデンティティ・アクセス管理（IAM）が答える問いは「このアイデンティティは何にアクセスできるか」だ。

エージェント型AIはもう一つの問いを強いる。「このエージェントは、このコンテキストで、今この瞬間に、この特定のアクションを実行してよいか」。

あるエージェントが正当に顧客データベースへのアクセス権を持っているとしよう。仕事をするためにREADアクセスが必要かもしれない。しかし、だからといって顧客レコードをDELETEする権限も自動的に与えられるべきだろうか？

おそらくそうではない。

これが「アクセス制御」と「アクション（またはアウトカム）制御」の違いだ。Check Point社はAIエージェントセキュリティモデルをこの区別の上に構築している。エージェント型環境では、セキュリティは「誰がアクセスできるか」という問いではなく「AIが何をしてよいか」という問いになる。理由は単純だ。アクセス権が有効であっても、アウトカムが間違っていることがある。パーミッションチェックをパスしても、その背後のアクションは合理的な運用者が承認しないものかもしれない。

エージェントの操作に明確な境界線を設けるべきだ

例えば、ある企業がシンプルなポリシーを採用するとしよう。「自律型AIエージェントは本番データに対してDELETE操作を行ってはならない」。

エージェントが許可される操作の例：

• CREATE → 許可
• READ → 許可
• UPDATE → 定義された条件下で許可
• DELETE → ブロック、または人間の承認が必要

重要なのは、これをシステムプロンプトに「本番データを削除しないでください」と書くだけでは不十分だということだ。

セキュリティコントロールはエージェントの外部に存在し、技術的に強制される必要がある。エージェントが削除を最善の方法と判断した場合でも、エンタープライズのセキュリティポリシーが最終的な判断を下すべきだ。

Check Point社のWorkforce AI Securityによる実例

Check Point社のWorkforce AI Securityは、MCPサーバーを通じて動作するAIエージェントとそれらに公開されているツールの可視化を提供する。管理者はCreate、Read、Update、Delete（CRUD）に分類されたエージェントの操作を確認し、各ケイパビリティに関連するリスクを分析し、高リスクなツールへのアクセスを制限できる。

より重要なのは、Check Point社のエージェントポリシーフレームワークが自動化されたアクションの制御を明示的に扱っている点だ。Workforce AI Securityの管理者ガイドに示されたコントロールポリシーの例では、ツールまたはCRUD操作のスコープを定義し、AllowまたはBlockアクションを適用する方法を示している。ツール呼び出しが発生した時点では、アクセス制御はすでに「許可」を出している。エージェントは通常、システムが付与する全操作範囲を持つ継承トークンで認証する。アイデンティティの検証は誰が呼び出しているかを確認するが、「なぜ」かは確認できない。エージェントが信頼できないドキュメントやWebページ、ツールの出力を処理している場合、リクエストは運用者から発生していないかもしれない。操作スコープの制御はそれでも機能する。削除ルールは、何がエージェントを削除に誘導したかにかかわらず、削除をブロックする。

これはサイバーセキュリティにおける重要な進化だ。昨日エージェントが何をしたかを観察するだけでなく、アクションが実行される前に許可すべきかどうかを判断する方向へ進んでいる。

なぜランタイムコントロールが重要か

エージェントは素早く動く。次のシーケンスを想像してほしい：従業員 → AIエージェント → モデル → MCPツール → API → DELETE

エージェントは認証済みかもしれない。APIコールは技術的に有効かもしれない。エージェントはユーザーのリクエストを達成するために削除が必要だと判断しているかもしれない。しかし組織のポリシーは「自律型エージェントは本番レコードを削除できない」と定めている。ランタイムセキュリティは、その最終アクションが実行される前のコントロールポイントを提供する。

Check Point社はAIエージェントセキュリティのアプローチとして、プロンプト、モデルの応答、外部コンテンツ、ツール呼び出し、エージェントのアクションをリアルタイムで評価し、安全でない、または許可されていない行動を実行前にブロックするポリシーを適用すると説明している。

これは重要な区別だ。パーミッションはエージェントが何をできるかを定義する。ランタイムポリシーは今それをすべきかどうかを判断する助けになる。

各エージェントのオーナーは誰か

人間だ。

すべての本番エージェントには明確に識別されたオーナーが必要だ。高リスクなエージェントには、ビジネスオーナーと技術オーナーの両方を設けることを推奨する。

ビジネスオーナーが答える問い：このエージェントはなぜ存在し、どのような権限を持つべきか。技術オーナーが答える問い：どのように設定・接続・認証・監視・保護されているか。

エージェントはタスクを自律的に実行できる。しかしアカウンタビリティは自律的であってはならない。識別可能なオーナーのいないエージェントは、最終的には孤立した特権アカウントと同様に扱われるべきだ。

認証だけでは信頼を確立できない

悪意のあるコンテンツがエージェントを操作して正当なツールを呼び出させると仮定しよう。エージェントは有効な認証情報を使って、設計者が意図しなかったアクションを実行する。

認証は機能した。認可も技術的には機能したかもしれない。しかし動作は間違っていた。

Check Point社のAIエージェント保護に関するガイダンスは、プロンプトインジェクション、間接攻撃、機密データの露出、不正なツール使用をコンテキストに応じたランタイム制御が必要なリスクとして挙げている。だからこそ、認証だけでは自律型アイデンティティに対して恒久的な信頼を確立できない。

信頼はダイナミックである必要がある

原則自体は変わらない。適用の仕方が変わる。エージェントの場合、判断はますます次の要素で構成される：

アイデンティティ＋コンテキスト＋データ＋ツール＋要求されたアクション＋動作＝信頼の判断

HRエージェントが10件の従業員レコードを読み取ることは完全に正常かもしれない。同じエージェントが突然2万件のレコードを要求したら、再検討が必要だ。

開発エージェントがコードを書くことは想定内かもしれない。しかし同じエージェントがIAMポリシーを変更しようとする場合、認証に成功したからといって信頼を引き継いであってはならない。

アイデンティティガバナンスをエージェントに適用する

アイデンティティガバナンスのノウハウをエージェントにも適用しよう：

発見 → 登録 → オーナーアサイン → 認証 → 認可 → 監視 → レビュー → 停止 → 廃止

エージェントが作成されたとき、所有権を確立する。アクセス権を受け取るとき、最小権限を適用する。目的が変わったとき、パーミッションを見直す。動作が変わったとき、信頼を再評価する。そしてエージェントが廃止されたとき、認証情報・トークン・APIパーミッション・ツールアクセスを失効させる。

今日の害のないPoC（概念実証）が、明日の忘れ去られた特権アイデンティティになってはならない。

今すぐ確認すべき問い

• 環境内でいくつのエージェントが稼働しているか？
• 各エージェントのオーナーは誰か？
• 機密または特権システムにアクセスできるエージェントはどれか？
• 呼び出せるツールとMCPサーバーは何か？
• 実行できる操作は何か？
• 明示的に禁止されているアクションは何か？
• エージェントの異常な動作を検知できるか？
• 実行前に危険なアクションを止められるか？
• エージェントを即座に無効化できるか？
• 事後に何が起きたかを再構成できるか？

Check Point社のWorkforce AI Securityは、同様の「発見・統治・保護」アプローチに従い、AIアプリケーションとエージェント全体の可視化、粒度の細かいガバナンスポリシー、リスクの高いエージェントアクションに対するランタイムコントロールを提供している。

「最小エージェンシー」という原則

エージェント型AIは単なる別のアプリケーションセキュリティの問題として捉えるべきではない。

Check Point社はこれを明確に述べている。意思決定権限を持つ新しいクラスの非人間アイデンティティを作り出しているのだ。

数十年にわたり、サイバーセキュリティは最小権限の原則で運営されてきた。アイデンティティには仕事に必要なアクセス権だけを与える。

エージェント型AIはもう一歩先を求める。「最小エージェンシー（Least Agency）」と呼べるもの：AIエージェントには認可されたビジネス目的を達成するために必要な自律性だけを与え、それ以上は与えない。

あるアクションは許可される。あるアクションは追加のコンテキストや人間の承認が必要だ。そしてあるアクションは単純に禁止される。

それが、無制限の権限を与えることなく自律型AIの恩恵を得る方法だ。目標はAI導入を遅らせることではない。セキュリティが同じスピードで進化することを確実にすることだ。エージェントがデジタルワークフォースの一部になるにつれ、すべてのCISO・CIO・取締役会が最終的に答えられるべき問いは依然として最もシンプルなものだ：

すべてのAIエージェントが次の特権的インサイダーになる前に、自信を持って識別・統治・監視・制御できるか？

今日の答えが「まだできていない」なら、それがおそらくAIセキュリティ戦略の出発点になる。