アイデンティティは、設定ではなくライフサイクルとして捉える

本ブログは「AIエージェントの登場で、従来のID管理が崩壊する理由」連載シリーズ、第六回目（最終回）の記事です。

エージェントは、一度設定してそのまま放置しておけるものではありません。構築され、公開され、デプロイされ、やがて廃止されます。この一連の流れ全体を追跡しないアイデンティティは、書いたきり忘れられた記録にすぎません。認証情報が、本来紐づいていたエージェントよりも長く生き延びてしまうのは、そのためです。

だからこそ、アイデンティティはライフサイクルとして扱うべきです。認証情報は、誰かが必要になったときにその都度発行するのではなく、定められたゲートで発行します。失効も、発行と同じくらい簡単に行えるようにします。エージェントを立ち上げるのに管理された1つの手順で済む一方で、それを廃止するのにチケットを起票して1週間かかるようであれば、そのシステムは既定でリスクを蓄積していく構造になっています。

ゲートは最低限の対策であり、到達点ではない

発行と失効のゲートは必要な仕組みです。ただし、この考え方の中で最も強力な対策ではありません。最も強力な対策の形——そして2026年に向けて目指す価値のある対策は、常時保持される権限そのものをなくすことです。

エージェントは、恒常的な権限を保持すべきではありません。アクセス権は、必要なタイミングでその都度、目の前のタスクの範囲に限定して付与され、タスクが完了した瞬間に解放されます。タスクとタスクの間、エージェントの基本のアクセス権はゼロです。権限は、それを必要とする作業があるときに現れ、作業が終わると消えます。

これは、人のアイデンティティ管理において、この10年間実現されずにきた理想形です。人に対するジャストインタイムのアクセス権付与がなかなか進まないのは、人の業務フローが煩雑で、人が摩擦を嫌うためです。エージェントは、この計算を両方向から変えます。

1つは、より切実な課題にするという方向です。エージェントは、数千単位で生成されます。しかも短命です。それだけの規模の集団全体に常時保持の権限をかけ合わせ、そのほとんどが普段は使われないまま置かれている状態は、誰も承認した覚えのない被害範囲を生み出します。

もう1つは、より実現しやすくするという方向です。エージェントは、自らの実行の流れの中で、プログラムによって認証情報を要求し、解放することができます。これは、人の業務フローでは決してできないことです。人に対するジャストインタイムのアクセス権付与を阻んできた摩擦は、ソフトウェアにとってはほとんど問題になりません。人にとって理想にとどまっていたことが、エージェントにとっては運用上現実的なものになります。

この仕組みには、拠り所となる標準規格があります。有効化、一時停止、失効、削除といったライフサイクルオペレーションは、まさにOpenID Provider Commandsが定義しているものです。アイデンティティをその一生にわたって管理するための言葉を、一から考え出す必要はありません。あとは、それらをエージェントプラットフォーム内のゲートに組み込み、発行と失効を手作業の後始末ではなく、一級の操作として位置づける作業を行うだけです。

認可のループを閉じる

本ブログの結論は、ここにあります。

前提は単純で、エージェントは非決定的です。権限を付与する時点では、エージェントがどの行動を取るかの集合は分かりません。ツールの組み合わせを、プロンプトやコンテキスト、そして自分を呼び出したものの出力に基づいて、実行時に選ぶためです。この1つの事実こそが、借用した認証情報がうまくいかない理由であり、権限の範囲を狭く保たなければならない理由であり、委任の連鎖を検証可能にしなければならない理由であり、そして認可を実行時に判断するコントロールプレーンに置かなければならない理由です。

これはまた、認可を一度きりの設計時点での付与にはできない理由でもあります。行動主体が実行されて初めて何をするかを決めるのであれば、その行動主体が何をしてよいかを事前に決めることはできません。認可は継続的でなければならず、エージェントの目の前にある実際のタスクに対して、実行時に評価される必要があります。

これを運用可能にするのがライフサイクルです。ジャストインタイムでの発行とは、実行時の認可をアイデンティティという形で表現したものです。エージェントは、そのタスクに必要なアクセス権だけを、必要なタイミングで手に入れ、それを返します。失効は、これを反対側から見た同じ考え方です。継続的な再評価とは、設定して立ち去るような仕組みではなく、エージェントが動いている間、ライフサイクルもともに動き続けることを意味します。

