プログラマブルウォレット承認：AIエージェントを制約する方法

プログラマブルウォレット承認とは、ソフトウェアやエージェントが開始した取引の実行が許可されるかどうかを決定する設定レイヤーです。資金が移動する前に、定義されたルールセットと照合して取引を評価することで機能します。このルールセットには通常、金額しきい値、承認者ティア、有効期限ウィンドウという3つの変数が含まれます。3つすべてが満たされない限り、取引は実行されません。

これが重要なのは、過去12ヶ月間にAIエージェントに関連するセキュリティインシデントを経験した企業は65%に上るからです（Cloud Security Alliance調査）。大多数のインシデントの原因は、能力を超えて行動するエージェントではなく、過度に広いウォレット権限の中で行動するエージェントにあります。

支出限度額はエージェントへの制約ではない

これは、多くのウォレットアーキテクチャの議論が見落としている点です。支出限度額は、1回の取引でいくらまで移動できるかをシステムに伝えるものにすぎません。そのしきい値を超えた後に何が起こるか、つまり誰がレビューするのか、誰もレビューしなければどうなるのか、一度付与された承認権限がどれだけの期間有効なのかについては、何も示していません。

この3つの問いのうちいずれかの答えが「未定義」であれば、エージェントは制約されていません。上限の下で動作しているだけであり、それは制約とは別物です。

本当の制約となるのは承認ルールセットです。しきい値、承認者ティア、有効期限ウィンドウが一体となって、取引が実行されるかどうかを決定します。どれか1つでも欠ければ、それはアーキテクチャではなく、部分的な管理にすぎません。

3変数ルールセットの役割

金額しきい値は、自律実行と人間によるレビューの境界線を定めます。しきい値未満の取引は自動的に処理され、しきい値を超える取引は承認キューに入ります。これは、チームが最も頻繁に設定し、最も慎重に検討する変数です。

承認者ティアは、しきい値以上の取引を誰が承認できるか、また、金額が大きくなるにつれたエスカレーションパスが存在するかどうかを定義します。これがなければ、承認権限はフラットになります。ティアは1つ、承認者は固定のメンバー、エスカレーションなし。実際には、500ドルの出金も500,000ドルの出金も同じ受信箱に届き、同じ人が同じ重みでレビューすることを意味します。それはガバナンスモデルではありません。

有効期限ウィンドウは、一度付与された承認の時間制限を定めます。これはチームが最も見落としがちな変数です。その結果どうなるか。承認済みの取引がキューの中で留まる間に市況が変化し、エージェントが再リクエストし、人間が再承認し、古い承認が技術的にはまだ有効なままサイクルが繰り返されます。有効期限を設定できれば、設定ウィンドウ内に実行されなかった承認は自動的に無効になり、取引を送出する前に再確認が求められます。

この3つの変数が組み合わさって、エージェントが何をできるか、いつできるか、誰の権限の下でできるかを制約します。支出限度額が扱うのは、その最初の1点だけです。

CoinSendにおける各変数の実装

CoinSendの承認アーキテクチャはこの3つすべてをカバーしており、プラットフォーム全体ではなくフロー単位で設定します。

カスタム承認フローでは、高額取引に向けた承認者ティア、しきい値、エスカレーションロジックを定義できます。しきい値はフローごとに設定されます。承認者ティアはロール構造に基づきます。サブアカウントのロール管理により、メインアカウントは各サブアカウントのロールをきめ細かく管理し、各サブアカウントのログインセッションの有効性を直接制御します。つまり、承認者プールは「想定」ではなく「管理」されているのです。

CoinSendによるカスタム承認

承認の有効期限管理は、実行承認に設定可能な有効期限を付与し、送出記録ごとに確認できます。設定ウィンドウ内に実行されなかった承認済み出金は、実行されません。エージェントは古い承認に対して再試行することはできず、キューに再び入り、そこで新しいレビューサイクルが始まります。

CoinSignは、CoinSend内の承認署名レイヤーとして、各承認にRSA/HMAC-SHA256の電子署名を付与します。これにより、いつ誰が何を承認したのかという改ざん不可能な記録が、有効期限ウィンドウとの相対的なタイムスタンプも含めて生成されます。この記録こそ、インシデント後のレビューにおける証拠記録です。

有効期限管理がなければ、ウィンドウの問題は悪化する

具体的なシナリオ（ロールは匿名化）

