【Identiverse 2026レポート前編】AI時代の認可基盤「アクセスからアクションへ」のパラダイムシフト

世界最大規模のアイデンティティカンファレンス「Identiverse 2026」が2026年6月15日から18日にかけて米国ラスベガスで開催されました。約4,000人のプロフェッショナルが集結した今年の最大の焦点は、急激に普及するAIエージェントへの適切な権限付与とそれを支えるリアルタイムな認可アーキテクチャ、そしてAI攻撃や量子コンピュータといった新たな脅威でした。

現地で体感したID業界の潮流と、これから私たちのビジネスやセキュリティがどう変わっていくのか、最先端のトレンドを凝縮したレポートの前編です。

Identiverse 2026 とは

Identiverseは、毎年米国で開催されている世界最大規模のデジタルアイデンティティ専門カンファレンスです。Identiverse 2026には4,000人以上の参加者、250人以上のスピーカーが集まりました。

昨年のIdentiverse 2025では、Artificial IdentityとNon-Human Identity（NHI：非人間アイデンティティ）が主要なアイデンティティ領域として整理されていました。AIについては、ディープフェイク、サイバー攻撃の軍拡競争、データの出所や著作権、信頼性と委任が課題として挙げられ、NHIについても可視性や委任の連鎖、大規模化への対応が論点になっていました。また、AIエージェント向けID管理のセッションでは、LLMの暴走（Excessive Agency）に対応するためのきめ細かいアクセス制御、権限管理、最小限の権限委譲、AIエージェントごとのID一意識別などの重要性が取り上げられました。一方で、具体的なエージェント同士の認可まで踏み込んだセッションは限られ、OAuth 2.0に対応できるAIツールもまだ少ないと報告されていました。また、ExpoにNHI専用エリアが設けられるなど注目は高まっていたものの、NHIやAIエージェントの管理モデルは、まだ実装・標準化が広く成熟した段階ではありませんでした。

2026年は、これらの議論が具体的な認可アーキテクチャや標準化、運用上の課題へ移っています。AIエージェントの権限を「アクセス」ではなく「アクション」単位で評価する実行時アイデンティティ、常時特権を持たせないZero Standing Privilege（ZSP）、PEP/PDP間の認可判断を標準化するAuthZEN、MCPにおけるツール呼び出しの認可、そしてShared Signals Framework（SSF）を用いたContinuous Identityが、カンファレンス全体を通じた重要テーマとして取り上げられました。

本稿では、Identiverse 2026のセッションから主要なトピックを前編・後編に分けてレポートします。
まず、前編では、AIエージェントへの適切な権限付与と動的なアクセス制御を中心に、実行時アイデンティティ、ZSP、AuthZENの最新動向をご紹介します。

カンファレンス会場の様子

Identiverse 2026セッション紹介

キーノート：Actions, Not Access: The Shift to Runtime Identity with Andre Durand
（アクセスからアクションへ：ランタイム・アイデンティティへの転換）

登壇者：Andre Durand（Ping Identity）

概要

AIエージェントが認証後も高速かつ連続的に処理を進める環境では、一度アクセスを許可した後のセッションを信頼し続ける従来のアイデンティティモデルでは、意図しない行動を実行前に止められないことが指摘されました。本基調講演では、制御の単位をアクセスからアクションへ移し、実行時に継続判断する実行時アイデンティティが提唱されました。権限の範囲と保持時間を最小化し、委譲された権限を明示的に制御することで、検証可能なアクションへ導く構想が示されました。

従来のアイデンティティ基盤によるアクセス制御の限界

従来のアイデンティティ基盤は、次の二つのゲートを中心に構築されてきたと説明されました。

• アイデンティティ管理（Identity Management）：「誰が存在するか」
• 認証（Authentication）：「誰を中へ入れるか」

このモデルは、人間が予測可能な速度でアプリケーションを操作する環境では、一定の効果を発揮するとされました。しかし、認証に成功した後はセッションや付与済みの権限が信頼されるため、アクセス後に状況やリスクが変化しても、次の行動を実行前に評価できないという課題が示されました。

