エージェントスタックは4層構成です。ほとんどのデプロイは3層が欠けています。

アイデンティティ、評判、権限、そして支払いはオンチェーンで存在する必要があります。多くの本番デプロイでは、まだそうなっておらず、これはコンプライアンスの後付けではなく、アーキテクチャ上の問題です。

私は本番エージェントのデプロイが実際にどのように配線されているかを見るのに多くの時間を費やしていますが、パターンはしばしば同じです：モデルは有能で、オーケストレーションフレームワークは妥当ですが、認証レイヤーは依然として数か月間ローテーションされていない共有APIキーです。

自律エージェントのインフラは、その上で動作するモデルに追いついていません。エージェントスタックは、チェーンにネイティブである必要がある4つのコンポーネント、すなわちアイデンティティ、評判、権限、そして支払いで構成されています。私が見る多くの本番デプロイでは、これらは事後的に追加されているか、そもそも存在しないことさえあります。

そしてこれは、規制された金融分野で特に重要です。トークン化された証券で取引したり、財務アクションを承認したり、ポジション間で配分したりできるエージェントは、何が許可されているか、誰が許可したか、どの範囲で、そしてその権限のオンチェーン記録がどこにあるかを示す必要があります。ほとんどのデプロイは今日それを明確に答えることができません。その記録がなければ、エージェント自体が監査およびコンプライアンスリスクとなります。

共有APIキーが誤ったプリミティブである理由

ほとんどのエージェントデプロイがSaaSから継承する認証モデルは、ヘッダーで渡される共有シークレットです。これは呼び出し元サービスを認証しますが、呼び出しを行う特定のエージェントやそのエージェントが許可されていることについては何も示さず、規制当局が検査できる形で監査に耐える記録も残しません。すべてのエージェントアクションはキーを保持している者にのみ帰属するため、実際にはエージェントが複数、またはオペレーターが複数になると帰属が崩壊します。

代替案は、署名ベースのリクエストごとの決済です。各リクエストはエージェント自身のウォレットで署名され、呼び出し時に暗号的に決済されます。これは x402 が構築された目的であり、認証と支払いが一体化されています。これにより、機関はどのウォレットがいつ何を行い、何に対して支払ったかという記録を得られ、監査の精査に耐える台帳となります。

アイデンティティのギャップ

ERC-8004 は、信頼できないエージェントのためのオンチェーンアイデンティティを定義しています：エージェントが管理ウォレット、サービスエンドポイント、モデル参照とともに登録されるレジストリです。現在、そのエージェントはベンダーのインフラ内で動作する不透明なプロセスに過ぎません。レジストリエントリにより、検証可能な起源を持つファーストクラスのオンチェーンアクターとなり、スマートコントラクトやコンプライアンスダッシュボードが仲介者を信頼せずに直接チェックできます。

評判レイヤーはこれに基づいて構築されます。ERC-8004レジストリに書き込まれたフィードバックシグナルは不変で、タイムスタンプが付与され、帰属可能です。エージェントに対して信頼判断を行いたいシステムは、そのレジストリを直接読み取ることができます。ベンダー管理のスコアやDiscordの評価とは異なり、ここでの信頼はデータベースを管理する者ではなく、ネットワークの属性です。

これら両レイヤーは、特別なエンジニアリングなしで今日実装可能です。多くのデプロイがそれらを持たないのは、最も抵抗の少ない実装パスが依然としてエージェントをサービスアカウントとして扱い、ファーストクラスのアクターとしないからです。プロトタイプでの合理的なショートカットが、本番環境で複合的なアーキテクチャ負債となります。

権限の問題は、規制された金融が他のすべてと分岐する場所です

アイデンティティと評判はエージェントが誰であり、どのように振る舞ってきたかを示しますが、エージェントが何を許可されているかは確立しません。多くのエージェントユースケースでは、アプリケーション層のコントロールでそのギャップを埋められます。規制資産で動作するエージェントにとって、認可の問題は法的な問題になります。その回答は規制当局を満足させる形で存在する必要があります。

