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

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

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

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

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

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

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

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

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

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

認可のループを閉じる

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

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

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

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

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

次にすべきこと

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

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

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

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