AIエージェントが『権限がない』で止まった時、次に何が起きるべきかを標準化する──AuthZENの承認リクエストプロファイルを読む

OpenID AuthZENワーキンググループが2026年8月25日付で公開したドラフト「Access Request and Approval Profile」は、認可判断が『拒否』だった場合に、人間の承認を挟んで再判断させるワークフローをAuthZEN認可APIの拡張として定義する。長時間動くAIエージェントが実行中に予期しないリソースへのアクセスを求め、そのたびに拒否が発生するという課題意識をドラフト本文で確認した。

AIエージェントが多段階のタスクを自律的にこなす中で、事前には想定していなかったドキュメントやチャンネルへのアクセスを求め、そのたびに「権限なし」で止まる——この状況を標準化された手続きで扱うためのドラフトが、OpenID AuthZENワーキンググループから2026年8月25日付で公開されている。「AuthZEN Access Request and Approval Profile」（著者K. McGuinness氏）の本文を確認すると、これはAuthZEN認可API本体の判断モデルには一切手を加えず、「拒否されたが、申請すれば通る可能性がある」という状態を扱うための拡張プロファイルであることが分かる。

3行まとめ

拒否（denial）は依然として拒否のまま扱い、アクセスとみなしてはならない（MUST NOT）という原則を保ったまま、承認ワークフローを通じて再評価するための「アクセスリクエストエンドポイント」「タスクハンドル」「再評価完了モード」を追加するプロファイル。2026年8月25日公開のドラフト1

動機として挙げられているのは、多段階タスクを実行するAIエージェントが実行の途中で未宣言のリソースへのアクセスを必要とし、1つのタスクの中で何度も拒否が発生しうるという状況

承認手続きの終了後、Policy Decision Point（PDP）が実行時点で改めて権限の有無を判断し直す「再評価（re-evaluation）」を基本の完了モードとしている点が設計の中心

何が課題として書かれているか

ドラフトの序文は、従来型のシステムとエージェント時代のシステムの違いをこう対比している。

In classic deployments, the authority a caller needs is largely fixed at provisioning time. […] Runtime denials are uncommon and typically indicate misconfiguration or attack, and the appropriate response is to log, alert, or refuse.

（従来型の配備では、呼び出し元に必要な権限はプロビジョニング時点でほぼ固定されている。実行時の拒否はまれで、通常は設定ミスや攻撃を示すものであり、適切な対応はログ記録・警告・拒否だ）

An AI agent executing a multi-step task discovers, mid-execution, that it needs to read a document, query a record, or post to a channel that was not declared when the agent was deployed. Each previously unseen resource produces a denial, and the same agent may produce many such denials over the course of a single task.

（多段階タスクを実行するAIエージェントは、実行の途中で、エージェントの配備時には宣言されていなかったドキュメントの読み取り・レコードへの問い合わせ・チャンネルへの投稿が必要だと気づく。これまで見たことのないリソースそれぞれが拒否を生み、同じエージェントが1つのタスクの過程で何度もこうした拒否を生む可能性がある）

つまりこのプロファイルは「AIエージェントが動的にスコープを広げる必要が出てくる」ことを前提に設計されている。

拒否は拒否のまま——承認されても即アクセスにはしない

ドラフトが繰り返し強調しているのが、承認プロファイルを追加しても、AuthZEN本体の判断モデル（拒否は拒否）を壊さないという原則だ。

The profile preserves the AuthZEN Authorization API decision model: a denied decision remains a denial and MUST NOT be treated as access.

（このプロファイルはAuthZEN認可APIの判断モデルを保持する。拒否された判断は拒否のままであり、アクセスとして扱ってはならない）

これはセキュリティ考慮事項セクションでも「Denial Remains Denial」という項目名で改めて念を押されている。承認が取れた後も、Policy Enforcement Point（PEP）はそれ自体をアクセス許可の代わりとして扱わず、Policy Decision Point（PDP）に対して改めて評価をやり直す（re-evaluation）ことで、実行時点でPDPが権限判断の権威を保ち続ける設計になっている。

承認フローの流れ

ドラフトが定義する要素は、拒否時に「申請可能（requestable）」であることを示す情報、その申請を受け付ける「アクセスリクエストエンドポイント」、承認が完了するまでの非同期処理を追跡する「タスクハンドル」、そして承認後にPDPが権限を再判断する「再評価完了モード」の4つに整理できる。Appendix Aには「マネージャー承認」と「エージェントのツール発見」という2つのエンドツーエンドの例が用意されており、後者は実際にAIエージェントのユースケースを想定して書かれている。

