内部で統治し、外部とは連携する—信頼ドメインをまたぐと何が壊れるか

ここまでで、エージェントは自分自身のアイデンティティを持ち、そのアイデンティティを一連の呼び出しの連鎖の中で運べるようになりました。次の問いは、ルールがどこにあるかです。エージェントに何が許されるかを誰が決め、その判断はどこで下されるのか、という点です。

答えは2つあり、どちらもこれまでの議論全体を支える土台になります。

認可サーバーは、コントロールプレーンである

認可サーバーは、エージェントのアイデンティティにおける戦略的なコントロールプレーンです。アイデンティティを発行し、委任の連鎖に沿ってトークンを交換し、それぞれのトークンが何に使えるかを決めるのが、この認可サーバーです。これまでの3回の記事で扱ってきたことはすべて、ここを経由します。これは、1つのサービスに組み込むライブラリではなく、中核となるインフラとして扱うべきものです。

きめ細かな認可は、アプリケーションのコードのあちこちに散らばらせるのではなく、外部化されたポリシー層——いわゆるポリシーエンジンというカテゴリに置くべきものです。理由は、第1回で扱った非決定性にあります。行動主体が実行時に自らの行動を選ぶのであれば、「この特定の呼び出しは許されるか」という問いにも、実行時に、現在のコンテキストに照らして、全体を見渡せる何かが答える必要があります。このロジックを各サービスの中に埋め込んでしまうと、判断が一貫しなくなり、ルールを変更する中心的な場所もなくなり、エージェント群全体として何ができるのかを把握する手立てもなくなります。

すべてを1つのIDプロバイダーに統一することはできない

これは、大企業であれば共通してぶつかる制約です。組織内のすべてのIDプロバイダーを1つのシステムに統合することはできません。従業員向けのディレクトリがあり、プラットフォームチームにはワークロードID用の仕組みがあり、事業部門が独自に立ち上げたクラウドアカウントには別の仕組みがあり、買収によって加わったものがさらに3つある、という具合です。これらすべてに標準化を指示するのは、何年経っても終わらないプロジェクトになります。

だからこそ、それを目指すべきではありません。エージェントのアイデンティティは1か所で自前に統治し、そこから、すでに存在しているIDプロバイダーやワークロードID用の仕組みへと、連携を外側に広げていきます。

これは、特定ベンダーが考案したものではありません。AWS、Zscaler、Ping、OpenAIなどの寄稿者によって書かれた公開のIETFドラフト（draft-klrc-aiagent-auth）にある、既存の標準規格を組み合わせるというアプローチと同じ考え方です。このドラフトは、代替プロトコルを新たに考案するのではなく、SPIFFE、WIMSE、OAuth、OIDCを組み合わせています。ここで前提とすべき賭け方は同じです。土台となる仕組みはすでに存在しているのだから、やるべきことはそれらの上に統治の仕組みを築くことであって、それらを一から作り直すことではありません。

具体的には、この連携はオープンな基盤技術の上に成り立っています。SPIFFEとSPIREは、ワークロードを証明する仕組みであり、エージェントの実行基盤が自分自身の正体を証明できるようにします。WIMSEは、ワークロードのアイデンティティをシステムをまたいで運びます。OIDCは、IDプロバイダー間で信頼を連携させ、一方が発行したトークンを他方が受け入れられるようにします。これらはいずれも新しい技術ではありません。ここでの作業は、それらを1つの統治の枠組みの下に組み合わせることです。

ここからが、未だ解決できない領域です

第2回で扱った、単一のコントロールプレーンによるモデルがすべてうまく機能するのには、1つの理由があります。Entra Agent ID、Bedrock AgentCore、そして同じ形のオープンソースのパターンは、いずれも1つの信頼ドメインの中でアイデンティティの連続性を保っています。1つのプラットフォームがアイデンティティを発行し、統治し、すべてのホップを把握できるのは、そのすべてのホップが自分の管理下で起きているからです。

難しい問題が始まるのは、エージェントが、発行元のプラットフォームの手が届かない場所で行動しなければならなくなった瞬間です。組織をまたぐ場合。クラウドをまたぐ場合。どのプラットフォームも所有していない、発見可能なツールやエージェントからなるオープンなエコシステムの中。すべてを扱いやすくしていたコントロールプレーンは、その境界線の向こう側では権限を持ちません。発行したトークンも、そこでは意味をなさないかもしれません。それまで正とされてきたレジストリも、そのギャップを埋めることはできません。

この信頼ドメインをまたぐケースこそが、この分野で本当にまだ解決されていない部分です。今日組み合わされつつある標準規格は、そこに至る最も有力な道筋ですが、「自分のエージェントが、自分のアイデンティティを持ち、自分の統治のもとで、自分の管理が及ばないドメインで行動する」という問いに対する明快な答えを、まだ誰も世に出していません。これは解決済みだと言う人がいれば、それは1つの信頼ドメインの中だけの話を、世界全体の話であるかのように売り込んでいるにすぎません。

統制は、被害範囲に応じて調整すべき

今回のブログの最後に、もう1つの視点を紹介します。すべてのエージェントに同じ統制をかけるべきではありません。統制は、エージェントの能力と被害範囲に応じて調整すべきです。CoSAIの能力・影響度によるフレームワークは、一方の端にある低リスクなFAQ検索ボットから、もう一方の端にある、財務操作を実行する高リスクなエージェントまでを扱います。両者の土台にあるアイデンティティの仕組みは同じですが、その上に築かれる統制の範囲はまったく異なります。

FAQボットであれば、大まかな権限範囲と軽いレビューで十分です。一方、資金を動かすエージェントには、厳格なタスクの範囲設定、短命の権限付与、機微な操作における人の関与、そして規制当局に見せられる水準の監査証跡が必要です。統制を一律にしてしまうと、無害なエージェントの動きを窮屈にするか、危険なエージェントへの保護が不十分になるか、いずれかに陥ります。それぞれが及ぼしうる被害の大きさに応じて、段階分けすべきです。

まとめ

エージェントのアイデンティティの統治は、1つのコントロールプレーンに集約します。信頼は、組織内ですでに稼働しているIDプロバイダーやワークロードID用の仕組みへと外側に連携させます。それらが1つに収束することはないためです。きめ細かな認可は、実行時に判断する外部化されたポリシー層に任せます。そして、統制の規模は、組織一律の既定値ではなく、エージェントごとの被害範囲に合わせて決めます。

そのうえで、その限界については正直であるべきです。単一のコントロールプレーンによるモデルが機能するのは、1つの信頼ドメインの中に限られます。ドメインをまたぐ問題は未解決であり、この分野の今後数年は、そこでどう答えを出すかにかかっています。

残る観点はあと1つで、これはここまでの話全体の土台にあるものです。アイデンティティは、一度書いたきりの静的な記録ではありません。エージェントの一生を通じて、発行し、範囲を定め、失効させ、再評価し続けるものです。次回（最終回）では、アイデンティティをライフサイクルとして扱うことを取り上げ、それがなぜ、このシリーズの冒頭で提起した非決定性の問題への最終的な答えになるのかを説明します。

本ブログは「Govern natively, federate outward, and what breaks across trust domains」の抄訳版です。