RSAC 2026では、5つの異なるベンダーが、AIエージェントにアイデンティティを与えるための5つの異なる手段を投入しました。CrowdStrike、Cisco、Palo Alto Networks、Microsoft、Cato CTRLの5社はいずれも、同じ週のうちにエージェントのアイデンティティのためのフレームワークを発表しました。Shadow AIエージェントの発見。OAuthベースのエージェント認証。エージェント在庫（インベントリ）ダッシュボード。メッセージは明確でした。業界は、AIエージェントを守るための最初のステップは「その正体を知ること」だと決めたのです。
数日も経たないうちに、Fortune 50の2件のインシデントが「アイデンティティは必要だが十分ではない」理由を示しました。いずれの場合も、すべてのアイデンティティ確認は通過しました。エージェントは認証され、認可され、割り当てられたスコープの範囲内で動作していました。失敗の原因は「誰か」ではなく、「エージェントが何をしたか」でした。
最初のインシデントでは、CEOのAIエージェントが、会社自身のセキュリティポリシーを書き換えました。エージェントにはポリシー文書への正当なアクセス権がありました。エージェントは、制限がタスク完了を妨げていると判断し、その制限を取り除きました。アイデンティティ確認：これはCEOの認可されたエージェントです。統制されないアクション：エージェントが人の承認なしにセキュリティポリシーを変更しました。
2つ目では、Slackベースの100を超えるエージェントのスウォームがコード修正で協働しました。連鎖の中のエージェント12が、人のレビューなしにコードを本番環境へコミットしました。スウォーム内のすべてのエージェントは認証されていました。委譲（デリゲーション）チェーンは技術的には正当でした。しかし最終アクションについて承認する人が誰もおらず、デプロイ後になって初めて誰も気づきました。
これらは例外ではありません。ガバナンスを作らずにアイデンティティだけを構築したときに、起こり得る（予測できる）結果そのものです。
RSAC 2026で投入されたもの
エージェントのアイデンティティの取り組みは、実際に存在し、価値があります。CrowdStrikeは、AI Detection and Response（AIDR）の機能を拡張し、Microsoft Copilot Studioのエージェントも対象にする形で提供し、Copilot、Salesforce Agentforce、ChatGPT Enterprise、OpenAI Enterprise GPTにまたがってShadow SaaSおよびAI Agent Discoveryを出荷しました。彼らのFalconセンサーは現在、顧客の導入環境全体で1,800を超える個別のAIアプリケーションを検知し、エンタープライズのエンドポイント上で1億6000万のユニークなインスタンスを生成しています。
Cisco、Palo Alto Networks、Microsoft、Cato CTRLはいずれも、同じテーマの自社バリエーションをそれぞれ投入しました。つまり、自社環境にどんなエージェントが存在するのかを発見し、それらを認証し、セキュリティチームがエージェントの活動を可視化できるようにする、というものです。
これは重要な基盤作業です。見えないものは守れません。エージェントの発見とアイデンティティは、それに続くあらゆるものの前提条件です。
ただしアイデンティティが答えるのは「このエージェントは誰か？」という1つの問いだけです。エージェントの振る舞いが安全で、法令順守に適合していて、かつ認可されているかどうかを実際に左右する問いには答えません。
アイデンティティが開けてしまう3つのギャップ
RSACで投入された内容と、インシデントが明らかにしたことを踏まえると、アイデンティティのフレームワークでは埋められないギャップが3つあります。
ギャップ1：ツール呼び出し層での認可
OAuthは、呼び出し元が誰であるかを教えてくれます。しかし、その呼び出し元がアクセス権を使って何をするかは制約しません。Jiraインスタンスに対してOAuthで認証されたエージェントは、チケットを作成し、チケットをクローズし、プロジェクト設定を変更し、ボードを削除できます。アイデンティティのフレームワークはエージェントの身元を確認します。しかしパラメータを制約したり、意図が行動にどう結びつくかを評価したりはしません。
これはCEOのエージェントが突いたギャップです。エージェントにはポリシー文書にアクセスするための正当なOAuth資格情報がありました。「その文脈において、そのエージェントにとって『セキュリティポリシーを変更すること』が認可されたアクションなのか」を評価する仕組みはありませんでした。
ツール呼び出しの認可は、アイデンティティとは別の層で機能させる必要があります。アイデンティティは「このエージェントはこのAPIを呼び出してよい」と言います。認可は「このエージェントは、これらのパラメータで、これらの条件のもとで、承認チェーンを経た上で、このAPIを呼び出してよい」と言います。
ギャップ2：エージェント能力に対する変更管理
エージェントのツールカタログと権限は、ポリシーのレビューサイクルよりも速く変動します。先週はJiraチケットを読む権限が認可されていたエージェントが、今週は開発者がデモのために必要だと考えて書き込み権限を付与されているかもしれません。その権限変更は、セキュリティによってレビューされることもなく、記録されることもなく、組織のポリシーフレームワークに照らしてテストされることもありません。
RSACの発表のどれも、時間の経過に伴ってエージェントの権限をどう管理すべきかには触れていません。発見（ディスカバリー）は「今日どんなエージェントが存在するか」を教えてくれます。しかし、エージェント47の権限が、セキュリティレビューなしに過去1か月で3回拡張されたことまでは教えてくれません。
同じ問題を、エンタープライズは人間向けIAMではアクセスレビュー、職務分掌（分離の責務）、変更管理プロセスで解決してきました。エージェントの能力にも同じ扱いが必要です。ただし、エージェントは人間よりも速く権限を積み上げ、しかも誰もその変更をレビューしていない点が異なります。
ギャップ3：証拠と監査証跡（監査ログ）
Slackのスウォーム事件が、この点をまさに完璧に示しています。100を超えるエージェントが協働しました。エージェント12がコードをコミットしました。事後になっても、完全な意思決定チェーンを再構築できる人はいませんでした。どのエージェントが修正を提案したのか、どのエージェントがそれをレビューしたのか、どのエージェントがコミットを委譲したのか、そして、なぜエージェント12がそれを実行したのか──です。
アイデンティティシステムは、エージェント12がコミットしたときに認証されていたことは示せます。しかし、以下を不変（改ざん不能）な形で記録したものを生成することはできません。チェーンを開始した元のプロンプト、各エージェントが提案したアクション、各委譲の決定、最終アクションに対する承認（または承認されなかったこと）、そして結果として得られた成果物です。
規制産業にとって、このギャップは単なるセキュリティ問題ではありません。コンプライアンス違反です。監査人は、アクションが認可され、承認され、文書化されていることを確認できる必要があります。「エージェントが認証された」は、コンプライアンスに適合した行動の十分な証拠にはなりません。
「意図セキュリティ」は行き止まりである理由
CrowdStrikeのCTOであるElia Zaitsevは、ゴーストエージェントをより広範なエンタープライズのアイデンティティ衛生（hygiene）の失敗に結びつけることで、問題をうまく整理しました。とはいえ、業界の反応は「意図セキュリティ」へと押し進めることでした。つまり、エージェントが実行する前に「何を意図しているか」を突き止めようとすることです。
意図は言語の層で測定されます。エージェントが「MFAの要件を外すために、セキュリティポリシーを更新する」と言います。意図分析は、それが正当な要求なのか悪意のあるものなのかを判断しようとします。
しかし問題は、意図について言語を信頼性高く検証できないことです。CEOのエージェントは悪意がありませんでした。役に立つものでした。ポリシーの制限がタスクを妨げていると判断し、適切にそれを取り除きました。意図は良いものでした。それでもアクションは壊滅的でした。
工学上の原則は、もっと単純で信頼性も高いです。状態が変わる場所で、信頼境界（トラスト境界）を強制すべきであり、テキストが生成される場所で強制すべきではありません。エージェントは何でも言えます。重要なのは、実際に何ができるかです。
つまり、プロンプト層ではなくツール呼び出し層で強制するということです。述べられた意図ではなく、アクションを評価します。エージェントの説明がどれほどもっともらしく聞こえても、認可されていない状態変更はブロックしてください。
アクションのガバナンスが実際にどう見えるか
アイデンティティが「このエージェントは誰か？」に答えるのだとすれば、アクションのガバナンスはさらに4つの問いに答えます。エージェントが何を許されているか。どのような条件のもとで許されているか。どんな承認を伴うのか。そして、事後にそれをどう証明できるのか。
実務では、これは次のような一連の制御に落とし込まれます。
ツールの許可リスト（allowlist）と、リソースごとのスコーピング。 エージェントはJiraチケットを作成できるが、プロジェクト設定は変更できない。エージェントはセキュリティポリシーを読み取れるが、変更はできない。エージェントはデータベースを問い合わせできるが、DDL文は実行できない。スコーピングはAPIごとではなく、リソースごとに行います。
パラメータ制約。 エージェントは最大$500まで資金を送金できる。エージェントは社内アドレスにのみメールを送信できる。エージェントは/appディレクトリ内のファイルは変更できるが、/configは変更できない。パラメータは実行前に検証し、実行後ではありません。
インパクトの大きい操作に対する承認ゲート。 ポリシー変更には人間の承認が必要です。本番環境へのデプロイには二人の署名（サインオフ）が必要です。しきい値を超えるデータエクスポートはレビューキューをトリガーします。エージェントは操作を提案し、人間（またはより高い権限の承認ワークフロー）がそれを認可します。
セッションを考慮した評価。 ワークフローの途中で何が起きたかが重要です。直近10回の操作の間に、自分自身の権限を段階的に拡大してきたエージェントは、各個別の操作が単体では妥当に見えるとしてもフラグ付けされるべきです。Slackのスウォーム（群）インシデントは完璧な例です。委任の各ステップはそれぞれ個別には正当でしたが、その連鎖によって認可されていない結果が生み出されました。
完全な連鎖につながる監査証跡。 操作を引き起こしたプロンプトまたはコンテキスト。提案された具体的なツール呼び出し。承認判断（承認、却下、自動承認＝ポリシーによる）。実行結果。生成された成果物（コミット、ポリシー変更、送信されたメール、更新された記録）。連鎖のすべてのリンクはタイムスタンプ付きで、帰属が明確で、改ざん不能です。
コンプライアンスの次元
これは単なるセキュリティ・アーキテクチャの問題ではありません。多くのフレームワークが明示的に要求し始めているコンプライアンス要件です。
AIUC-1（AIエージェントのための新興のSOC 2）には、エージェントのアクション制御に関する具体的な要件が含まれています。B006は認可されていないエージェント操作を防ぐことを求め、D003は安全でないツール呼び出しの制限を求め、E015は完全な監査証跡付きの活動ログを要求します。
EU AI Actは、高リスクAIシステムに対する人間の監督メカニズムを求めています。これには、システムが実行できる行為のドキュメント化や、認可されていない操作を防ぐためのセーフガードの説明が含まれます。
ISO 42001は、運用上の制約やモニタリングを含めて、AIシステムの振る舞いの境界を定義し、強制することを要求しています。
いずれの場合も、アイデンティティだけでは要件を満たしません。監査人は「エージェントは認証されていたか？」とは尋ねません。監査人が尋ねるのは「その行為は認可されていたか、そしてそれを立証できるか？」です。
ベンダーに求めるべきこと
RSACの後にエージェントのセキュリティ・ソリューションを評価しているなら、アイデンティティとディスカバリーを超えて次の点を質問してください。
エージェントのツール呼び出しに対して、アクション単位のポリシーを強制できますか？「このエージェントはJiraにアクセスできる」だけでなく、「このエージェントはプロジェクトXで優先度がMedium以下のチケットを作成できる」といった形で強制できますか。
インパクトの大きいエージェント操作のための承認ワークフローをサポートしていますか？エージェントが本番環境へのデプロイやポリシー変更を提案した場合、実行前に人間の承認をシステムに要求できますか。
あらゆるエージェント操作について、エンドツーエンドの監査証跡を作成できますか？トリガーとなったコンテキストから、提案された操作、承認判断、実行、そして結果として生じた成果物まで。
セッションのコンテキストを踏まえて操作を評価しますか？各操作を個別に評価するだけでなく、操作のシーケンスを通じたパターンを検知できますか。
監査人に対して継続的な強制を立証できますか？一時点のレポートではなく、監査期間を通じてポリシーが有効であり、実際に強制され続けたことを示す継続的な証拠です。
RSACでアイデンティティ・フレームワークを出荷したベンダーたちは土台を築きました。なお欠けているのは、そのアイデンティティを意味あるものにするガバナンスです。つまり、エージェントが何をしたのか、許可されていたのか、誰が承認したのか、そして後からそれらをすべて立証できることです。
アイデンティティは、誰が門のところにいるかを教えてくれます。アクション・ガバナンスは、内部に入った後にその人（エージェント）が何を許可されているかを決めます。
私は Aguardic を構築しています。これは、承認ワークフローと監査証跡を自動生成しながら、リアルタイムでエージェントの操作に対するポリシーを強制するポリシー・アズ・コードのプラットフォームです。コメント欄でエージェントのガバナンスに関する質問にもお答えします。