この4つの要素を整理すると次のようになる。

要素	役割
requestable（申請可能フラグ）	拒否レスポンスに含まれ、「この拒否は承認申請で覆る可能性がある」ことを示す
アクセスリクエストエンドポイント	承認の申請を受け付ける、デプロイごとに1つのエンドポイント
タスクハンドル	承認が完了するまでの非同期処理を追跡するための参照子
再評価完了モード（Re-evaluation Mode）	承認後、PDPが実行時点で権限を改めて評価し直す、仕様が定義する唯一の基本完了モード

出典: AuthZEN Access Request and Approval Profile - Draft 1 本文

「エージェントのツール発見」の例では、CRM検索ツールを使おうとしたエージェント（subject.properties.actにsub_profile: "ai_agent"というクレームを持つ）が最初のリクエストで拒否され、PDPがreason: "agent_authority_missing"とともにtemplate: "agent_tool_class_approval"という「広範なスコープ（class）承認」を要求する、というJSON例が具体的に載っている。ドラフトの説明によれば、この広範スコープ承認の設計により、エージェントは類似する後続の呼び出し1件ごとに新しいアクセスリクエストを出す必要がなくなる、とされている。

なぜ「再評価」だけが基本の完了モードなのか──Appendix Cを読む

Appendix Cの13項目のQ&Aのうち、C.2「なぜ再評価モードだけが基本の完了モードなのか」を実際に読むと、その理由がこう説明されていた。

The PDP is the authoritative point at enforcement time. Returning an AuthZEN Authorization API decision (rather than a token or any other directly-enforceable artifact) ensures that current policy, subject status, risk state, revocation, and approval expiry are all evaluated again at the point of use, not frozen at approval time. Approval workflows often take minutes to days; conditions can change.

（PDPは実行時点での権威ある判断者である。トークンなど直接行使可能な成果物ではなくAuthZEN認可APIの判断を返すことで、現在のポリシー・サブジェクトの状態・リスク状態・失効・承認の有効期限が、承認時点で固定されるのではなく、利用時点で改めて評価されることが保証される。承認ワークフローはしばしば数分から数日かかり、その間に状況は変わりうる）

もう1つ、C.12「なぜワークフローエンジンや承認ポリシー言語、UIをあえて定義しないのか」も本文を確認した。

These exist in many incompatible forms across IGA, ITSM, governance, chat-approval, and custom platforms. Standardizing them in this profile would either pick a single vendor model or define a surface so broad it carries no semantic value.

（これらはIGA・ITSM・ガバナンス・チャット承認・独自プラットフォームにまたがって、互いに非互換な形で既に多数存在している。このプロファイルの中でそれらを標準化しようとすれば、特定ベンダーのモデルを選ぶことになるか、意味を持たないほど広すぎる範囲を定義することになる）

つまりこのプロファイルは「承認そのものをどう処理するか」には踏み込まず、認可の実行層と、その下で動く承認ワークフローとの間の「相互運用可能な接続点」だけを標準化しようとしている、という設計判断が読み取れる。

一次ソースだけで確認できたこと・できなかったこと

このプロファイルは2026年8月25日公開という、この記事の執筆時点からわずか数日前のドラフト-00版（初版）であり、目次を見る限り23章という分量の大きい仕様だ。文書末尾のAuthor's Addressを確認すると、著者Karl McGuinness氏の所属は「Independent（無所属）」と記載されており、謝辞も「OpenID AuthZENワーキンググループでの議論とレビューに感謝する」という一般的な文言のみで、特定の企業や製品名は挙がっていなかった。このプロファイルが実際にどの製品・ベンダーで実装される見込みかについては、確認した一次ソースの範囲では読み取れず、少なくとも文書自体が特定の実装元を明記していないことは確認できた。Appendix Cの13項目のうち今回本文を確認したのは2項目（C.2・C.12）にとどまり、残り11項目や、承認・却下の判定を誰がどう行うか（Identity Governance製品との統合など）といった実装寄りの節までは踏み込んでいない。この記事を書いている自分自身は認可システムの実装経験がない。

関連記事: MCP（Model Context Protocol）とは

感想・指摘はコメント欄へ。