共有APIキーやサービスアカウントを使うと、個々のエージェントとリクエストの背後にいる実行者を区別できなくなります。ログに残るのは認証情報であり、顧客のために操作するエージェントやサポート担当者ではありません。小規模なら不便で済みますが、エンタープライズ規模では危険です。請求情報、医療記録、インフラへの変更が誰によるものか分からなければ、コンプライアンス上の抜け漏れが生じ、インシデントの調査が難しくなります。また、リスクを高める過度に寛容なポリシーを強いられます。

複数エージェントのワークフローでは、オーケストレーター、ツールエージェント、MCPサーバーを次々に経由するのが一般的です。IDを引き継げなければ、最終的なシステムは仲介役を信頼するか、リクエストを拒否するしかありません。Agent Identityは、下流システムが元のトークンを信頼する場合のトークンパススルー、エージェント自身として動作する必要がある場合のOAuth2クライアントクレデンシャル、そして「ユーザーの代理として動作するエージェント」を表すトークンを発行するOBO交換に対応します。エージェントを変更せずに、基幹システムがユーザーごとの適切な権限を適用できます。

IDは、それに基づいて制御できてこそ役に立ちます。TrueFoundryでは、各エージェントに対する許可リスト（ユーザー、チーム、アプリ、他のエージェント）と、モデル、MCPサーバー、サービスへの送信先権限を設定できます。付与した権限を削除すれば、ゲートウェイは直ちに403を返します。これらの制御を一元化すれば、エージェントごとに脆弱なアクセスロジックを重複実装する必要がなくなり、規模やリスクの変化に応じて権限の監査、取り消し、厳格化を行う場所も一本化できます。

TrueFoundryは複数のIDモデルに対応しています。迅速に導入できるTrueFoundry発行トークンのほか、Okta、Entra、その他のOIDCプロバイダーのsubjectクレームにひも付けるIdPベースのIDも利用できます。AWSの処理向けにはSigV4署名にも対応しています。エージェントはどこで稼働していてもガバナンスの対象にできます。プロキシ型エージェントには受信側のポリシー適用を、組み込み型エージェントには送信側のガバナンスを適用できます。段階的な導入も可能で、まずリスクの高いエージェントを登録し、デプロイ構成を再設計せずに対象を広げられます。

ゲートウェイでID管理を一元化すると、リスクも集中します。トークン交換、キャッシュ、権限取り消しが重要なインフラとなるため、トークンライフサイクルの監視、ゲートウェイのスケーリング、交換経路の強化など、新たな運用業務が発生します。また、負荷が高い状況でのOBOフローやSigV4署名について、レイテンシーや障害時の挙動も評価が必要です。TrueFoundryはトークンキャッシュ、更新ロジック、OpenTelemetryトレースでこうした課題の多くに対応しますが、プラットフォームチームはゲートウェイをSLOやインシデント対応手順に含める必要があります。