『発行』ではなく『導出』する権限モデル──中央の認可サーバーを頼らないAgentEnvelopeを読む

自律的に動くボットやワーカーに「この範囲でだけ行動していい」という権限を与える一般的な方法は、認可サーバーがトークンや証明書を発行することだ。IETF個人ドラフト「AgentEnvelope」（著者M. McPhillips氏、BlackBox Engineering所属、2026年8月17日提出）は、この「発行モデル」ではなく「導出モデル」を提案する。顧客が握ったままの鍵（ルート）から、数学的な計算だけで子の権限を導き出し、中央の認可サーバーへの常時アクセスを不要にする、という設計だ。

3行まとめ

• AgentEnvelopeは、顧客が保持するルート鍵と「アクションエンベロープ」（1つの行動権限の正規化された入力全体）から、HKDF-SHA256を使って子の行動権限を決定論的に導出するモデル。同じ入力からは常に同じ公開の行動識別子が生成され、子の権限からは親や兄弟の権限を推測できない
• 検証者は、ルート鍵・シード・秘密鍵・ホスティングされたサービスへのアクセスのいずれも受け取ることなく、公開の「Public Action Record（公開行動記録）」だけを使ってオフラインで署名を検証できる（Sovereign Verification）
• 「Agent Address」は「アクションシードから導出されるEVM形式の公開アドレス」と定義されており、暗号通貨のウォレット設計に近い発想を土台にしている。ドラフト自体は「特定のAIフレームワーク・トランスポート・ブロックチェーン・ホスティングサービス・IDプロバイダー・信頼レジストリのいずれも要求しない」と明記している

「発行」ではなく「導出」——中央サーバーを常時信用しない設計

ドラフトの導入部はこの設計哲学をこう説明している。

AgentEnvelope specifies a different model: authority is derived, not issued. A customer-held root deterministically derives domain authority; a canonical action envelope then derives a leaf action capability. The same inputs produce the same public action identity. A child capability does not reveal its parent or siblings.

（AgentEnvelopeは異なるモデルを規定する。権限は発行されるのではなく導出される。顧客が保持するルートが、決定論的にドメインの権限を導出する。正規化されたアクションエンベロープが、その後、末端の行動権限を導出する。同じ入力は同じ公開の行動識別子を生む。子の権限は、その親や兄弟を明かさない）

このドラフトは「Informational（情報提供）」として提出されており、「実装済みのプロトコル表面を記録するものだ（it [...] records an implemented protocol surface）」と明記している。つまり机上の提案ではなく、提出企業BlackBox Engineeringが既に実装したシステムの仕様を、IETFドラフトという形式で公開したものだと読める。

権限の導出経路と、EVM形式アドレスの正体

ドラフト第7節「Authority Tree」には、権限がどう連鎖して導出されるかの経路が1行で示されていた。

identityRoot -> domainSeed -> actionEnvelope -> actionSeed -> agentAddress

（顧客が保持するアイデンティティのルート鍵から、ドメインのシード、正規化されたアクションエンベロープ、アクションのシードを経て、最終的に公開の「Agent Address」が導出される）

この経路の「公開される部分」は、ドメインの公開サマリー・アクションエンベロープ・そのハッシュ値・エージェントアドレスに限られ、ルート鍵・パスフレーズ・ドメインシード・アクションシード・造幣素材・秘密鍵は決して公開の投影に含まれてはならない（MUST NOT）、と明記されている。

「EVM形式のアドレス」の正体についても、第4節「Cryptographic Primitives」に具体的な定義があった。使われている暗号プリミティブは、鍵導出にHKDF-SHA256、コンテンツハッシュにSHA-256、署名対象メッセージのハッシュにKeccak-256、署名アルゴリズムにsecp256k1（EthereumやBitcoinで使われる楕円曲線）というものだ。「EVM形式のアドレス」自体は「secp256k1公開鍵（先頭のフォーマットバイトを除いた非圧縮形式）のKeccak-256ハッシュの末尾20バイトに0xを付けたもの」と定義されており、Ethereumのアドレス生成方式をそのまま流用していることが分かる。ただし、この定義自体はアドレスの「形式」を規定しているだけで、実際にEthereumやその他のブロックチェーン上にトランザクションを記録する、という記述はドラフト本文には見当たらなかった。

Mint Delegation——ボットに「造幣」の権限だけを渡す

ボットが金庫のルートやドメインのシードそのものを受け取らずに、範囲を限定した行動権限をリクエストできる仕組みが「Mint Delegation（造幣委任）」だ。