AIエージェントは複数のアプリケーション、API、データを横断し、人間の約8.3倍の速さで処理を実行し、かつ処理中にコンテキストやリスクが変化するとされました。そのため、一つの認証や長期間有効なトークンが過剰な権限を持つと、誤動作や侵害の影響も短時間で拡大すると指摘されました。

そこで、信頼（Trust）を与えるための制御単位を、暗黙的な信頼（Implied Trust）から明示的な信頼（Explicit Trust）、さらに検証された信頼（Verified trust）へと順次移行する必要があるとされました。

アクセスではなくアクションを判断単位にする

実行時アイデンティティ（Runtime Identity）において最も重要な問いは、「あなたは誰か（Who you are）」ではなく、「このアクションは承認されるべきか？（Should this action be approved?）」であると説明されました。

認証済みであることは必要条件とされますが、それだけで後続の操作は許可されません。アクションの実行直前に、次の要素を評価する考え方が示されました。

• 状況（Context）：誰が、どの環境から、何を実行しようとしているかが確認されます。

• 方針（Policy）：対象の操作が、定められた権限や条件を満たしているかが判定されます。

• リスク（Risk）：直前までの行動や異常の兆候を踏まえ、許可できる状態かが評価されます。

   

これにより、認可（Authorization）はログイン時の一度限りのイベントではなく、継続的認可（Continuous Authorization）を通じた信頼の継続的な評価（Continuous Evaluation of Trust）へ変わるとされました。

問題があるアクションの一つ手前で判断できれば、次のアクションを最後のアクションにできると説明されました。AIエージェントの世界における実行時アイデンティティでは、「あなたは次のアクションの瞬間までしか信頼されない。」そして「あなたの次のアクションが、あなたの最後のアクションになるかもしれない。」と説明されました。

Zero Trustへの移行：必要十分かつ必要時のみの権限で影響範囲を縮小する

講演では、侵害が発生した際のリスクの総量である「爆風ゾーン（Blast Zone）」または「爆風半径（Blast Radius）」を、AIに与えられた権限の広さである「表面積（Surface Area）」と、その権限が有効な時間である「露出時間（Exposure Time）」の積として捉える考え方が示されました。

AIエージェントが超高速（人間の8.3倍のスピード）で自律動作する環境においては、この2つの次元の双方を極限まで小さくすることが不可欠であるとされ、影響範囲の抑え込みが可能なAIエージェント環境におけるゼロトラスト（Zero Trust）という目的地へ到達するために、以下の原則が提示されました。

これら原則に従い、実行時にリアルタイムで継続評価する「実行時決定ゲート（Runtime Decision Gate）」を構築することで、AIエージェントのスピードを活かしながらも、企業の安全性を担保するモデルが示されました。

検証済みの信頼を検証可能なアクションへつなげる

実行時の判断に必要な検証済みの信頼（Verified Trust）を確立するため、従来の技術カテゴリを融合させる方向性が示されました。具体的には、以下の3つの仕組みを連携させると説明されました。

• 本人性の検証（Identity Verification）：行動主体が真に本人であるかを証明する
• アクセス管理（Access Management）：対象のリソースへの到達を制御する
• 不正検知（Fraud Detection）：行動や取引に不正の兆候がないかを評価する

これらが融合することで、まずは前提条件としての検証済みの信頼が確立されるとしています。

さらに、このような仕組みの連携によって実現したいことは、人間に適用される「検証済みの信頼（Human Verified Trust）」と、マシンに適用される「検証されたアクション（Agentic Verified Action）」を、アクションごとの「実行時制御（Runtime Control）」を介して結合し、インフィニティ・ループとして機能させる構想（実行時アイデンティティ管理プレーン（Identity Runtime Control Plane））にあると説明されました。

これは単なるAIエージェント専用の隔離された仕組みではないとされ、入力シグナル（例：人間、AIエージェント、デバイス）と制御対象（例：アプリケーション、API、データ、AIエージェント）を包括的に横断する、企業全体の意思決定および制御基盤として機能すると示されました。

