どうやって見つけたか
始まりは羨望だった。xAI の GrokBot のエージェントは常時稼働している。常時稼働できるのは、必要なログイン情報がすべてクラウドコンピュータ上に用意されているからだ。体験は正しい。管理権は間違っている。そのログイン情報は、あなたが決して目にすることのないデータセンターに置かれている。私が欲しかったのは、同じ体験を、管理権の境界線をオーナーの側に引いたまま実現することだった。そこで一週間かけて Buzz の実際のコードを掘り下げ、そのうちどれだけがすでに存在するのかを調べた。
予想以上だった。アイデンティティはすでに持ち運べる。Buzz のエージェントは鍵ペアであり、NIP-OA によって、エージェントの公開鍵に対する私の署名済みの承認が、エージェントの発行するすべてのイベントに同乗する。これはどのマシンからでも有効だ。メモリもすでに持ち運べる。NIP-AE はエージェントの状態を暗号化イベントとして保存し、その復号鍵はエージェント自身の鍵から導出される。だから新しいマシンの新しいセッションでも、同じメモリを取得できる。エージェントに必要な三つのもののうち二つは、私が一行も書かないうちから持ち運べる状態だった。
続いて、私たち自身のデプロイで気まずい発見が二つあった。一つ目は、あるツールのクレデンシャルが、手書きのラッパースクリプトを通じてエージェントの 1 体にこっそり持ち込まれていたことだ。どの画面からも一覧できず、どの画面からも取り消せない権限だった。二つ目は経済性だ。Claude のサブスクリプションが発行する OAuth トークンは、それ自体が持ち運べる。しかも 1 ドルあたりの推論量は API 料金より一桁多い。いくつものエージェント系スタートアップが、この利幅を持てずに倒れた。最後に残った錨はクレデンシャルだった。それ以外はすべて、すでに鍵に従っていた。
一文で済む修正
ローテーションは再発行だ。修正はこれに尽きる。NIP-AK は、各クレデンシャルの権限を、オーナーが作成する暗号化されたアドレス指定可能イベント(kind 30180)として、それぞれ固有のブラインドアドレスに保存する。あるアドレスの最新のヘッドが、有効なクレデンシャルだ。同期プロトコルはない。バージョンベクトルもない。突き合わせの処理もない。リレーはもともとアドレスごとに最新のイベントだけを保持している。仕様はそこに乗っかるだけで、それ以上は何もしない。
流れはこうだ。私がラップトップで /login をやり直す。ウォッチャーが新しいトークンに気づき、数秒以内に封印済みのヘッドを再発行する。すべての実行環境はプッシュで収束する。認証に失敗した実行環境は、再試行の前にヘッドを問い合わせ直して自ら回復する。ローテーション 5 回分を眠って過ごしたエージェントも、起きればヘッドはひとつで、追いつくためのプロトコルはない。一度の発行が、すべての場所に行き渡る。
これを支えるルールはひとつ。キーリングのイベントを作成できるのはオーナーだけだ。キーリングは私が書き、エージェントが読むものなので、乗っ取られたエージェントでも、自分に新しいクレデンシャルを与えることも、許可リストを広げることも、他人の鍵を手に入れることもできない。そして MCP の権限の一覧は参考情報ではない。エージェントのツールの許可リストを、目に見える形にしたものだ。与えられたものが、そのままエージェントの持てるもののすべてになる。
なぜ必要なのか
キーリングのパネルが、ラッパースクリプトの時代を終わらせる。クレデンシャルはキーリングを通じてしかエージェントに届かず、キーリングは目に見える。すべての権限、その出どころ、最後にローテーションした時期が、ひとつのパネルに並ぶ。私たちのデプロイでこっそり持ち込まれていた鍵には、どこにも行がなかった。NIP-AK のもとでは、そうした回避策が住める場所はもう残っていない。
マシンは使い捨てになる。エージェントを机の上の mac mini で作っても、フリートのコンテナでも、Kubernetes のポッドでも、Fountain のサンドボックスでも、鍵は同じで、権限も同じだ。アイデンティティは鍵に従う。メモリは鍵に従う。そしていま、クレデンシャルも鍵に従う。プロセスがどこで起動するかは、もはやアーキテクチャ上の判断ではなくなる。
そして経済性がようやく噛み合う。エージェントは 2 本の鍵でできている。仕事に署名するアイデンティティの鍵と、思考の代金を払う推論の鍵で、どちらも持ち運べる。エージェントが使うのはオーナーのサブスクリプションであって、再販業者の利幅ではない。それが、エージェント事業になるか、ただ資金を燃やすだけになるかの違いだ。
現在の状況
NIP-AK はドラフトとして block/buzz PR #6011 で検討を待っている。これは Buzz 自身の前例に倣ったものだ。NIP-AE は仕様が先に入り、実装が後から続いた。この提案も同じ道をたどる。仕様は意図的に小さくしてある。kind がひとつ、スラッグの体系、ブラインドアドレスの導出方法、そしてローテーションのルールだけだ。
この一週間からの補足をひとつ。ドラフトは途中で番号が変わり、kind 30176 から kind 30180 になった。私たちがまだ書いている間に、上流のチームが 30176 とその近くの番号を確保したからだ。これは厄介ごとではない。レジストリ優先のルールが正しさを証明したのだ。kind は、その上に何かを作る前にレジストリで確保しておくこと。さもなければ、誰か別の人が確保する。
同じアイデアについてのフィールドノートは、これで三本続いた。「エージェントは鍵であって、コンピュータではない」はアイデンティティについての論拠を示した。「マシンは使い捨てでいい」は欠けている脚に名前を付けた。そしてこの記事は、その修正を上流に提案する。ドラフトを読み、穴を突き、ローテーションがどこで壊れるかを教えてほしい。誰も曲げようとしていない仕様は、誰もテストしていない仕様だ。