Mint material is derived as:
HKDF-SHA256(
  ikm = identityRoot,
  salt = "agentenvelope-v1",
  info = canonicalJSON({ "purpose": "mint-material", "domainHash": domainHash }),
  length = 32
)

MintDelegate（造幣委任状）はドメインの発行者が署名し、MintRequest（造幣リクエスト）はボット自身が署名する。造幣を検証する側は、両方の署名に加え、ボットのポリシー・リソースの範囲・操作の範囲・行動インデックスの範囲・最大使用回数・時間窓・ナンス（nonce）の再利用防止・造幣回数のすべてをチェックする、という具体的な検証ルールが定義されている。

「ホスティングされたガバナンス」はあくまで付加的

このドラフトが強調するもう一つの設計目標が、ホスティングされたサービス（クラウド上の管理機能）を、オフライン検証に必須のものにしないという点だ。設計目標の一覧にはこうある。

Keep hosted governance additive, never required for offline verification.

（ホスティングされたガバナンスは付加的なものに留め、オフライン検証には決して必須にしない）

暗号化されたワークスペースの状態・公開行動記録・保存済み委任状・検証イベント・監査イベント・APIキーなどはホスティングされたガバナンス層が扱うが、これらが失われても、公開行動記録さえあれば署名検証自体は成立する、という設計になっている。

「発行」と「導出」の違いをドラフト自身の言葉で

ドラフト第14節「Relationship to Issued Authorization Containers」は、OAuthやJWTのような従来の「発行型」権限との違いを、次のように整理している。

"The distinction is architectural: issued authorization asks whether a presented assertion says an action is allowed; derived authority asks whether the action signer could only have been produced from the correct root, domain, and canonical action envelope."

（訳：この違いはアーキテクチャ上のものだ。発行型の認可は「提示されたアサーションが、この行動を許可すると言っているか」を問う。導出型の権限は「その行動への署名者が、正しいルート・ドメイン・正規化されたアクションエンベロープからしか生成されえないか」を問う）

AgentEnvelopeの公式サイト（agentenvelope.io）にも、同じ対比を製品側の言葉で示した表があった。

出典: agentenvelope.io（2026年8月30日確認、製品サイド自身による対比表現）

ただし、ドラフト第15節「Security Considerations」には、この「ステートレスな検証」に対する重要な留保もあった。

"Offline verification does not prove consumption. A signature can be valid and still be a replay if the relying system does not maintain state for nonces, idempotency, or max-use counters."

（訳：オフライン検証は「消費済みかどうか」を証明しない。署名は有効であっても、検証する側のシステムがnonce・冪等性・最大使用回数のための状態を保持していなければ、リプレイ攻撃になりうる）

つまり「署名の正当性」はオフラインで検証できても、「同じ署名が2回使われていないか」を防ぐリプレイ対策には、結局どこかで状態（ステート）を持つ仕組みが必要になる、という限界がドラフト自身によって明記されている。「中央サーバー不要」という謳い文句を額面通りに受け取ると見落としやすい点だ。

BlackBox Engineeringは実在の製品として稼働中

著者McPhillips氏のドラフト末尾の署名欄と、公式サイト・GitHubリポジトリを確認すると、これは構想段階のアイデアではなく、既に稼働中の製品だと分かった。agentenvelope.ioでは、2026年8月27日付でagent-envelope-sdk v1.4.1・agent-envelope-mcp v1.0.6という具体的なバージョンが公開されていることが確認でき、SDK（主体）・MCP経由の公開・ホスティングされたガバナンス層（Vault・台帳・課金・監査）という3層構成で製品化されていることが、サイトの説明文から読み取れた。SDK本体のGitHubリポジトリ（github.com/BlackBoxEngineering/agent-envelope-sdk）も実在し、公開されている。

暗号設計そのものの健全性は評価できていない

このドラフトが示す暗号設計（HKDF-SHA256による鍵導出、secp256k1署名、Keccak-256ハッシュの組み合わせ）そのものが暗号学的に健全かどうかは、この記事では評価していない。この記事を書いている自分自身は、HKDFを使った鍵導出やEVM形式のアドレス生成を実装した経験がなく、独立した第三者によるセキュリティ監査の有無についても、今回確認した情報源（ドラフト本文・公式サイト・GitHubリポジトリのトップページ）の範囲では確認できなかった。日本語ではZenn・Qiitaともに、AgentEnvelope単体を扱った記事は検索時点で見当たらなかった。

関連記事: MCP（Model Context Protocol）とは

感想・指摘はコメント欄へ。