Agentへ委譲する権限の範囲と失効

Agentへの作業依頼は、利用者や委譲元の全権限を渡すことではありません。現在の実行主体、誰のために動くか、許可された操作と対象、引数、期限、再委譲の条件を明示し、重要な効果の直前に現在の権限を照合します。委譲の履歴が残っていることと、今その操作を許可してよいことは別です。長時間の処理では、開始時の許可、更新・失効、非同期で残った仕事まで管理します。

RFC 8693のact claimは現在のactorと、入れ子になった過去のactorを表現できます。ただしaccess controlではtokenのtop-level claimsと現在のactorを考慮し、過去のactorは履歴情報として扱うと規定しています[S1]。したがって履歴のどこかに強い権限を持つ主体がいることから、現在のagentへ権限を継承させる読み方はできません。

Cedarの公式ガイドは、agentをprincipalとして利用者をcontextへ入れる方式と、利用者をprincipalとしてagentをcontextへ入れる方式を示し、どちらも両方のentityをpolicy評価へ利用できるようにする構成を説明しています[S2]。何を主たる認可判断にするかはapplicationの要件で決めます。二つのidentityを記録しただけで、適切なpolicyが自動成立するわけではありません。

長時間agentの権限失効を扱う原著は、process停止やcredential失効だけでは、queue、callback、委譲task、provider側処理が後から効果を生む経路を閉じられない問題を扱っています。原著の試験・証明は、明示したmanifestと構成の範囲に限られ、globalな停止、rollback、業務完了を証明しないとしています[S3]。本項もその境界を維持します。

依頼を受ける時点で、作業目的、対象、許可する効果、再委譲可否を確定します。子agentへは必要な範囲へ限定した権限を渡し、親の全credentialや過去会話を権限の代用品にしません。外部文書やtool結果に書かれた指示は、利用者が承認したscopeの追加とは扱いません。

実行時には、現在のactor、action、resource、対象版、引数、期限とpolicy版を照合します。承認後に対象が変わった場合は、同じ承認で変更後の効果まで実行してよいかを再判断します。認可サービスへ接続できない時の扱いも決め、古い許可の無条件な再利用や、障害時の許可への切替を避けます。

認可判定と効果の適用の間には競合が残ります。直前にGETしただけでその後の状態が固定されるわけではないため、適用先が持つ条件付き更新、対象版、権限の世代、取消や失効の照合などを組み合わせます。対応する仕組みがない場合は、その時間差と残るリスクを記録します。単なるreadbackを原子的な認可・実行と呼びません。

長時間処理では、process、credential、承認、queue、外部providerのjobが異なる寿命を持ちます。失効時には新しい作業の発行を止めるだけでなく、既に渡したtask、予約、callback、再試行も対象として列挙します。権限のroot IDと世代を持たせ、旧世代の効果を適用先で拒否できる境界を設けることが設計上の要点です。

S3のような保存先や外部業務APIなど、適用先ごとの具体的な失効機構は別途確認します。ここで特定製品がroot世代の検査を標準提供すると主張しません。取消要求を送れたこと、jobがcancelledと表示されたこと、credentialを無効化したことから、すべての遅延効果の不存在を推定しないでください。

別の正当な権限によって同じ仕事を継続する場合も、旧許可が生きていることにはしません。現在の独立した権限と、継続する対象・効果を明示して再び結び付けます。共有jobを丸ごと停止すると他の正当な依頼を壊す可能性があり、逆に共有だから旧許可の仕事を残してよいともいえません。識別できない場合は失効完了を未確定にします。

依頼、承認、委譲、認可判定、送信、適用結果を同じoperationと対象へ結び付けます。token本文や秘密鍵を監査logへ保存せず、必要な識別子と保護された証拠locatorを使います。失効後は、対象の非同期経路と適用先を調べ、受理済み・未適用・適用済み・結果不明を分けます。

認可を拒否したことは、過去の効果を取り消した証拠ではありません。既に適用された効果の訂正や補償は、別の権限と操作として扱います。失効処理の完了、実行の停止、業務目的の達成を一つのdoneへ圧縮しません。

代表的な失敗は、利用者とserviceのidentity混同、再委譲時のscope拡大、承認の別対象への再利用、期限切れcache、失効後のqueue再送、結果不明な外部書込みの再実行、監査履歴のactorを現在権限と誤認することです。権限を更新したつもりで古いworkerが旧設定を使い続ける経路も確認します。

架空の主体と非破壊の適用先で、scope外resource、期限切れ、親だけの失効、子の再委譲、承認後の取消、queue滞留、worker再起動、遅延callbackを確認します。現在の独立した権限で許される仕事は維持し、全拒否だけで正しく制御できたとしません。本RUNでは認可engine、token交換、外部providerを接続した実行試験は行っていません。原著の試験結果も本RUNの実測へ読み替えません。

短命token、限定scope、現在のpolicy照合は有効な防御ですが、外部へ移った非同期の仕事をすべて停止する保証ではありません。RFC 8693はtoken exchangeの規格であり、AI agent全体の失効protocolではありません。Cedarは認可のモデル化手段であり、正しいidentity入力や適用先への強制を自動保証しません。原著も宣言した経路以外の効果を証明していません。

実組織の権限合成、再委譲上限、認可cacheの許容遅延、長時間の更新・再承認、全queue/carrier/sinkの一覧、provider別の失効強制点、実行競合、独立した本番失効事故、version固定の失効試験は未確認です。即時のglobal失効や全効果のrollbackは主張しません。

「指定した主体・scope・世代と列挙した実行経路について、現在権限と失効後の結果を照合した」とします。「親を停止したので、すべての子taskと外部効果が止まった」とは記述しません。

現在のactor、委譲scope、期限、適用先の失効判定、非同期経路の結果が不明な場合は、重要な効果を許可済み・失効完了と宣言しません。

EA-499-R1-20261013と継続Doc 1XpjZC_R1eHlIckvUaEaJ_mcj6YW6j0ihZ0b91z5vewUのEA-499節を継承。2026-10-18に主要一次資料・原著を再確認。仕様、原著の限定結果、提案制御、未実施試験を区別しました。

• [S1] RFC 8693 §4.1 act claim、現在actorと過去actorのaccess-control上の区別: https://www.rfc-editor.org/rfc/rfc8693.html#section-4.1
• [S2] Cedar Using the context、Agents acting on behalf of a principal: https://docs.cedarpolicy.com/bestpractices/bp-using-the-context.html
• [S3] Zhu / Wang, Authorization Revocation for Long-Running AI Agents, arXiv:2609.21284v1、Abstractの適用範囲と試験・証明の限界: https://arxiv.org/abs/2609.21284