権限の根拠、委任、アクション、そして結果をランタイムで一貫して結びつけ、誰の権限で何が行われ、なぜその瞬間許可されたのかをいつでも検証・説明できる状態を作ることこそが、AI時代におけるアイデンティティ管理に課された新たなミッションであると結論づけられました。

筆者所感

本基調講演で印象的だったことは、アイデンティティの責任範囲を入口から実行時へ広げる転換が示された点です。アクセスを許可した事実と、その後のアクションを許可できることは同じではありません。この違いをAIエージェントが利用するアイデンティティ管理基盤において設計として組み込む必要があると感じました。

関連基調講演においても、この実行時制御（Runtime Control）を支える重要な補完的論点が提示されました。

まず2日目の基調講演 "The Three Identity Problem: Surviving the Chaotic Era" にてPritchard氏は、人間→AIエージェント→非人間アイデンティティへと権限が流れていく構造を「制御不能な継承チェーン（Uncontrolled Inheritance Chain）」と呼び、これに対して単なる可視性（Visibility）ではなく、因果関係を捉える可観測性（Observability）が必要であると主張しました。

また、3日目の基調講演 "The New Frontier of Identity Security for AI" にてNayar氏とFarshchi氏は、アイデンティティ統制を開発の初期段階に組み込む「Shift Left」への移行の必要性や、非人間アイデンティティを「第一級の市民（First-class citizens / First-class Identity）」として包括的に管理すべきであるという旨を述べられていました。

今後は、アイデンティティ管理基盤にアクション（業務内容、操作内容等）をリアルタイムに評価する機能を整備するとともに、人間の意図から実行、そして検証・説明責任までを一貫して追跡できる「実行時アイデンティティ」の全体設計が、AI時代の安全なビジネス推進にとって重要になるでしょう。

セッション：Governing Non‑Human Identity for AI Agents in CIAM
（CIAMにおけるAIエージェントの「非人間アイデンティティ」としてのガバナンス）

登壇者：Manikandan Rajaram（Capital One）  
登壇者：Anji Yalla（Capital One）

概要

顧客の代わりに住所変更や返金、プラン変更、決済などを行うAIエージェントが普及する中、従来のCIAMで用いられてきた長期的な認証情報や粗い権限では、不正利用時の影響を抑えられないことが指摘されました。本セッションでは、AIエージェントを独立した非人間アイデンティティ（NHI, Non-Human Identity）として管理し、常時権限を持たせない常時特権の排除（ZSP, Zero Standing Privilege）の適用モデルが紹介されました。顧客の同意、目的と有効期間を限定した権限、継続的なリスク評価、送信者制約、監査証跡を組み合わせ、安全性とユーザー体験を両立するための参照アーキテクチャと段階的な導入方法が示されました。

AIエージェントを独立したNHIとして管理する

従来のCIAMは、認証された人間が画面を操作し、予測可能な頻度でサービスへアクセスすることを前提としてきました。一方、AIエージェントは顧客に代わって複数のAPIやツールへ連続的にアクセスし、人間よりも速く、ときには予測しにくい形で処理を進めます。顧客の認証情報や長期間有効なAPIキーをそのまま渡した場合、プロンプトインジェクション、悪意のある拡張機能、トークンのリプレイなどを起点として、アカウント侵害や意図しない取引へ発展する可能性があります。

そのため、AIエージェントを「顧客本人」や「APIキーを持つインテグレーション」として扱うのではなく、CIAM上で独立して識別できるNHIとして扱う必要があると説明されました。各エージェントについて、所有者、利用目的、ライフサイクル、期待される振る舞いを登録し、誰の委任を受けて何を実行したかを追跡できる状態が求められます。人間と同じCIAMのポリシー基盤を利用しながら、自律性によって増大するリスクに合わせて、より細かな制御を加える必要性が示されました。

常時特権の排除（Zero Standing Privilege）を支える4つの原則

この課題に対する制御モデルとして、ZSPが提示されました。ZSPは、AIエージェントに権限を一切与えないという意味ではありません。エージェントが正当な目的のために必要とする権限を、必要な対象と期間に限って付与し、それ以外の権限を常時保持させない考え方として説明されました。また、暗黙的な許可をなくし、例外も含めてすべての判断を記録することが基本とされました。

