AIエージェント「専用」アイデンティティの正体——それはワークロードIDと何が違うのか

ファーストクラスのエージェント・アイデンティティの正体。そして、それは単なる「ワークロード・アイデンティティ」にすぎないのでしょうか？

本ブログはグローバルで公開された「What a first-class agent identity actually is, and whether it is just workload identity」の抄訳版です。

前回の記事では、「借り物の資格情報」と「静的な権限付与では統治できない非決定的なアクター」という課題を残しました。この解決策は、借りるのをやめることです。エージェントに対して、認可の対象となり、行動を帰属させることができ、個別に失効可能な、安定して検証可能なランタイム用のプリンシパル（主体）を与える必要があります。

この一文には、4つの要件が隠されています。それらを分解してみましょう。

エージェント・アイデンティティに必要な4つの要素

• 独自のプリンシパル（Distinct Principal） エージェントは独立したアクター（主体）です。なりすまし対象の人間でも、その中に隠れてしまうような共有サービスアカウントでもありません。エージェントの行動は、そのエージェント自身のものとして監査ログに記録・解決されます。
• 制限された権限スコープ（Scoped Permissions） 付与される権限は、いかなる人間の権限よりも狭く、起動した人間ではなく「タスク」の規模に合わせて設定されます。この「スコープ」こそが、第1回で触れた非決定性の問題に対する答えです。すべての行動を予測することはできないからこそ、エージェントが行動できる空間の「境界（バウンダリ）」を定義するのです。
• 明確な所有者（Clear Owner） すべてのエージェントは、その責任を負う特定の個人またはチームにまで遡って追跡できなければなりません。所有者のいないアイデンティティは、名前の書かれていない債務（リスク）を抱えているのと同じです。
• キルスイッチ（Kill Switch） 他の誰の資格情報にも影響を与えることなく、そのエージェントの権限だけを失効（無効化）させることができます。この「独立した失効機能」があるからこそ、そもそも安心してアイデンティティを渡すことができるのです。

これらのうち1つでも欠ければ、第1回の悲惨な状態に逆戻りしてしまいます。そして、エンジニアが真っ先に手を伸ばしがちな代替案は、どれも少なくとも1つの要素を欠いているのです。

アプローチ	アクターモデル	属性情報 (Attribution)	権限スコープ (Scoping)	失効 (Revocation)	破綻するポイント
共有サービスアカウント	1つのIDを複数のエージェントで共有	なし：すべてのエージェントが同一に見える	大雑把（粗い）、全員で共有	つを失効させると、すべてが失効する	エージェントを個別に識別することも、特定のエージェントだけを停止することもできない。
ユーザーごとのなりすまし	エージェントが人間のIDを借用	ログにはエージェントではなく人間が表示される	その人間の全アクセス権を継承してしまう	キーのローテーション（変更）により、人間のアクセスが遮断される	前回の記事（第1回）で指摘した問題そのもの。
静的シークレット	長寿命の（期限のない）キー	アクターではなく「シークレット」に紐づ	そのシークレットが作成された当初の目的のまま	ローテーションもできず、綺麗な失効も不可	シークレットが漏洩し、永遠に生き残り、スコープ制限も機能しない。
ファーストクラスのエージェントID	独自のプリンシパル	行動はエージェント自身に帰属する	タスク単位のスコープ（人間より狭い範囲）	独立したキルスイッチ	本物のインフラとして運用するためのコスト（実装・管理の手間）。

優秀なエンジニアなら、すでに抱いているであろう疑問

もし、エージェントが「スコープ制限された権限」と「キルスイッチ」を備えた「安定したランタイム用プリンシパル」を持つのであれば、それはまさにワークロード・アイデンティティ（Workload Identity：実行プログラム用のID）の説明そのものです。では、「エージェント・アイデンティティ」とは、単にワークロード・アイデンティティに新しいラベルを貼り直しただけのものでしょうか？

これは現在も活発に議論されている最中であり、決着はついていません。そして、誠実な答えを言えば、「3つの不変条件（インバリアント）」に依存する、となります。

