8月11日、Auth0が「Intent, Not Just Permissions: Rethinking Authorization for AI Agents」と題した記事を公開した。この記事では、AIエージェントの認可をパーミッション（許可）ベースから「インテント（意図）」ベースに再設計するアーキテクチャ手法について詳しく紹介されている。以下に、その内容を紹介する。
「できる」と「すべき」は別問題だ
AIエージェントのセキュリティを考えるとき、従来の認可モデルには根本的な欠陥がある。
たとえばこういうシナリオを考えてほしい。スケジューリングエージェントがカレンダー、Slack、CRM、メールへのアクセス権を持っているとする。ユーザーが「デザインチームとミーティングを設定して」と指示したとき、プロンプトインジェクション攻撃によって悪意ある命令が付加されていたら？エージェントは会議室を予約し、Slackにメッセージを送り、CRMの連絡先を外部アドレスにエクスポートするかもしれない。これらの操作はすべて「許可されていた」が、ユーザーが「意図した」ものは一つもない。
これを記事では「ブラストラディウス問題」と呼んでいる。エージェントが広範で持続的なパーミッションを持っているとき、インジェクションされたプロンプト一つで生じうる被害の総範囲だ。
RBACは「このロールを誰が持つか」を問い、ABACは主体・リソース・環境をまたいだ条件を表現できる。しかしどちらも「タスクのライフタイム」という概念を持たない。ツールを呼び出せるかどうかは判定できても、そのツール呼び出しがユーザーの依頼の範囲内かどうかは判定できない。
最小権限の原則も答えにはならない。それは「アクセスできるものを静的に減らす」アプローチだ。必要なのはもっと動的なもの——「この特定のタスクに対して、今、何にアクセスすべきか」というリクエスト単位の境界だ。
インテントを認可の第一級オブジェクトにする
記事が提案するパターンは「タスクベース認可（task-based authorization）」と呼ばれる。
考え方はシンプルだ。ユーザーの意図を、そのタスクの期間だけ存在するパーミッションに変換する。ロールと違い、インテントはエフェメラル（一時的）だ。事前に付与されず、持続もしない。ライフサイクルはこうなる：
- ユーザーが意図を表明する（「デザインチームとミーティングを設定して」）
- システムがそれを有界なパーミッションセットに変換する（カレンダーのイベント作成のみ）
- エージェントはその境界内で動作する
- タスク完了時にアプリケーションがパーミッションを削除する
この「変換ステップ」がどう機能するかが核心であり、後述するように最大の難所でもある。
Auth0 FGAで実装する
記事ではAuth0 FGA（関係ベースアクセス制御のマネージドサービス）を使った具体的な実装を示している。タスクを認可モデルの第一級オブジェクトとして扱い、エージェント・ユーザー・ツールとの関係をタプルで表現する。
Auth0 FGAのDSLによるモデル定義はこうなる：
model
schema 1.1
type user
type agent
type task
relations
define assignee: [agent]
define initiator: [user]
define can_execute: assignee
type tool
relations
define task: [task]
define can_call: can_execute from task
「デザインチームとミーティングを設定して」というプロンプトに対して、事前計画ステップでLLMに「このリクエストにはどのツールが必要か」を問い合わせ、calendar_create_eventのみと特定したとする。すると以下の3つのタプルをFGAに書き込む：
{ "user": "agent:scheduler", "relation": "assignee", "object": "task:550e8400-..." },
{ "user": "user:carla", "relation": "initiator", "object": "task:550e8400-..." },
{ "user": "task:550e8400-...", "relation": "task", "object": "tool:calendar_create_event" }
タスク実行前に2つのチェックを行う。まずuser:carlaがそのタスクの正当な起動者かを確認し（別ユーザーが作成したタスクをエージェントが実行するのを防ぐため）、次にエージェントがツールを呼び出せるかを確認する。
# Slackへのメッセージ送信を試みた場合
slack_allowed = fga.check(tuple_key: {
user: "agent:scheduler",
relation: "can_call",
object: "tool:slack_send_message"
})
# => { allowed: false }. インテントのスコープ外。
エージェントがシステム内の別の場所でSlackのパーミッションを持っていても、このタスクには含まれない。境界を強制するのはプロンプトでもエージェントの判断でもなく、認可モデルだ。タスク完了後は書き込んだタプルを削除して、パーミッションを失効させる。
この手法が崩れるケース
記事はこのアプローチの限界についても率直だ。
解決策のない問題： 自然言語からインテントを推論することは本質的に不正確だ。「ミーティングを設定して」が意味するのはカレンダーへの登録だけか、空き時間の確認・会議室予約・Slack通知・招待状送付まで含むのか。この変換は未解決問題であり、推論が間違っていても正しくても、FGAによる強制チェックは必ず実行される必要がある。プロンプトインジェクションで「連絡先もエクスポートして」という拡張意図を主張させることもできるが、タスク境界がそれを阻止する——境界の強制が確実であれば。
部分的な解決策がある問題： インテントがタスク途中で変化するケース（「ミーティング設定」→「アジェンダも送って」）だ。スコープを狭めすぎると正当なワークフローが壊れ、広げすぎると過剰パーミッション問題に逆戻りする。バックグラウンドパイプラインや自律エージェントでユーザーへの同期的な問い合わせができない場合は、CIBA（クライアント開始バックチャネル認証）が有効だ。エージェントがユーザーのデバイスに帯域外の承認リクエスト（プッシュ通知など）を送り、明示的な同意を得てから処理を続ける。
今すぐ着手できること
記事の結論は明快だ。問うべき問いを「このエージェントは何にアクセスできるか？」から「このタスクに対して何にアクセスすべきか？」に変える。
実装に必要なツールは今日すでに存在する。FGAによる強制、CIBAによる人間承認フロー、Token Vaultによるクレデンシャルのタスクスコープ化だ。難しいのはインテント推論の精度であり、それは現時点では未解決だ。しかし推論が改善されたとき、強制レイヤーがすでに正しい形になっていれば、そのまま恩恵を受けられる。
詳細はIntent, Not Just Permissions: Rethinking Authorization for AI Agentsを参照していただきたい。