ZSPを構成する原則として、次の4点が挙げられました。

• 常時特権を持たせない（No Standing Privilege）：デフォルトの管理権限を与えず、タスク単位で権限を昇格させます。
• 必要時アクセス（Just-in-Time Access）：要求が発生した時点で、対象、操作、有効期間を限定した権限を発行します。
• 継続的認可（Continuous Authorization）：APIリクエストごとに同意、コンテキスト、行動、リスクを再評価します。
• 送信者制約（Sender-Constrained）：mTLSやDPoPを用いてトークンを特定のエージェントが持つ鍵に結びつけ、盗まれたトークンの再利用を難しくします。

これらを組み合わせることで、一つの侵害が広範な操作へ波及するリスクが抑えられると説明されました。

顧客の同意からAPI実行までを一貫して制御する

セッションでは、AIエージェントが顧客の住所を変更する例を用いて、ZSPの具体的な流れが説明されました。最初に、顧客が目的や条件を含む明示的な同意を与えます。AIエージェントはAPIを呼び出す前に、ワークロードアイデンティティ（Workload Identity）とTLSによる構成証明（Attestation）によって認証されたのち「特定顧客の住所変更を5分以内に行う」といったタスクに限定されたジャストインタイム（JIT, Just-in-Time）の権限を要求します。認可サーバーは、目的と有効期間を限定し、送信者制約（Sender-Constrained）を付けた短寿命トークンを発行します。住所変更のように不正リスクが高い操作では、顧客本人によるステップアップ認証と取引確認も求められます。つまり、人間関与（Human-in-the-loop）がプロセスに組み込まれるのです。

各APIへの要求はポリシー執行点（PEP, Policy Enforcement Point）で受け止められ、ポリシー決定点（PDP, Policy Decision Point）によって、同意の有無、要求された操作、リアルタイムのリスクシグナルが評価されます。トークン発行後も、APIログ、エージェントの処理フロー、行動テレメトリが継続的に監視され、異常があればトークンを速やかに失効させる構成が示されました。さらに、誰が何を承認し、どのエージェントが、何の目的で、どの操作を行ったかが、改ざん困難な監査証跡として残されます。認証、認可、実行、失効、監査を一連の制御として設計することで、利便性を維持しながら説明責任が確保されると説明されました。本セッションにてこれは続的なリスク評価（Continuous Risk Assessment）継続的な検証（Continuous Verification）と説明されていました。

NHIの棚卸しから始める段階的な導入

ZSPを一度に完成させるのではなく、各段階でリスクを減らしながら成熟させるロードマップが示されました。全体像は次のとおりです。

(※)セッションでは、第1ステップを0～90日、第2ステップを90日～180日、第3ステップを180日～365日で実施するロードマップが示されました。

第1ステップでは、AIエージェント、Bot、サービスアカウント、外部クライアントなどのNHIを棚卸しし、それぞれの所有者と用途を明確にすることが推奨されました。可能な範囲で長期間有効なクレデンシャルを短寿命トークンへ置き換え、CIAM APIの前段に一貫した認可を実行するPEPを配置する方針が示されました。

第2ステップでは、目的に応じたスコープ、金額の上限、承認条件などをコードとしてのポリシー（Policy as Code）として定義する方針が示されました。あわせてmTLS／DPoPによる送信者制約を導入し、トークン、API、ツール呼び出しを追跡するアイデンティティ・テレメトリ（Identity Telemetry）の整備が推奨されました。

第3ステップでは、プロビジョニングや権限レビューを含むライフサイクル管理を自動化し、端末、行動、不正検知などのシグナルを用いた継続的認可へ拡張するとされています。さらに、エージェントのワークフローをレッドチームで検証し、規制対応に利用できる証拠を整備することが示されました。このロードマップは完成済みの導入事例ではなく、組織がZSPへ移行するための実践的な指針として提示されたものです。

筆者所感

