エストニアは、AIエージェントに「AI ID code」と呼ばれる公式のデジタルアイデンティティを発行しようとしている。 Kristen Michal首相府によれば、その狙いはAIが「明確に定義された範囲内で、検証可能かつ監査可能な形で、個人、企業、組織に代わって行動できるようにする」ことにある。これが実現すれば、エストニアはAIエージェントに国家が承認するアイデンティティを与えた最初の国になる。これは本当に有用な一歩だが、同時に簡単な部分でもある。難しいのは、そのIDが背負うことになるすべてだ。

私は実際の認証情報を持つエージェントを構築しているので、私の反応は「これはディストピア的なのか」というよりも「このIDは実際に何を結びつけなければならないのか」というものだ。識別子はそれ自体では単なる数字にすぎない。それを意味あるものにするのは、そこに何を紐づけるかだ。すなわち権限、委任のチェーン、そして説明責任である。これらを間違えれば、非常に公式そうに見える主キーを世に出しただけになる。

エストニアが実際に発表したこと

計画では、各エージェントに識別子を割り当て、その目的は二つある。識別と、エージェントが許される行動範囲の制限だ。Michal首相府の打ち出した枠組みは正しい。「誰が、誰の代わりに、どのような権利をもって行動しているのか、そして最終的に誰が責任を負うのかが明確でなければならない」。Jumioのデジタルアイデンティティ責任者であるPhilipp Pointnerは、これを「エージェントが個人に代わって何ができるのかをどう監査すべきかの」前例だと評し、アイデンティティシステムは今や人間のアイデンティティとエージェントの権限を区別しなければならないと強調した。

この区別こそがすべてだ。人間のアイデンティティは「あなたは誰か」に答える。エージェントIDはより難しい問いに答えなければならない。「誰があなたに、何をすることを、どれだけの期間許したのか」だ。

これが単なる官僚主義ではない理由

LLMをツールに接続したことがあるなら、現在の最先端が借り物の認証情報であることはすでに知っているだろう。エージェントはservice accountとして動作するか、あるいはもっと悪いことに、人間のOAuth tokenや環境変数にコピーされた長命なAPI keyを使って動作する。人間中心のIAMは、たまにログインして同意画面をクリックし、人間の速度で行動する人を前提に作られている。エージェントは一度もログインせず、誰かにアクセス権を渡され、毎分数千回の行動をする。

だからエージェントが何か間違ったことをすると、ログにはservice accountがやったとか、人間がやったと記録される。リクエストに載っていたのがそのtokenだからだ。行動は本物だが、説明責任は虚構だ。エージェントに固有のアイデンティティを与え、その行動をそのエージェントに帰属させ、それを承認した者まで追跡できるようにするというエストニアの直感は、まさに埋めるべきギャップそのものだ。直感は正しい。コストがかかるのは実装の部分だ。

エージェントIDが背負わなければならない三つのこと

1. 単なる名前ではなく、スコープを持つ権限

「これはエージェントXだ」と証明するだけで、それ以外に何もないIDはネームタグにすぎない。価値はそこに紐づけられた権限にある。どのシステム、どの操作、どのデータ、どのような条件のもとで、どれだけの支出やレート制限を伴うのか。これがプレスリリースで「明確に定義された範囲」と曖昧に示している部分であり、正しく作るのに何年もかかる部分だ。なぜなら広すぎるスコープは元の問題を再現し、狭すぎるスコープはエージェントを役立たずにするからだ。すでにこれに対するプリミティブはある。OAuth scopes、workload identity、capability tokenだ。だが国家のIDレイヤーはそれらと相互運用しなければならず、第四の競合する真実の源として上に乗ってはならない。

2. 実際に追跡できる委任のチェーン

