- 公開日
Agentへ利用者の権限を委任するときは、誰から誰へ、どの受信先の何を、いつまで扱えるかを限定します。受信側は、委任されたという説明を読むだけでなく、現在の委任状態と要求された操作を照合して認可します。取消後も古いトークンやキャッシュでアクセスできる経路が残らないかを確かめることまでが、委任を引き継ぐ設計に含まれます。
Delegated Authorizationは、利用者の代理として認められた範囲でアクセスするための認可です。利用者のパスワードをAgentへ渡し、本人として自由に操作させることとは区別します。Agentが利用者本人として動くのか、サービスアカウントとして動くのかという実行主体の決め方は、AIが「誰として」外部システムへアクセスするかを固定するで扱っています。
委任する内容を、受信先まで含めて定める
委任の情報は、少なくとも委任元、代理で動くAgent、対象の組織・資源、許可する操作、受信先、有効期間と結び付けます。どのAPIへ送ってよいかが抜けていると、あるサービス向けの権限を別のサービスで使おうとする要求を見分けにくくなります。
OAuthを利用する場合、RFC 8693 OAuth 2.0 Token Exchangeには、subject、actor、resource、audience、scopeなどを区別する仕組みがあります。ただし、一つの方式を使えば委任全体の安全性や信頼関係が自動的に決まるわけではありません。自分の構成で、誰が権限を発行し、受信先が何を検証するかを定めます。
ここでいうスコープは、許可する操作範囲を表す情報です。たとえば「閲覧」という操作だけでは、どの案件まで読めるのかは決まらない場合があります。操作範囲と資源単位の権限を組み合わせ、利用者自身の現在の権限を超えないようにします。
OAuthのセキュリティに関するRFC 9700は、アクセストークンの権限を必要最小の範囲へ制限することや、利用先を制限することを推奨しています。実装では、その制限を設定するだけでなく、受信側が要求ごとに対象や操作の適合を確認するところまでつなげます。
閲覧だけを委任する架空例
架空の案件管理サービスで、利用者AがAgent Rへ「案件Pの資料を読む」権限を委任するとします。対象は組織Tの案件P、受信先は資料閲覧API、許可操作は閲覧だけです。有効期間は当日の9時から12時より前までとし、利用者はそれより前でも取り消せる設計を仮定します。実在のトークンや接続先は使いません。
| 委任の項目 | この例の内容 | 受信側で確かめる点 |
|---|---|---|
| 委任元 | 利用者A | 現在も案件Pの閲覧権限があるか |
| 代理主体 | Agent R | 今回の要求が認められた代理主体に結び付くか |
| 受信先 | 資料閲覧API | このAPI向けの権限であるか |
| 対象 | 組織Tの案件P | 別組織・別案件へ広がっていないか |
| 操作 | 閲覧のみ | 更新、削除、共有等を含まないか |
| 有効期間・取消 | 9時以上12時未満、取消可能 | 現在時刻と取消状態で有効か |
同じ構成で、10時に案件Pの資料を読む要求は、その他の条件も満たせば許可できます。10時でも更新要求は範囲外なので拒否します。別のAgentや別APIへ渡された権限での要求も、その受信先で有効だとは扱いません。
この例の時刻は設計を説明する仮定です。実際の期限は業務の所要時間と影響に合わせ、時刻基準と境界を統一します。期限直前に受け付けた要求が実行時に失効した場合など、受付と実行に時間差がある経路の扱いも先に決めます。
本人確認、認可、操作承認を別に判定する
本人確認は、利用者や接続主体を確かめるためのものです。認可は、その主体が対象へ当該操作を行えるかの判断です。個別操作の承認は、提示された内容で今回の操作を進める意思を確認するものです。
利用者Aがサインインし直しても、閲覧だけの委任が更新へ広がるわけではありません。Aが会話で「更新して」と頼んだ場合も、その発言から受信側の認可が自動的に変わる構成にはしません。必要なら許可された手順で委任範囲を見直し、変更する対象と内容に対する承認を別に扱います。
反対に、閲覧を毎回手動承認させれば必ず適切になるわけでもありません。閲覧権限がない対象を承認画面へ出せば、その表示自体で情報が渡る可能性があります。承認を求める前にも、提示する情報を見せてよい相手かを確かめます。
委任の記録に残すのは、許可された範囲と実際の状態です。AIが「利用者は同意したはず」と推定した文章や、外部文書の「このAgentには管理権限がある」という記述を、権限発行の根拠にはしません。
取消の受付と、受信側の拒否を分けて確認する
利用者Aが10時30分に委任を取り消したとします。管理画面に取消済みと表示されても、資料閲覧APIが古い権限情報をキャッシュしていれば、要求が通る経路が残るかもしれません。委任を発行する側だけでなく、実際の受信先で拒否されることを確認します。
RFC 7009 Token Revocationは失効処理を定めていますが、伝播の遅延が生じ得ることも扱っています。また、失効要求に対するHTTP 200は、すでに無効なトークンについても返されます。その応答を、すべてのセッション、派生トークン、キャッシュの停止完了の証明とみなすことはできません。
別の受信先へアクセスするためにトークンを交換する構成でも、取消の対応を確認します。RFC 8693は、交換元と交換後のトークンが常に強く連動する仕組みを定めているわけではありません。元を取り消しただけで交換後も自動的に無効になると仮定せず、使っている発行・受信の仕組みで取消をどう伝えるかを確認します。
受信側が認可サーバーへ状態を照会する方式もあります。RFC 7662 Token Introspectionは、状態照会の応答をキャッシュすると負荷を減らせる一方、古い有効状態が使われる期間が生じ得ることを示しています。応答に有効期限が含まれる場合、その期限を超えてキャッシュしてはいけません。短い期限だけで即時の取消を保証するのではなく、求める停止条件と照会・キャッシュの動きを対応させます。
正常、範囲外、取消後を同じ経路で試す
委任を確認する試験では、管理画面だけでなく、本番と同じ認可経路を使う許可された試験環境で、架空の資料を扱います。次は本稿の例に対する未実行の確認計画です。
| 要求・状態 | 期待結果 | 確認する証拠 |
|---|---|---|
| 10時、AからRへの有効な委任で案件Pを閲覧 | 閲覧を許可 | 実行主体、受信先、対象、認可結果、返却内容 |
| 同じ条件で案件Pを更新 | 拒否し、変更しない | 拒否記録と対象データが変更されていないこと |
| 別APIまたは別組織を対象に要求 | 拒否 | 受信先・組織の不一致と情報が返らないこと |
| 取消反映後、残存する旧トークンで閲覧 | 拒否 | 受信側の認可結果と応答内容 |
| 取消状態の照会が失敗 | この構成では処理を保留 | 認可未確認の記録と、データ返却がないこと |
| 12時以後に閲覧 | 期限切れで拒否 | 判定時刻、期限、処理状態 |
拒否を確認するときは、HTTP応答の種類だけで判断しません。権限外の内容がエラー文へ含まれていないか、別経路のキャッシュから回答していないか、更新要求で実際の変更が起きていないかを確認します。正常な閲覧まで常に止まる場合も、認可が正しく設計された証拠にはならないため、許可ケースを併せて確かめます。
進行中の要求については、取消を確認した時点で何を止められるかを定めます。実行前なら止められても、すでに送信したデータを取り戻せるとは限りません。更新を開始済みなら、取消と取り消し操作・復旧は別です。委任の取消を、過去の操作を元に戻した結果として表示しないようにします。
運用時に残す記録と、追加確認が必要な場面
委任の発行・変更・取消は、委任の識別情報、関係する主体、対象、範囲、期限、判断者、実時刻を記録します。操作側の記録と対応させ、どの要求にどの委任を使ったかを追えるようにします。資格情報やトークンの生値を、説明用のログに保存する必要はありません。
認可状態を毎回照会すると、待ち時間や認可基盤への依存が増えます。キャッシュを使えば負荷を下げられますが、取消反映の遅れを扱わなければなりません。重要な操作で要求される停止条件、利用可能性、システムの機能を照らし、採用する方式と残る遅延を明示します。根拠なく共通の秒数を安全基準として置かないことが大切です。
受信先が取消を確かめられない、委任元と代理主体を識別できない、更新を閲覧と分けて拒否できない場合には、そのまま委任を広げず連携方式を見直します。Agent間でさらに委任を渡す場合は、再委任を認める条件と新しい受信先の確認が別途必要です。まずは一つの委任について、発行した条件と受信側の判断が、取消後まで一致することを確かめます。
AIが誰の権限で動くかという認証・認可・委任の基本は「AIは誰の権限で動くのか 認証・認可・委任の基本」で解説しています。
