テザーがAI向けウォレットの仕組みを解説｜残る設計上の課題とは

テザーが9月3日に公開した解説で、同社のウォレット開発キット（WDK）で作られたコマンドライン版ウォレットの仕組みが示されました。

利用者が時間制限付きでウォレットを解錠すると、その間はソフトウェアが個々の支払いごとに承認を得なくても取引を要求できます。鍵を利用者の手元に置くことと、エージェントに与える支出権限を決めることは別の設計判断になります。

解錠前のシードはAES-256-GCMで暗号化され、鍵はscryptで導出されます。macOSとLinuxでは常駐プロセスの接続口がOS上の所有者に限定される一方、プログラムごとの資格情報はありません。同じ利用者として動くプロセスが接続口に到達できれば、パスフレーズを再入力せずに署名を要求できます。既定のセッションは解錠から5分で早期の施錠や有効期限の無効化も選べます。

送金ツールは既定で試行モードとなり、送金先や金額、手数料を確認してから実行する手順が推奨されています。ただし常駐プロセスは、事前の確認が行われた証明を求めません。宣言された書き込み操作を呼び出す別の経路もあるため、丁寧な承認画面を用意しても他の経路を制御しなければ、支出権限は定まらないことになります。

開発キットにはALLOW/DENY形式のローカルな取引ポリシーがありますが、価格の取得や累積支出の記録は自動化されていません。1日あたりの上限を設けるには、アプリケーション側で過去の支出を保存し、同時実行を整合的に扱う必要があります。

エージェントに委ねた権限を利用者の理解と一致させる責任は、製品側に残ることになりそうです。

記事ソース：資料