「誰が誰の代わりに行動しているのか」は一段階の話ではない。人がエージェントを承認し、エージェントがツールを呼び出し、ツールがサブエージェントを生成し、サブエージェントがサードパーティのAPIに到達する。各段階で権限は狭まる、あるいは狭まるべきだ。IDがこのチェーンを捉えなければ、機械の速度で古典的なconfused-deputy problemが起きる。正当なアクセス権を持つコンポーネントが、他者の目的のためにそれを使うよう騙され、監査ログにはきれいで承認済みの呼び出しが記録される。エージェントIDは、最終的な行為者だけでなく、そのチェーンを記録し制約する能力の分だけしか価値を持たない。

3. 人間に行き着く説明責任

ここが技術では解決できない部分だ。エージェントにID、ウォレット、スコープを与えることはできる。だがそのエージェントが口座を空にしたり、不当な契約に署名したりしたとき、責任はエージェントで止まらない。それは人や組織にまで遡る。IDはその遡及を可能にする仕組みであり、それは良いことだ。だがIDは誰が責任を負うのかを決めはしない。委任した本人なのか、エージェントを作った開発者なのか、モデルを提供したベンダーなのか。エストニアはその問いを早い段階で表に出すという責任ある行動を取っている。誰もまだきれいな答えを持っていない。

アイデンティティは必要だが、十分ではない

報道で引用されたBCGの最近の一節が、より深い問題を突いている。「価値観はルールではない。それは何千もの人間の判断を通じて形成される信念と原則であり、文脈、例外、そして前例によって形作られる」。ID codeはルールをエンコードできる。だが判断はエンコードできない。完璧でスコープも監査も完全なアイデンティティを持つエージェントでも、技術的には許可されているが明らかに間違った行動を取りうる。アイデンティティが与えてくれるのは帰属と取り消しだ。良い振る舞いは与えてくれない。それらは別の問題であり、両者を混同すると、立派なバッジを持っているという理由だけで、設計が保証する以上にエージェントを信頼してしまうことになる。

エージェントを構築するなら、これが意味すること

この考え方を適用するために政府の登録制度を待つ必要はない。エストニアの計画は、あなたがすでに行っているべき選択の国家規模版にすぎない。

  • すべてのエージェントに固有のアイデンティティを与える。 共有のservice accountでも、人間のtokenでもなく。エージェント1つにつき1つのprincipalとし、その行動がそのエージェント単独に帰属するようにする。
  • タスクにスコープを絞り、そして失効させる。 短命で範囲の狭い認証情報は、長命なkeyに毎回勝る。読み取りしか必要としないエージェントが、書き込み可能なtokenを持つべきではない。
  • 呼び出しだけでなく、委任のチェーンをログに残す。 誰がどのスコープでエージェントを承認したかを記録し、「誰が誰の代わりに行動しているのか」がフォレンジック調査ではなくクエリで分かるようにする。
  • 取り消しを即座にできるようにする。 エージェントが不正な動作をしたとき真っ先に欲しいのは、数秒で効くオフスイッチであって、1日かかるkeyのローテーションではない。
  • 意図的に人間に説明責任を持たせる。 デプロイ前に、誰がそのエージェントの行動を所有するのかを決める。組織図がインシデント中にそれを発見するような事態を許してはならない。

機械の速度で動作するエージェントには組み込みの説明責任が必要だというエストニアの主張は正しいし、アイデンティティがその出発点だという点も正しい。ただし難易度の順序を見誤らないことだ。IDを発行することは発表にすぎない。権限を結びつけ、委任を追跡し、誰がエージェントの責任を負うのかを決めることが本当の仕事だ。そしてそれは、ツールを使うモデルを配線する小さなチームであろうと、エージェント経済全体にコードを発行する国家であろうと、同じ仕事なのだ。

次に読む

エージェントを安全に運用するためのインフラとプラットフォームの側面については、クラウドのフィールドノートを ercan.cloud で公開している。AI、アイデンティティ、プラットフォーム関連のコンサルティングについて、あるいはただ挨拶したいだけでも、まずは ercanermis.com から。