AIエージェントの代理実行ID設計｜利用者・agent・toolの権限を一つのtokenに潰さない【2026】

本文

社内AIエージェントがCRMを検索し、経費を下書きし、文書を更新する。ここで「agent用の強いAPI keyを一つ置けばよい」とすると、誰の依頼で、どの実行体が、どの業務操作をしたかが消えます。利用者に許可があってもagent自体に権限がない、またはagentに強い権限があって利用者にはない、という事故を区別できません。

結論は、利用者ID、agent実行体のworkload ID、下流resourceごとの短命access tokenを分け、実行ごとにserver側で交差判定することです。modelが「管理者として実行してよい」と出力しても、tokenの発行・認可・監査はモデルの外に置きます。

三つの主体を、同じ「ログイン」と呼ばない

代理実行には最低でも三つの主体があります。第一に、依頼した利用者。第二に、実際にjobを走らせるagent serviceやworker。第三に、操作されるCRM、ファイル、社内APIなどのresourceです。利用者のsession cookieをworkerへ保存して使い回す、またはすべてのworkerで共有admin keyを使う設計では、主体が一つに潰れます。

NISTのゼロトラストは、ネットワーク位置や所有者だけで暗黙の信頼を与えず、enterprise resourceへのsession前にsubjectとdeviceを認証・認可する考え方です。AI agentでも「社内networkから呼ばれた」「当社のagentだから」という理由で下流toolを信頼しません。resource serverは、現在のuser、現在のagent workload、対象resource、依頼された操作を別々に検査します。

代理と成り代わりを混ぜない

IETF RFC 8693は、token exchangeでdelegation（代理）とimpersonation（成り代わり）を区別します。代理ではagent AのIDはuser Bと別に残り、「Bが一部の権利をAへ委ねた」と理解されます。成り代わりでは受け手から見るとAはBとして扱われるため、監査やpolicyの設計を誤ると実行体の痕跡が失われます。

業務AIの既定は代理です。下流tokenまたは監査eventに、少なくともuser_subject、actor_workload、tenant、resource、action、scope、expires_at、request_idを結びます。token exchangeのsubject_tokenは誰のためか、actor_tokenは誰が動くかを表せます。ただしRFCはtrust modelや具体的なtoken表現までは規定しません。自社のIdPとresource serverで、どの組み合わせを許可するかを明示する必要があります。

tokenを発行する前に、交差条件をserverで評価する

安全な発行条件は「userに読む権限がある」だけではありません。少なくとも次をすべて満たすときに、対象resource向けの短命tokenを発行します。

利用者の現在の認可とtenant所属が有効である
agent workloadが、その業務actionを実行できる
そのagentが、その利用者の代理を許された経路から起動した
audienceとresourceが対象APIに限定され、scopeが必要最小限である
対象操作が現在の業務状態・承認条件を満たす

Microsoft Entraのagent向けon-behalf-of flowは、user tokenとagent側のcredentialを検証してresource tokenを返す例です。同社は本番でclient secretをagent identityのcredentialとして置かず、federated identity credentialやcertificateを使うよう警告しています。これは「user tokenだけで下流を呼ぶ」でも「agent keyだけでuserのデータを読む」でもない経路の実例です。

long-lived secretからworkload identityへ寄せる

agent workerが固定のservice account keyを環境変数へ持つと、漏えい後の影響範囲とrotateの運用が大きくなります。Google Cloudは外部workloadについてservice account keyではなくWorkload Identity Federationを使い、外部のID assertionとtoken exchangeで短命credentialを得る方法を示しています。direct resource accessかservice account impersonationかをresource単位で選べます。

Kubernetesや複数cloudで実行体を識別するなら、SPIFFEのようにprocess/workloadに暗号学的IDを配る方式もあります。SPIFFE Workload APIは、callerを識別してから対応するidentity materialを渡すことを求めます。重要なのは製品選定ではありません。job queueのconsumer、scheduler、interactive APIを同じworkload IDにしないことです。更新workerが取得したcredentialを、ユーザー対話用agentが再利用できない境界を作ります。

tokenは「発行したら終わり」にしない

下流APIは署名、issuer、audience、expiry、scopeを検証し、必要ならtoken introspectionまたはserver側policyも評価します。userの部署異動、agentの停止、承認取消しのあとに、発行済みtokenがいつまで動くかを決めます。RFC 8693もexchangeは入力tokenと出力tokenを自動的に強く連動させるものではなく、失効eventの伝播は実装依存と説明しています。だから短い有効期限、再発行、重大操作の直前再認可を組み合わせます。

監査には、prompt全文や秘密値をtokenへ入れません。request_idで「依頼user」「agent workload」「token発行policy」「resource action」「外部効果」を結び、token値は記録しない。失敗時は汎用keyへfallbackせず、必要なtokenを発行できなかったことを明示して止めます。これはtool引数のschema検証の後段ではなく、toolを実行する主体を決める前提です。

限界と反証

三者IDとtoken exchangeは、読み取りだけの小規模な社内botには過剰な場合があります。短命tokenの発行障害は可用性も下げ得るため、IdP障害時に何をread-onlyで継続するかを業務ごとに決める必要があります。また、tokenを細かくしても、modelが誤った顧客や金額を選ぶ問題は解けません。業務制約、確認画面、承認ゲート、評価試験は別途必要です。

導入時の最小チェックリスト

user、agent workload、resourceのIDとtenant境界を別々に表現したか
代理と成り代わりのどちらを許すか、監査にactorを残すかを決めたか
audience、resource、scope、期限を下流tool単位に絞ったか
共有admin key、長命refresh token、agent間credential共有を廃止できるか
発行・拒否・失効・外部効果をrequest IDで復元できるか

一次情報と確認範囲

確認日：2026年9月15日。製品仕様・制度は更新されるため、導入時はリンク先の最新版を再確認してください。海外の制度・職業規範は日本へ直接適用せず、相違点と限界を本文に明記しています。

本文