本セッションで重要と感じたことは、既存のアクセス制御原則を、CIAMにおけるAIエージェントのふるまいベースで再構成した点です。導入の起点をNHIの棚卸し、所有者の明確化、長寿命シークレットの削減、API境界でのポリシー執行としていることも、実務的なアプローチだと感じました。

また、前述した基調講演「Actions, Not Access」にて提唱された、アクション（Action）を実行時に判断する実行時アイデンティティ（Runtime Identity）への転換は、ZSPアーキテクチャにおいて以下のように具体化されていると捉えられます。

また上記の組合せによるZSPアーキテクチャによって、基調講演「Actions, Not Access」にて提示された「爆風半径 ＝ 表面積（Surface Area） ✕ 露出時間（Exposure Time）」という概念モデルを以下のように具現化しています。

• 「表面積（Surface Area）」の極小化
  「No Standing Privilege」と「RAR」の組合せによって、万が一の侵害時における攻撃対象領域を最小化
• 「露出時間（Exposure Time）」の極小化
  「JIT」と「短寿命トークン（TTL ≦ 5分）」の組合せによって、露出時間をAIエージェント向けに最小化
• 「実行時決定ゲート（Runtime Decision Gate）」の具現化
  ZSPにおける PEP（ポリシー執行点） と PDP（ポリシー決定点）による、継続的なリスク評価と検証の仕組み

このように、基調講演が提示した概念的なゼロトラスト原則は、CIAMにおけるAIエージェント向けのアーキテクチャとして紹介されたZSPの原則と対応付けることができ、AIエージェント向けCIAMの目指すべき全体像が示されたように感じました。

セッション：AuthZEN Deep Dive: Mastering the OpenID Authorization Standard
（AuthZEN 深堀り：OpenID 認可標準をマスターする）

登壇者：Alex Olivier (Cerbos)
登壇者：Atul Tulshibagwale (CrowdStrike)
登壇者：Mark Berg (Axiomatics)

概要

本セッションは、アプリケーションやサービス、自律型AIシステムから認可ロジックを完全に分離し、ランタイム契約として一貫してデプロイするためのロードマップを示すものです。
その核心となるのが、PEP と PDP 間の通信を標準化する「AuthZEN API 1.0」、AIエージェントの安全なツール呼び出し (MCP) を制御する「COAZ (Co-AuthZEN) プロファイル」、そして非同期なHuman-in-the-loop ワークフローをガバナンスポリシーの枠組みで標準化する最新仕様「AARP (AuthZEN Access Request and Approval Profile)」 の3要素です^[1]。
これらの仕様により、きめ細やかな認可の標準仕様だけでなく、従来の「即時OK/NG判定」を超えた「非同期かつ動的な段階的認可ライフサイクル」が確立されることになります。

認可基本モデル (AuthZEN API 1.0) とハイブリッド属性設計

AuthZEN の核心は、認可に必要なコンテキストを定義する SARC (Subject, Action, Resource, Context) 情報モデルです。
PEP-push と PDP-resolve の双方に対応しています。

• PEP-push型
  • PEP 側で JWT のクレーム等から事前に属性情報を抽出し、properties オブジェクトに格納して送信する。
  • 低遅延だが、認可ポリシーの整合性が損なわれるリスクあり。
• PDP-resolve型

• • PEP からは最低限の識別子 (ID) のみを送信し、PDP 側が属性ストア (PIP : Policy Information Point) やデータベースから最新のメタデータを動的に取得する。
  • 常に最新のデータで評価を行うが、レイテンシーが肥大しやすい。

これにより、データ整合性 (リアルタイム性) とネットワーク遅延 (レイテンシー) のトレードオフに応じた柔軟なシステムトポロジーを設計できます。

PEP-PDP 間の通信においては、プロトコル上のエラー (Malformed JSON など) は HTTP 4xx/5xx 等のトランスポート層で返し、PDP (認可エンジン) がポリシーを正しく評価した結果としての拒否 (decision: false) は HTTP 200 OK のペイロード内で返す「トランスポート層とペイロード層のデカップリング設計」を徹底しています。 
これにより、ポリシー起因のアクセス拒否と、システム故障 (通信エラー等) によるフォールバック処理を PEP 側で安全かつ明確に区別して制御できます。