明確なライフサイクルに沿って、実行時に発行・範囲設定・失効・再評価ができないエージェントのアイデンティティは、もはやアイデンティティとは呼べません。それは、名前がついているだけのリスクです。

次にすべきこと

自社の環境ですでに稼働しているエージェントを1つ選び、次の5つの問いに順番に照らし合わせてみてください。

• そのエージェントは、自分自身のアイデンティティを持っているか、それとも人のアイデンティティを借用しているか。
• 権限は、そのタスクの範囲に限定されているか、それとも丸ごと継承されているか。
• ツールや別のエージェントを呼び出すとき、委任の連鎖は保たれているか、それとも作り直された1つのトークンに平坦化されてしまうか。
• 認可は、コントロールプレーンによって実行時に判断されているか、それともデプロイ時にハードコードされているか。
• 明確なライフサイクルに沿って発行・範囲設定・失効ができるか、それとも誰かが一度書いたきりの静的な記録になっていないか。

答えが望ましくないものだった箇所が、次に直すべき対象です。最も大きな被害を及ぼしうるエージェントから着手し、順に対応していきます。

<連載記事の概要：関連ブログもぜひご覧ください>

Part 1：認証情報の「借り物競争」を終わらせる
なぜ人間のアクセスキーをそのまま引き継ぐことが、実質的な「特権昇格（Privilege Escalation）」になってしまうのか。その根本原因を解剖します。「最初に入国審査でスタンプを押されたパスポート（＝一度きりの認証）」ではなく、「実行時にその都度判断される権限」こそが解決策となる理由を解説します。 近日公開予定です。まずはここからスタートします！

Part 2：第一級のインフラとしての「エージェントID」の定義
真のエージェントアイデンティティとは何か。それは「独立したプリンシパル」「制限された権限スコープ」「明確な所有者」、そして「緊急停止スイッチ（キルスイッチ）」の4つを備えたものです。また、証明（Attestation）によってそのIDの信頼性を担保する方法や、優秀なエンジニアなら誰もが抱く疑問「これって既存のワークロードアイデンティティ（SPIFFE等）と何が違うの？」という問いに答えます。

Part 3：委任チェーン（Delegation Chain）の追跡
エージェントからツール、さらに別のエージェントへと処理が渡っていく「委任の連鎖」を追いかけます。チェーンをフラットに簡略化（横着）したときに発生する「代理人問題（Confused Deputy問題）」の危険性と、現場でその連鎖が維持されるか破壊されるかを左右する2つのプロトコル、MCP（Model Context Protocol）とA2A（Agent-to-Agent）の実践に迫ります。

Part 4：認証情報を「モデル（LLM）」に触れさせない設計
エージェントのコンテキスト（プロンプトの文脈）は、常に外部からの攻撃に晒されています。プロンプトインジェクションを1発受けるだけで、中のデータはすべて読み取られてしまうのです。だからこそ、生の認証情報をエージェントのプロセスに渡してはいけません。ブローカーが認証情報を保持し、境界線で認証をインジェクションする（動的に差し込む）ことで、エージェントにはスコープを絞った最小限の権限（Capability）だけを渡すアーキテクチャを解説します。

Part 5：認可とガバナンスの最適解
ガバナンスはプラットフォーム側で一元管理し、既存のID基盤（IdP）へと信頼をシームレスに連携させる。そして、コントロールの強さを「爆発半径（影響範囲の大きさ）」に合わせて最適化する手法を考えます。さらに、まだ誰も綺麗に解決できていない最前線の課題――「エージェントが、自身のプラットフォームの統制が及ばない『外部の信頼ドメイン』をまたいで行動するとき、何が起きるのか」に切り込みます。

Part 6：ライフサイクルとしてのアイデンティティ
アイデンティティを「動的なライフサイクル」として捉えます。常時与えられた特権（永続的な権限）を排除し、タスク実行時のみ、その瞬間だけ有効な「ジャストインタイム（JIT）」の認証情報へとシフトします。連載の原点である「非決定性（予測不可能性）」へと話を戻し、最終回として、あなたの会社の実環境にいるエージェントに対して実行すべき「6つの監査チェックリスト」を提示します。

本ブログはグローバルで公開された「Identity as a lifecycle, not a setting」の抄訳版です。