ERC-8226、規制エージェント権限標準（RAMS）は、このギャップを埋めるよう設計されています。RAMS はエージェントのアイデンティティとトークンレベルのコンプライアンスフレームワークの間に位置するコンプライアンス委任レイヤーを定義します。KYC 認証された主体がエージェントに対し、定義されたスコープ、管轄、価値上限、期限日を持つ権限を付与します。実際には、決済前にチェックできるオンチェーンの委任状のように機能します。規制対象トークンコントラクトは、決済が行われる前に、事前転送コンプライアンスフック内でその権限を原子的に検証します。

この設計は2つのインターフェースで実装されます。`ComplianceProvider` は任意の KYC または証明オペレーターによって実装され、特定スコープに対する主体の適格性を保証します。`IAgentMandate` は権限の付与、延長、取り消し、実行、規制当局レベルの凍結を記録するレジストリです。強制は `recordExecution` を通じて行われ、転送時にアクティブな権限の上限をチェックし、取引がそれらを超える場合はリバートします。

このアーキテクチャは ERC-8004 のアイデンティティと、ERC-7943 のようなトークンコンプライアンスフレームワークの間に位置し、どちらも置き換えるものではありません。アイデンティティはエージェントが存在し検証可能であることを示し、トークンコンプライアンスは主体がこの特定資産を保有できることを示します。RAMS は両者がカバーしない部分、すなわちこの主体からの権限、特定スコープ、これらの上限、そしてこの日付までを追加します。現在は PDF やバックオフィスのスプレッドシートにしか存在しない法的に執行可能な委任レイヤーがオンチェーンに移行し、転送時に実際に執行できるようになります。

準備と実行の分離は摩擦ではない

ある設計決定は直接的に擁護されるべきです：取引の準備を署名およびブロードキャストから分離すること。エージェントをよりシームレスに感じさせようとする多くのシステムでこの分離は削除されます。

本能的にこれらを単一ステップに統合したくなりますが、効率的に感じるからです。しかし、準備とブロードキャストの間のギャップこそが機関の監視が必要な場所です。ここでコンプライアンス担当者は、チェーンがそれを認識する前にエージェントが何をしようとしているかをレビューし、RAMS 権限チェックは署名が生成される前に準備されたペイロードをアクティブなスコープ、価値上限、管轄と照合し、CFO はエージェントがステージングしたがまだコミットされていない財務アクションを承認します。

有意な規模で自律エージェントをデプロイする多くの機関は、欠如していることに気付くと最終的にこの分離を再構築します。最初のコンプライアンスレビューを通過させるためのレトロフィットではなく、意図的なアーキテクチャプリミティブとして組み込むことが重要です。

スタックが完全であるときの姿

4つのレイヤーがすべて整うと、クリーンに構成されます。ERC-8004 はエージェントのアイデンティティとオンチェーン評判を固定し、ERC-8226 は各エージェントが誰の代理で何をできるかを制限する権限レイヤーを追加します。 x402 は決済を処理し、各リクエストに署名することで全てのアクションが帰属可能かつ監査可能になります。その下で、ERC-7943 のような規制資産フレームワークは、転送時に主体の適格性とエージェントのアクティブな権限の両方に対してコンプライアンスを強制します。

これらのコンポーネントは成熟度が異なりますが、どれも純粋に理論的なものではありません。ERC-8004 はデプロイ可能なアイデンティティと評判プリミティブを備えたドラフト標準トラック ERC です。ERC-7943 は最終的な Ethereum 標準です。ERC-8226 は標準トラック上にあり、コアインターフェースは初期実装に十分安定しています。x402 は稼働中で、ヒトとエージェント向けのプログラム的 HTTP 支払いを前提に設計されています。

この点を正しく実装できるチームは、今すぐこのスタックに向けて構築することも、監査とコンプライアンスの圧力がレトロフィットを強いるまで待つこともできます。この点を正しく実装できる機関は、権限とアイデンティティのレイヤーを KYC やカストディと同様に、初日からインフラ要件として扱う機関です。規制当局はまだすべての要素を明示的に要求していないかもしれませんが、この分野で本番システムを構築しているチームは、事後にこれらのコントロールを追加するコストがいかに高いかをすでに知っています。