• 一対一のマッピング（A one-to-one mapping） 1つのエージェントが、正確に1つのワークロード（実行プログラム）に対応していること。これが維持される限り、ワークロードのIDがそのままエージェントのIDとなります。
• 真実の基準（信頼できる情報源）としてのレジストリ（A registry as the source of truth） どのエージェントが存在し、それらが何であるかを、信頼性を持って記録する「台帳（レジストリ）」が存在すること。これがなければ、エージェントの「全体像（母集団）」を把握できず、個別のバラバラなプロセスとしてしか扱えなくなります。
• アイデンティティの継続性（Identity continuity） プロセスの再起動、一時停止、再スケジュールを挟んでも、アイデンティティが維持されること。復帰したエージェントが、停止前と「証明可能なレベルで同一のエージェントである」と言える必要があります。

これら3つがすべて維持される場合、エージェント・アイデンティティはワークロード・アイデンティティに収束します。SPIFFEやWIMSEといったオープン標準のフレームワークを用いてワークロードを証明（アテスト）し、それに対して直接認可を行えば十分です。余計なレイヤーを追加する余地はありません。

しかし、これらは頻繁に崩れます。 エージェントはバースト的（一時的に大量発生）に動作し、きわめて短寿命（エフェメラル）です。1つのワークロードに固定されることなく、複数のワークロードをまたいで激しく動き回ります（チャーン）。また、自らを証明するためのワークロード自体を持たない「サブエージェント」を動的に生み出すこともあります。

こうして一対一のマッピングは崩壊し、継続性の担保は極めて困難になります。もはやワークロードは、エージェントの忠実な身代わり（スタンドイン）としては機能しなくなるのです。こうなったとき、エージェント・アイデンティティはワークロード・アイデンティティの上に重ねる「上位レイヤー」となります。

主要プラットフォームが示しているもの

すでに一般公開されているプラットフォームの動向を見ると、本番環境でこの「レイヤー化されたパターン」が採用されていることが分かります。

たとえば、Microsoft Entra Agent IDは、単に既存のワークロード・アイデンティティを使い回すのではなく、既存のディレクトリを拡張する形で「エージェント専用のプリンシパル」を導入しています。また、AWS Bedrock AgentCoreは、サンドボックス化されたワークロードの上位に位置する、安定したエージェント・アイデンティティを公開しています。この構造により、下層のワークロードがどれだけ激しく入れ替わっても、エージェントのアイデンティティが一緒にブレることはありません。

ここで、両者に共通する特徴に注目してください。 それぞれが単一のコントロールプレーン、かつ単一の信頼ドメイン（Trust Domain）の内部で完結している点です。1つのシステムがアイデンティティを発行・管理し、エージェントのすべてのホップ（システム間の移動）を監視しています。すべての挙動が「自陣のグラウンド」で行われるからこそ、これらのプラットフォームにとってレイヤーモデルの運用が現実的なものになっているのです。

この観察を、頭の片隅に留めておいてください。これは見かけ以上に重要な役割を果たしており、そして第4回で崩壊することになる「前提条件」だからです。

まとめ

エージェント・アイデンティティとは、「独自の制限された権限」「明確な所有者」「オフスイッチ」を備えた、安定したランタイム用プリンシパルです。それが単なるワークロード・アイデンティティで済むのか、あるいはその上のレイヤーにするべきなのかは、好みの問題ではありません。「一対一のマッピング」「真実の基準となるレジストリ」「ライフサイクルを通じた継続性」の3つを維持できるかどうかで決まります。自社のエージェント群を、これら3つの不変条件に照らし合わせて監査してみてください。それらの条件が崩れる場所こそが、追加のレイヤー（専用ID）を必要とする場所であり、そして現実の多くのエージェントフリート（群）が実際に置かれている場所なのです。

これで、アイデンティティを持つ「1つのエージェント」が誕生しました。しかし、現実のシステムは単一のエージェントでは完結しません。ユーザーがエージェントを呼び出し、そのエージェントがツールを呼び出し、そのツールが別のエージェントを呼び出す……アイデンティティは、これらの「あらゆるホップ」を生き延びなければなりません。次回の記事では、この連鎖（チェーン）の中でアイデンティティに何が起こるのか、そしてそれを保護する、あるいは破壊してしまうプロトコルについて解説します。