AIエージェントが別のシステムを呼ぶとき：アイデンティティの引き継ぎを図にする

Larry

社内のAIエージェントが顧客情報を検索し、結果をチケット管理システムへ書き込む場面を考える。入口でユーザーを認証できても、複数の下流システムを呼ぶと、誰の依頼による操作かが曖昧になりやすい。

一つのサービスアカウントを使えば、記録には「エージェントが操作した」としか残らない。入口のユーザートークンを転送すれば、本来の受取先ではないサービスへ認証情報を渡すことになる。

必要なのはトークンの使い回しではなく、各ホップで代理されるユーザー、実行者、受取先、許可する操作を確定し直すことである。

AWSは2026年7月、Amazon Bedrock AgentCore Gatewayによるマルチテナント実装を公開した。ユーザーを代理するトークンを交換し、audience bindingで受取先を制限する構成である。製品固有の実装だが、設計原則は複数システムをまたぐエージェントにも使える。

OBOでも、ユーザーとエージェントは同一主体にならない

On-Behalf-Of（OBO）では、中継サービスがユーザーのトークンを受け取り、下流サービス用の新しいトークンを認可サーバーへ要求する。受取先は指定したAPIに限定し、権限は元の認可とシステムポリシーの共通範囲に絞る。

エージェント自身のアイデンティティも必要である。RFC 8693は、代理される主体をsubject、処理を実行または委任を引き継ぐ主体をactorとして区別する。act claimの対応状況にかかわらず、監査記録から両者を復元できなければならない。

固有のアイデンティティがない場合は、ERP内のAIエージェントになぜ固有のIDが必要なのか？を先に確認する。サービスアイデンティティはエージェントを識別するものであり、ユーザーの文脈を消す代替手段ではない。

呼び出しチェーンを5ステップで確認する

「ユーザー → エージェント → API」という箱だけでは不十分である。受信、交換、送信をホップごとに分け、次の5点を確認する。

入口トークンの受取先を検証する。 発行者、有効期限、audienceを確認し、入口API向けでなければ署名が正しくても拒否する。
subjectとactorを分けて残す。 ユーザーをsubject、実行するエージェントをactorとして記録する。共有サービスアカウントしか残らないホップでは委任を追跡できない。
交換先を一つの下流リソースに限定する。 requestに次のAPIのresourceまたはaudienceを明示し、発行後も呼び出し先との一致を検証する。
scopeを必要な操作だけに絞る。 ユーザーの認可、エージェントの許可範囲、下流ポリシーの共通部分だけを発行する。検索に削除や全件エクスポートを加えてはならない。
拒否を調査できるログを残す。 交換時刻、subject、actor、audience、要求scope、発行scope、拒否理由を記録する。完全なトークンは保存しない。

下流が変わるたびに交換とaudience検証を繰り返す。顧客情報API用のトークンをチケットAPIへ流用してはならない。MicrosoftのOBO文書も、中継サービスが下流Web API用の新しいトークンを取得する原則を示している。

認可判断をプロンプトだけに埋め込んではならない。AI agentの認可四問表：身元、権限、理由、結果では、バックエンドで強制する検査項目を整理している。

4つの条件で出口を分ける

処理の性質と下流の対応状況により、出口を四つに分ける。

特定ユーザーを代理し、認可システムと下流APIが委任に対応する場合： token exchangeでsubjectとactorを保持し、下流ごとに異なるaudienceのトークンを発行する。
特定ユーザーを代理しない場合： エージェントのワークロードアイデンティティに必要最小限の権限を与える。架空のユーザーは設定しない。
ユーザーを代理するが、下流がOBO非対応または委任を検証できない場合： 入口トークンを転送せず中継層で止め、限定操作のインターフェースか人による確認を用意する。
audienceを証明できない、またはscopeが過大な場合： 交換またはAPI呼び出しを直ちに拒否し、エージェントの推測に委ねない。

判断の起点は、本当にユーザーを代理する処理かどうかである。共有アカウントで主体を隠す必要がある場合や、別の宛先向けトークンを受け入れなければ動かない場合は、高影響操作を自動化する段階ではない。

OBOの検証に成功しても、高影響操作の自動実行が許されるとは限らない。データ責任者またはシステム責任者がsubject、actor、対象API、scope、影響、ロールバック手順を確認し、明示的に承認する必要がある。既定ポリシーで自動実行できるのは、結果を取り消せる低影響の照会に限る。

まず一つの経路を図にする

既存のエージェントを一つ選び、最もよく使う経路を次の形式で記録する。

ユーザーsubject → 実行者actor → トークン発行者 → 対象audience/resource → 発行scope → 拒否条件

共有サービスアカウントしか残らないホップや、異なるaudienceのサービスが同じトークンを受け入れる箇所を探す。見つけたら、新しい自動化を足す前に権限と受取先を絞る。

AI整理カード

各段では、判定（確認済み／要確認／阻止）と、その理由・根拠を先に記す。根拠は subject、actor、トークン交換先の resource／audience、scope／許可境界、endpoint、拒否 code／reason とする。

呼び出し全体の前提情報として、入口トークンの発行者、audience、有効期限を一度だけ記録する。共有サービスアカウントの使用と元トークンの転送は、それぞれが発生する段に記録する。不明値は補完や推測をせず、「要確認」と明記する。出力は段ごとの記録だけに限定する。

対象となる呼び出しチェーン：［ここに入力］