委任された権限の意味
委任された権限とは、本人（または組織）が AI エージェントに自分の代理で行動することを認める許可です。アシスタントがあなたのカレンダーに会議を入れたり、あなたの名前でサポートチケットを起票したり、取引先のポータルから請求書を取得したりする場合、それはあなたに由来する権限を行使しています。
適切な委任には 3 つの性質があります。範囲が限定されていること（エージェントは一部のことだけを実行でき、すべてはできない）、時間的に制約されていること（有効期限がある、または取り消せる）、そして帰属可能であること（受信側のアプリケーションが、誰の権限が行使されているのかを判断できる）です。
アプリケーションにとってなぜ重要か
アプリケーションの観点では、エージェントからのリクエストは最大で 3 つの別々の問いを投げかけます。
- どのクライアントがこれを送ったのか? それはエージェントのアイデンティティであり、署名付きリクエストで確認できます（HTTP Message Signatures 参照）。
- どの権限の下で行動しているのか? それが委任です。
- その権限はこのアクションに十分か? それが authorization であり、アプリケーション独自のポリシーによって決定されます。
よく知られたアシスタント運営者からの署名付きリクエストは、1 つ目の問いにはよく答えます。しかし、それだけでは 2 つ目については何も示しません。アシスタントは、あなたのユーザーのために動いているのかもしれませんし、あなたのユーザーではない誰かのためかもしれませんし、あるいは完全に自律的に動いているのかもしれません。クライアントのアイデンティティを本人の同意の証拠だとみなすのは、エージェント対応設計で最もよくある誤りの 1 つです。署名付き AI エージェントリクエストが証明するものと、証明しないもの を参照してください。
委任は通常どのように表現されるか
- OAuth 形式の付与。 本人があなたのアプリケーションにサインインし、OAuth 2.0 (RFC 6749) で定義されるように、制限されたスコープを持つトークンをエージェントに付与します。するとアプリケーションは、そのトークンにどの権限が載っているかを正確に把握でき、付与は取り消し可能です（RFC 7009）。
- アカウント単位の API キー。 ユーザーが特定の統合のために作成するもので、理想的には権限を最小限に絞ります。
- アプリ内での確認。 影響の大きいアクションでは、本人がエージェントが用意した特定の操作を承認します。
- トークンレベルの委任クレーム。 OAuth 2.0 Token Exchange（RFC 8693）は、ある当事者が別の当事者のために行動していることを記録する
act（actor）クレームを定義しています。リクエスト中でエージェントの委任を表す新しい取り組みはまだ発展途上であり、アプリケーションは委任クレームを鵜呑みにするのではなく、自身の記録と照合して検証すべきです。
よくある誤解
- 「エージェントが verified なら、ユーザーが承認したことになる」。verified はクライアントの識別を意味するだけです。承認は、アプリケーションが信頼する経路を通じて本人から得られなければなりません。
- 「ユーザーのセッションを使うエージェントなら問題ない」。場合によっては問題ないこともありますが、そのセッションは人が対話的に使うために発行されたものです。多くのアプリケーションは、自動化のために専用でスコープ付きの付与を好みます。そうすれば、アクションの帰属を明確にでき、取り消しも可能です。
- 「委任は全か無かだ」。最も安全な委任は狭く設計されます。読み取りは広く、書き込みは特定のアクションに限り、取り消せない操作には確認を求めます。
Proof of Actor との関係
Proof of Actor は、あるインタラクションがエージェント主導か AI 支援か、そしてその根拠が verified, declared, inferred, unknown のどれかを把握するのに役立ちます。その文脈は、たとえば人のアカウントセッション内で動く autonomous agent のように、どこで委任の問題が生じるかを示します。Proof of Actor は委任の資格情報を発行したり検証したりしませんし、Agent の結果が本人の承認を意味することもありません。それを決めるのは、アプリケーション独自の付与、スコープ、確認です。Route を使えば、実際のトラフィックを観測した後で、各 route に適したポリシーを適用できます。ポリシーパターンについては、人と AI エージェントのためのアプリケーションレベルのポリシー設計 を参照してください。
証拠で何が立証できるか、何が立証できないか を読むか、早期アクセスに申し込む をご覧ください。
出典
- RFC 6749: The OAuth 2.0 Authorization Framework: リソースオーナーからクライアントへのスコープ付き付与
- RFC 7009: OAuth 2.0 Token Revocation: 委任されたトークンの取り消し
- RFC 8693: OAuth 2.0 Token Exchange: 委任のための
act(actor) クレーム