Batch 評価セマンティクスと逆引き Search API

大規模環境における性能要件をクリアするため、AuthZEN は単一評価 (/access/v1/evaluation) だけでなく、バルク処理および探索クエリの API を標準化しています。

① バッチ評価 (/access/v1/evaluations) とマージ仕様

同一リクエスト内で複数の認可を評価する際、トップレベルに共通の subject や context を定義し、配列 (evaluations) の各要素内では変化する resource や action のみを記述するマージ仕様を採用、リクエストペイロードを削減します。

② 評価セマンティクス (evaluations_semantic) の制御

PDP に対して以下を使い分けが可能です。

• execute_all (デフォルト)

  • 配列で渡されたすべての評価結果を個別に応答。

  • UI のメニュー表示可否などのレンダリング処理に最適。

• deny_on_first_deny

  •  AND (論理積) の評価。どれか1つでも Deny が発生した時点で以降の評価をショートサーキット (打ち切り) して即座に終了。

  • 事前チェック (Pre-flight) の効率化に貢献。

• permit_on_first_permit

  •  OR (論理和) の評価。どれか1つのポリシーパスが Permit を返した時点で評価を確定。

③ 3つの逆引き Search API (/search/)

認可ポリシーのデータ構造に基づき、以下の3つのエンドポイントによる逆引き検索 (リソースフィルタリング、データフェッチ) が可能です。
特に /search/resource は、アプリケーションがデータベースからレコードを取得する前に、PDP からフィルタリング用IDリストを取得して SQL の IN 句などに動的にマップすることで、大量データの不適切なメモリ展開 (メモリ上でのフィルタリング) を防ぎます。

• /search/subject
  対象 resource と action から、実行可能な subject (プリンシパル一覧) を検索。
• /search/resource
  subject と action から、アクセス可能な resource 一覧 (IDの配列) を検索。
• /search/action
  subject と対象 resource から、実行可能な action 一覧 (権限セット) を検索。

LLM/MCP エコシステムにおける「COAZ」プロファイル

AIエージェントが自律的に外部ツール (API) を実行する MCP (Model Context Protocol) において、従来の OAuth スコープでは、エージェントが生成する「引数 (arguments)」の正当性や不正なアクセス先を動的に制限できません。
これを解決するのが COAZ (Co-AuthZEN) プロファイルです。

① 宣言的マッピングと CEL (Common Expression Language) による動的変換

MCP Server は、ツールの一覧 (tools/list) を返す際、JSON Schema 仕様 (inputSchema) の拡張フィールドとして x-coaz-mapping メタデータを埋め込みます。
このマッピング情報に基づき、実際にエージェントがツールを呼び出した (tools/call) 段階で、MCP Gateway (または Server に実装された PEP) が CEL (Common Expression Language) をインタープリタとして動かします。
これにより、以下の JWT クレーム (トークン情報) とツールの引数 (ペイロード情報) を動的にバインドし、AuthZEN 標準リクエストへと変換して PDP へ問い合わせます。

• Resource ID
  params.arguments.id から動的に抽出。
• Subject
  token.sub (ユーザーのID) をマッピング。
• Context
  token.client_id (エージェント自身の識別子) や params.arguments.case (案件番号) など。

② セキュリティバウンダリの確立

「認可チェック時に評価されるパラメータ」と「実際にツールに渡されて実行されるパラメータ」が同一オブジェクト (params.arguments) から抽出されるため、チェック時と実行時のパラメータの隙を突く攻撃や、プロンプトインジェクションによる引数の書き換え攻撃をゲートウェイレベルで遮断できます。
また、エージェントに対して最初から過剰な永続的権限 (高い予算上限など) を与える必要がなくなり、「最小特権の原則 (Least Privilege)」を保ちながら、必要な時だけ安全に人間の判断を介在させる「セキュアな自律ワークフロー」が実現します。

非同期ガバナンスを可能にする「AARP」プロファイル