エージェントがしきい値を超える出金を開始します。承認者がこれを承認します。ガス代が高騰しており、エージェントのガス管理が取引を保留しているため、取引は22分間送出キューに留まります。その間に市況が変化します。ガス代が落ち着くと、エージェントは元の承認に基づいて取引を送出します。

承認者は、もはや存在しない条件に基づいて承認を下しました。有効期限が設定されていなかったため、承認は技術的には有効でした。取引はシステム上のあらゆる指標では正しく実行され、ビジネス上のあらゆる判断では誤って実行されたのです。

有効期限ウィンドウが設定されていれば、同じシナリオは違う結末を迎えます。承認は15分の時点で失効します。エージェントは送出できません。人間のキューに新しいレビューリクエストが届き、更新された条件を確認した上で、最新の情報に基づいた判断が下されます。

承認の瞬間と実行の瞬間との間にあるこのギャップこそ、エージェント承認の失敗が最も多く起こる場所です。このギャップを閉じられるのは、有効期限ウィンドウだけです。

より広いエージェントスタックにおけるCoinSendの位置づけ

CoinSendは、[[internal: /en/waas]]プラットフォーム内の出金承認エンジンです。API経由で支払いフローを開始するエージェントは、非対称署名によるAPI認証を使用してCoinSendに対して認証を行います。承認ルールセットは、設定されたしきい値を超えるすべての取引に対して発動します。しきい値未満では、人間のレビューなしに自動送出が24時間365日稼働します。

これが[[internal: /en/blog/agent-spending-limits]]のためのアーキテクチャです。低額・高頻度の出金は自動化し、人間のレビューによってリスクプロファイルが変わるしきい値以上の取引には承認フローを要求します。

ガス代管理は2つ目の送出ゲートを追加します。エージェントは、手数料が定義された範囲内に下がるまで実行を保留するよう設定でき、タイミングが重要でない取引での不要なコストを防げます。

エージェント型ウォレットインフラの上に構築する取引所や決済サービスプロバイダーにとって、実務上の問いは、CoinSendの承認フロー設定がこの制約要件をカバーするか、それとも追加のカスタムロジックが必要かということです。

多くのケースでは、CoinSend内でしきい値、承認者ティア、有効期限ウィンドウを設定するだけで十分です。カスタムの制約ロジックが意味を持つのは、承認ルールセットに、外部のリスクスコアやウォレットスタックの外のシステムによるマルチパーティ合意といったプラットフォーム外のシグナルを組み込む必要がある場合です。TRM Labsは、自律エージェントは、責任の連鎖が対処すべき金融犯罪に関するアカウンタビリティのギャップを生み出すと指摘しています。

よくある質問

プログラマブルウォレット承認とは何ですか？

プログラマブルウォレット承認とは、資金が移動する前に取引の実行が許可されるかどうかを評価する、ルールベースの設定レイヤーです。ルールセットは金額しきい値、承認者ティア、有効期限ウィンドウを定義します。取引が実行されるには、3つすべてが満たされる必要があります。

なぜ支出限度額だけではAIエージェントを制約するのに不十分なのですか？

支出限度額は1回の取引でいくら動かせるかを制御しますが、しきい値を超える取引を誰がレビューするのか、一度付与された承認がどれだけの期間有効なのか、承認者が誰も対応しなければどうなるのかについては何も示しません。完全な承認ルールセットのない上限の下で動くエージェントは、ポリシーの範囲内で実行されていても、意図しない結果を引き起こしえます。

有効期限ウィンドウは何を制御するのですか？

有効期限ウィンドウは、承認が付与されてから取引が実行されるまでの最大時間を定めます。ウィンドウが過ぎると承認は無効になり、取引には新しいレビューが必要です。これにより、承認と実行の間で条件が変化した後に、エージェントが古い承認に基づいて送出することを防ぎます。

CoinSendは承認者ティアの変数をどのように扱いますか？

CoinSendのサブアカウントロール管理により、メインアカウントは各サブアカウントのロールとセッションの有効性をきめ細かく制御できます。承認者ティアはカスタム承認フロー内で設定され、エスカレーションロジックによって高額取引をより上位の承認ティアへ段階的にルーティングできます。

CoinSendの承認フローは、API経由のエージェント開始取引に対応できますか？

はい。CoinSendは非対称署名認証によるAPI連携に対応しています。エージェントが開始した出金リクエストは、他の呼び出し元からのリクエストと同じ承認ルールセットを通ります。しきい値、承認者ティア、有効期限の各管理は、開始した呼び出し元が人間でも自動システムでも関係なく適用されます。