Agent Identity

AgentになぜVerifiable Identityが必要ですか？匿名操作にはどのようなセキュリティ問題がありますか？

単一Agentシステムでは、Agentのアイデンティティは保持する秘密鍵に対応するウォレットアドレスです。しかし以下のシナリオでは、Agentにはより完全なアイデンティティメカニズムが必要です：

シナリオ1：マルチAgentシステムの信頼問題 OrchestratorがSub-agentに命令を送るとき、Sub-agentは「この命令は実際にOrchestratorから来たもので、なりすまし攻撃者ではない」をどのように確認できますか？検証可能なアイデンティティにより、Sub-agentは「この命令の送信元が信頼するOrchestrator」を検証できます（例：Orchestratorの署名検証）。

シナリオ2：クロスシステムのAgent協力 あなたのAgentが他のサービスのAgentと協力する必要がある場合（A2Aプロトコルシナリオなど）、相手のAgentはリクエストを信頼するかどうかを決定する前に「あなたのAgentが誰で何の権限があるか」を知る必要があります。

シナリオ3：責任追跡 オンチェーンAgentシステムで予期しない操作が発生した場合、「どのAgentインスタンスがこの操作を実行したか、誰の承認の下で」に答えられる必要があります。検証可能なアイデンティティなしでは、事後の責任追跡はほぼ不可能です。

DIDとVerifiable Credentials（VC）はAgentでどのように具体的に使用されますか？

DID（Decentralized Identifier）はW3C標準の分散型識別子フォーマットで、中央集権的なアイデンティティプロバイダーに依存しません。DIDはこのように見えます：did:ethr:0x1234...（イーサリアムアドレス型DID）またはdid:key:z6MkhaXg...（鍵ペア型DID）。

AgentのDID使用シナリオ：

• Agentはシステム初期化時にDIDを生成します（通常は鍵ペアに基づく）
• このDIDはAgentのデプロイヤー（あなた）によってDID Registryに登録され、「このDIDはAgent X、時刻Yに資産Zを操作する権限が付与された」という主張に関連付けられます
• Agentが他のシステムと相互作用するとき、このDIDを提示します；相手はDID Documentを解析してAgentの主張（アイデンティティと承認）を検証できます

Verifiable Credentials（VC）は信頼できる発行者（Issuer）によって署名されたDIDに添付された主張です。Agentシナリオでは、VCは「このAgent（DID = xyz）はAaveプロトコル上で$10,000以下のUSDC預け入れ/引き出し操作を実行する権限を付与され、有効期限は2026-12-31まで」と表現できます。

現在の成熟度：DIDとVCのオンチェーンAgentへの応用はまだ初期段階です。実際には多くのシステムがより単純なメカニズム（EIP-712構造化署名など）をAgent間のアイデンティティ検証に使用します。

オンチェーンAgentのアイデンティティとウォレットアドレスは同じものですか？どのような場合に区別が必要ですか？

オンチェーンAgentの最も基本的な「オンチェーンアイデンティティ」はその操作ウォレットアドレスです。しかし「Agentアイデンティティ = ウォレットアドレス」と同一視することは、いくつかの状況では不十分です：

区別が必要なケース1：複数のAgentインスタンスが1つのウォレットを共有する セキュリティ設計上の理由（ERC-4337マルチ署名ウォレットなど）から、複数のAgentインスタンスが同じ操作ウォレットアドレスを共有することがあります。この設計では「アドレス」はAgent全体のクラスターの資金アカウントを表し、特定のAgentインスタンスのアイデンティティではありません。

区別が必要なケース2：AgentがSafe（Gnosis Safe）マルチ署名ウォレットを使用する Safeマルチ署名はよく使われるオンチェーンAgentのセキュリティアーキテクチャです——2つのアドレスがあります：Safeアドレス（資金保持）とAgent EOAアドレス（Agentの操作アイデンティティ）——混同すべきではありません。

区別が必要なケース3：Agentが操作鍵をローテーションする Agentの「論理的アイデンティティ」（DIDまたは高レベルのマルチシグアドレス）と「操作アドレス」を分離するのが良い設計です——操作アドレスはローテーション可能ですが、論理的アイデンティティは一定に保たれ、信頼関係は論理的アイデンティティに基づいて構築されます。

Agent Identityの最小限の実行可能な実装は何ですか？DIDを使わずに、より簡単なアプローチはありますか？

ほとんどの個人オンチェーンAgent開発者にとって、完全なDID + VC実装は過度に複雑でコスト対効果が低いです。以下はDID/VCを使わずに最もコアなセキュリティ問題（OrchestratorとSub-agent間の命令検証）を解決する「最小限の実行可能なAgent Identity」設計です：

最小限の実行可能なアプローチ：EIP-712構造化署名 + 命令Nonce

Orchestratorは各Sub-agentへの命令にEIP-712構造化署名を作成します：{instruction_type: 'withdraw', protocol: 'aave', amount: 5000, nonce: 12345, expires_at: 1735689600}。Sub-agentは命令を実行する前に：署名がOrchestratorの鍵から来たことを検証；nonceがすでに使用されていないことを検証（リプレイ攻撃を防ぐ）；expires_atが現在時刻より後であることを検証（期限切れの命令を防ぐ）。

コスト：Pythonではeth_accountライブラリ（Web3.pyの一部、無料）だけが必要です；追加のインフラは不要です。これはDIDの複雑さを導入せずに個人のオンチェーンAgent開発者が達成できる合理的なセキュリティレベルです。