従来の認可システムは、「このアクションは“今すぐ”実行できるか？」という問いに答える、即時型の同期処理のみを前提としていました。
しかし、AIエージェントが自律的に目標を追求する環境下では、一時的にポリシー制限にぶつかった際、非同期に前提条件 (承認など) を解消してタスクを継続できる仕組みが必要になります。
これが AARP (AuthZEN Access Request and Approval Profile) です。
AARPは、認証における CIBA (Client-Initiated Backchannel Authentication) の非同期バックチャネル承認の仕組みを、認可ポリシーのレイヤーへと一般化した画期的なプロファイルです。

① Prerequisites (前提条件) の提示セマンティクス

エージェントが上限額を超える送金などを要求した際、ポリシー評価の結果が「現時点では否認 (False)」であれば PDP は単なる Deny を返すのではなく、AARP 仕様に則り「前提条件 (Prerequisites) 」 (例：特定の役職者による承認、またはステップアップ多要素認証の提示など) をレスポンスの context.access_request 内に格納して返します。

② 非同期アウトオブバンド処理とHuman-in-the-loop

エージェントは即時にエラー終了するのではなく、このリクエストに対する「保留中の追跡ID (handle)」を保存し、プロセスをサスペンド (一時停止) またはバックグラウンド化します。
裏側では、人間の管理者に対して組織既存のガバナンスプラットフォームを通じて「承認要求」が非同期に通知されます。

③ ポリシーを「最終権限 (Ultimate Authority)」とした再評価設計

AARP の最も重要なセキュリティ上の設計原則は、「人間が承認ボタンを押した事実によって、バックエンドシステムが直接バイパスされて実行されるわけではない」という点です。
人間 (または外部のガバナンスエンジン) が行った承認は、あくまで「ポリシーを評価するための『新しいインプット (コンテキスト情報) 』が1つ追加された」という扱いになります。
承認完了を検知したエージェントが、再度同一の AuthZEN リクエスト (承認されたことの証明データや追跡IDを添付) を投げると、PDP は「ポリシー、リクエスト、そして追加された承認コンテキスト」をその実行瞬間の (ランタイムの) ポリシーの定義に則って再評価し、初めて承認します。

筆者所感

今まで「人ありき」で設計されてきた認可は、事前定義されているスコープという粗粒度で制御を行っていました。
AI エージェントの台頭により、予測不可能な動的アクションや暴走、またはインジェクション攻撃を防ぐことが昨今の認可の必須条件となり、必然的に AuthZEN に組み込まれてきたと感じます。
また、AARP などによって最小権限を保ちつつ、過度に利便性を落とさない工夫が見られたと感じています。

セッションの質疑応答では、AI エージェント/MCP 連携における PDP 呼び出しのレイテンシーを問う質問がありました。
回答は、「極めてシビアな性能 (ミリ秒未満のレイテンシー) が要求される場合は、ネットワークをまたぐ中央集権的な PDP の構成を避け、PEP (アプリケーションやサイドカー、APIゲートウェイ) の同一メモリ/同一プロセスにライブラリとして PDP を組み込むアーキテクチャを検討してはどうか」でした。
アーキテクチャや通信については AuthZEN 定義外であり、エンジニアとして設計しがいのある範疇に残っているかなと考えています。

AuthZEN は認可 IF の仕様であり、identiverse 2026 で最大トピックのひとつとして扱われた Continuous Identity のアーキテクチャに応用されています。
後編では、Continuous Identity の中核となる Shared Signals Framework のセッションをご紹介いたします。

おわりに

前編では、AIエージェントの普及に伴う「アクセス制御からアクション制御へ」というパラダイムシフトと、それを支える実行時アイデンティティや認可の標準規格についてご紹介しました。
後編では、リアルタイムID連携（Shared Signals Framework）の導入で直面する運用のリアリティと、次世代のID基盤を脅かす最新セキュリティトレンドを深掘りしてレポートします。あわせてご覧ください。

[1] OpenID Foundation が講演と同日にドラフト承認記事を公開
「OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts」
https://openid.net/openid-foundation-advances-authorization-for-the-agent-era-with-new-authzen-working-group-drafts/