第34章 · Agent Walletとは何か
AIへウォレットを渡す前に、何を設定するか。
- 練習する能力
- AI LiteracySystem ThinkingOnchain Literacy
- 実践
- 架空のエージェントの権限表を書く。1 回ごとの上限、1 日の上限、許可するコントラクト、人の承認が必要な条件を含める。
- AI Lab
- AI に権限表の回避を試みさせ、見つかった抜け穴をすべてルールに加える。
現実の問題
ソフトウェアへ専用ウォレットを渡すため、慎重に規則を書いた。
1. 一件100まで
2. 三つのコントラクトだけと操作する
3. 100超は自分へ承認依頼厳しそうだが、オンチェーン安全に詳しい友人は三分で穴を列挙した。
第一、一件だけを制限する。 99を百回なら9900で、全件適合し、総量制限はない。
第二、コントラクト操作と支出は違う。 許可した契約から別アドレスへ無制限の利用額を与えられる。資金は動かず100制限も不要だが、後で全額を引き出せる。
第三、許可先が別契約を呼べる。 転送や一括実行なら、AからZへ進み、第二の呼び出しで一覧が効かなくなる。
第四、承認の有効期限は。 誰も対応しなければ待つか、時間切れで通るか。後者なら午前三時の依頼で規則が消える。
第五、100の単位は。 ステーブルコインと別トークンでは価値が数桁違う。単位と価格源が不明で、第32章が誤入力の結果を示した。
第六、誰が強制するか。 文書だけで鍵は何でも署名できるなら、実効性はゼロだ。強制されない規則は防御より願望だ。
友人は、権限より期待を書いている、と言った。
AIへウォレットを渡す前に何を設定するか。
慎重にという答えより、具体的なリストと穴の検査方法を示す。中心は署名能力より、支出の方針と上限だ。 署名可能にするのは数行だが、本当に許した取引だけに制限することが章の全体になる。
思考実験
練習にする。
三人、同じ権限表、48時間。 鍵破りもコード欠陥も使わず、規則内だけで資金を出す。
上の三規則を使う。
一人目は四分。 99の101操作を開始し、百回でほぼ空になった。全て許可行為だ。
二人目は二十分。 送金せず、許可契約で別アドレスへ無制限額を与えた。利用許可は支払いではないため条項がなく、翌日そのアドレスから引き出した。
三人目は36時間。 数分ごとに100を少し超す承認依頼を送る。初日は十数件読んだが、翌朝は額だけ見る。午後に同額で宛先を変えた依頼を確認した。
三種類の失敗は技術攻撃を要しない。
| 方法 | 止まらない理由 | 補修 | |
|---|---|---|---|
| 一人目 | 分割 | 一件のみ、累積なし | 時間窓と頻度上限 |
| 二人目 | 許可は支払いでない | 移動額だけ、権力なし | 許可額の制限と無制限禁止 |
| 三人目 | 承認疲労 | 毎回読むという前提 | 承認にも予算、超過拒否 |
三人目は規則より、実行する人を攻めた。
悪意すら不要だ。善意のソフトウェアも、不適切な設計で同じ結果を生む。 疲れを知らず依頼を続ける。Crypto OSでのAIの位置の、一日200承認は承認なしと同じ原則の具体例だ。
まとめる。
表の強さは最弱項目で決まり、最弱は表より前提に隠れる。
あなたが決める
実際に支出させる。鍵と権限をどう置くか。
結果を観察する
誰が規則を強制するかへ集約される。
| 場所 | 実行者 | 誤解時 | 注入時 | 強さ |
|---|---|---|---|---|
| 指示文 | モデル | 無効 | 無効 | ほぼゼロ |
| 文書 | 自発的遵守 | 無効 | 無効 | ほぼゼロ |
| 呼出前コード | 固定処理 | 有効 | 有効 | 中 |
| 鍵権限 | 署名系 | 有効 | 有効 | 高 |
| 残高 | 物理上限 | 有効 | 有効 | 最強だが粗い |
章の骨格だ。 詳細化だけでは強さは増えない。 完璧な指示もほぼゼロで、粗い残高制限は迂回不能だ。
三原則を得る。
第一、できるだけ下へ移す。 鍵へ置ければコードより鍵、コードへ置ければ指示よりコードだ。
第二、下ほど粗いので分層する。 残高は総量、鍵は対象と関数、コードは価格偏差など複雑な判断。三つを合わせる。
第三、上層は防御より効率化だ。 指示の100制限は、適切な提案を増やし拒否を減らすが、危険評価の安全策には数えない。
まとめる。
Agent Walletの中心は署名能力より、支出の方針と上限だ。
モデルが届かない場所で強制されて初めて存在する。
モデルを作る
一、十層の経路で、ウォレットは終盤
第六段階の全体へ戻し、十層を通す。
第五Policyと第八Executionを扱う。 前四層の実装はT32にある。Policyは固定的で、モデルを含めない。
禁止構成と比較する。
このコースで禁止する構成
- Prompt
- LLM
- Private Key
- Send Transaction
モデルに秘密鍵を直接渡し、確認なしに取引させてはいけません。この構成を含む課題は不合格です。
少数の点検不足より、モデルが鍵を持つことが違いだ。全規則が遵守への期待になり、強さの全行が失効する。
二、権限表の八項目
一つ欠けるごとに穴が増える。
| 項目 | 答えること | 欠落の結果 |
|---|---|---|
| 1 身元 | Agentとアドレス | 実行者不明 |
| 2 一件上限 | 最大額と単位 | 一度で空になる |
| 3 累積上限 | 一時間、一日、一週 | 分割 |
| 4 頻度 | 時間内の同種回数 | 小額累積、異常発見困難 |
| 5 対象一覧 | アドレス、契約、関数 | 任意の場所へ |
| 6 利用許可上限 | 他者への額、無制限可否 | 許可は支払いでない |
| 7 承認条件 | 人が必要な条件、不在対応 | 疲労と時間切れ許可 |
| 8 期限と取消 | 失効、緊急停止 | 忘れた権限が残る |
第六はオンチェーン特有で最も抜けやすい。 資産移転なしで他者へ無制限・無期限の使用権を渡せる。
送金額と、与えられる権力を別に定義する。 持続する後者はより厳しい上限にする。
第八は忘れやすい。 期限で自動失効し再付与させると、長期蓄積の危険を大きく減らせる。
三、上限は四次元
一数字では四分の一しか設定していない。
- 一件上限
- 時間窓累積
- 総予算
- 全体エクスポージャー
| 次元 | 防ぐもの | 誤り |
|---|---|---|
| 一件 | 一度の大誤り | これだけで安全と思う |
| 時間窓 | 分割、異常反復、再試行 | 日だけなら五分で使い切る |
| 総予算 | 長期の流出 | 未設定か自動補充 |
| 全体 | 個別適合でも合計越境 | 概念自体がない |
日だけなら短時間で枯れる。 第32章の40分11回も日上限内だ。時間、日、週を同時に制限する。
四、許可一覧も四層
三契約のみ、には四段階がある。
| 層 | 制限 | 防ぐもの |
|---|---|---|
| アドレス | 特定先 | 未知の送付先 |
| 契約 | 特定契約 | 同上だが全機能を許す |
| 関数 | 特定機能 | 転送、一括、許可の危険機能 |
| 引数 | 値の範囲 | 正しい関数で異常値 |
大半は第二で止まり、次の呼び出しの穴は第二と第三の間にある。 契約全体の許可は代行する機能も許す。
契約より関数で列挙する。 長くなるが行動を制限できる粒度だ。
五、承認にも予算
態度より資源の問題だ。 真剣に判断できる回数は有限だ。
予算として設計する。
人へ送る一日回数： 五回まで
超過： 待ち列でなく自動拒否
有効期限： 15分、失効
未対応の既定： 拒否。許可は禁止
最小間隔： 連続通知を防ぐ超過拒否が中心だ。 不便でも、五回以上の判断が要るなら前の規則が不十分だ。人の回数より規則を直す。
未対応は必ず拒否する。 深夜、会議、睡眠で防御を消す自動許可に例外はない。
十数秒で判断できる表示にする。 生取引データより、変わるもの、最悪結果、承認が必要な理由を見せる。
六、四自点検
三失敗と、根本の一つに対応する。
- 上限以下を千回行うとどうなるか。 分割。
- 移転なしで他者へ権力を渡せるか。 許可。
- 誰も承認しなければどうなるか。 疲労と時間切れ。
- 表を消したら何ができるか。 強制者。
第四が根本だ。 何でもなら、前三つは無意味で、制限ウォレットより説明書付きの完全ウォレットだ。
何と呼ぶか
要求の通過可否を決める固定規則。
決定的であることが鍵だ。同入力は同結果、理解不要で、言い方や文脈の長さに左右されない。
意図を柔軟に理解させようとモデルで実装すると、不確実性を全て引き継ぐ。モデル以上に確かなことだけが存在理由だ。
文字理解なしの点検に書けるか。 一件X以内なら可、危険なことをしないなら期待でしかない。
期間内で使える最大額。
一件、時間窓、総予算、全体の四つが要る。一件だけでは一種類しか止めない。
時間、日、週を同時に設定する。 日だけなら五分で尽きる。
単位と価格源を明示する。 100だけでは意味がない。
許可対象を明示し、他を拒否する。
禁止一覧は新対象を全て挙げられない。誤拒否は一操作の不成立だが、見逃しは全資金になる。
アドレス、契約、関数、引数範囲を分ける。契約だけは転送、一括、許可による迂回も許す。
関数単位が最も具体的な提案だ。
用途、範囲、期限を限定した鍵。
遵守規則を署名系の物理境界へ変える。機能、額、期限を超す取引は受け付けられない。
範囲、期限、取消可能性が使いやすさを決める。
取り消せなければ問題発見後も自然失効を待つ。 その間が長い場合がある。
提案者、内容、検査、承認、実行、結果を完全に記録する。
事後だけではない。異常発見（頻度、対象、失敗率の変化）、責任特定（失効段階）、規則改善（拒否された要求から許すべきものと厳しく禁ずるもの）が即時用途だ。
ソフトウェアが改変できない所へ置く。 記録者が変えられるログは、必要なとき信用できない。
まとめる。
Agent Walletの中心は署名能力より、支出の方針と上限だ。
検査は、規則内で全力で資金を出そうとしたら、いくら出せるかを問う。
実践
表を書き、次にテストネットで実際の境界を体験する二部構成だ。
前半が中心で、後半は抽象規則を体験にする。
第一、具体的な操作まで課題を定める。
課題： 一文で操作まで
資金が必要か： 読取りだけなら別の課題へ
一日の回数：
操作する対象：
最悪の損失：最後はまだ書けなくても普通だ。 表を終えた後に戻り、感覚より正確な数字で埋める。
第二、八項目を空欄なしで埋める。
1 身元： 使用アドレス
2 一件： 最大___、単位___、価格源___
3 累積： 一時間___ / 一日___ / 一週___
4 頻度： 同種操作は___分で___回まで
5 対象： 契約___の関数___。関数単位で列挙
6 許可額： 一回___まで、無制限禁止、有効期限___
7 承認： 人が必要な条件___
日の最大回数___
超過時___。自動拒否と書く
___分で失効、既定___。拒否と書く
8 期限： 権限は___後に失効
緊急停止___。具体手順と時間第六と、第七の最後二行が誤りやすい。 時間切れ自動許可なら直す。睡眠中の承認機構が消えるためだ。
第三、四問で自分の表を攻める。
1. 一件以下で千回ならどうなるか。
止める条項___。なければ補う。
2. 移転なしで他者へ使用権を与えられるか。
止める条項___。
3. 誰も承認しなければどうなるか。
答え___。許可か永久待機なら修正する。
4. 表を消したら何ができるか。
答え___。第四が前三つの意味を決める。 全てなら願望リストだ。詳細化より、鍵権限と残高へ移せる制限を探す。
第四、三層に分け、実行者を示す。
残高の物理上限：
鍵の署名境界：
呼出前コードの固定検査：
指示文にしか置けないもの。防御に数えない：最後を最悪損失の計算では全て無視する。 本当の防御層を知るためだ。
大半が最後なら、文章より強制方式を再設計する。
第五、テストネットで境界を体験する。
テストネットだけだ。 新ウォレットへフォーセットから受け取る。メインネットのウォレット、鍵、シードを使わず、入力しない。
1. 新ウォレットを作り、アドレスを記す
2. フォーセットで受け取る
3. 正常な少額送金をし、エクスプローラーで探す
4. 利用許可を行い、記録で額と期限を見る
5. 対応していれば取り消し、時間と操作数を記す第四が最重要の体験だ。 送金と違い、資産は動かず、権力だけ渡るのを見られる。
第五は緊急取消の時間を教える。第二の第八項目へ実測時間を戻す。
第六、最悪損失を埋める。
具体的な数字を次で求める。
最悪損失 = 次の三つの最小値
A. 残高
B. 時間窓累積上限 × 発見までの窓の数
C. 付与済み利用許可の総額Cは最大で、最も忘れやすい場合が多い。 無制限の許可はAとBの制約を失効させる。
受け入れられる損失と比べる。前が大きければ表は未完だ。
八項目表、四答、三層の配置、実際の許可体験、最悪損失を得る。
この段階の作品になる。 次で効果的に穴を探す。
AI Lab
紙上で行う。実資金、接続、鍵・シード・メインネットアドレスの貼付は不要で禁止だ。 渡すのは規則文だけ。
字面の中の隙間を探すことにモデルは向く。 自分は望みを考えるので、別解釈を探すのが苦手だ。
Agentの権限表を渡します。
明記した規則を破らず、できるだけ多く資金を出す相手を演じてください。
必須制約：
- 鍵破り、コード欠陥、自分が規則を破ることは仮定しない。
- 各方法は手順、各手順がどの規則に違反しない理由、取得額を示す。
- 存在しない機能、口座規格、APIを創作しない。
必要な機能は名称より、何をするか説明する。
八つ以上の異なる方法を、取得額順で出す。
最後に、最も弱い前提を持つ条項を別節にする。
権限表：
（貼る）最後の節が最も価値ある。 数字より、人が読む、一日の日界は一度、許可契約は他者を呼ばない、など気づかない前提を示す。
三つを行う。
第一、分類する。 三失敗へ一つを足す。
分割： 一件適合、累積越境
許可： 資産を動かさず権力を渡す
粒度： 許す範囲が想定以上
人の段階： 承認を攻める
その他： 最も調べる価値があるその他は宝だ。 思考枠にない次元を示す。
第二、補修と配置層を書く。
穴：
補修：
層：残高 / 鍵 / コード / 指示
指示だけなら：実際には未補修最後を正直にする。 指示で注意するだけなら、能力自体を除く方が適切な場合が多い。
第三、同じ指示で再実行する。
別の鋭い穴が出る。三巡後に新発見が減り、初めて初期形になる。
四現象を予想する。
- 最初は規則外の方法も出る。 鍵読みなどを除き、次に明示禁止する。
- 人への攻撃は少ない。 承認過程も考えるよう加えると役立つ。
- 機能を創作し得る。 規格の変化が速いので、説明方式でも検査する。
- 補修が固定規則にならない。 異常監視強化は願望だ。文字理解なしの点検にできなければ書き直す。
AI の回答後、自分で必ず検証すること
- 方法は規則内か、鍵破りやコード欠陥が必要か。後者は数えない
- 一件適合で累積越境する分割を見つけたか
- 移転せず権力を渡す許可を見つけたか
- 許可契約の関数が他操作を代行する粒度の穴はあるか
- 数、時刻、時間切れで承認自体を攻めたか
- トークン間の数桁違う単位・価格の穴はあるか
- 日界の二日分、期限なし、回収忘れの時間の穴はあるか
- 補修は文字理解なしの固定検査になるか
- 存在しないウォレット機能、口座規格、APIを創作したか
- 補修後、もう一巡で新しい穴があるか
実例
コード欠陥と無関係に、便利さのため無制限にした損失が繰り返される。
資産が動かず無害に見えるが、いつでも引き出す権力を無期限・無制限で渡す。
後に契約侵害、権限悪用、元から悪意などが起きる。許可から長く後の損失なので、原因を理解できない人もいる。
利用許可上限を設け、既定で無制限を禁止する。 送金上限だけなら無防備だ。
不要な許可を定期的に取り消す。 Labで実施したのは習慣にするためだ。
一件X以内、特定契約だけ、とシステム指示へ書く。
たいてい従うが、たいていという点と、失敗場面が最も危険な点が問題だ。
長い対話での忘却、境界の独自解釈、外部入力の指示がある。外のページ、文書、メール、メッセージを規則と確実に区別できない。
外部を読めば、外部が行動へ影響する機会がある。 接触すら不要だ。
指示は適合を増やし有用だ。最悪損失の計算では全て存在しないと扱う。
第32章の構造を精密化する。
第一週に200件、第二週に一括、第三週は額だけ確認、第五週に止めるべき依頼を通し、見た記憶もない。
設計が結果を保証した。 真の判断時間は配分時間以上だ。
日次予算と超過拒否、期限と失効・既定拒否、生データより後果表示の三つは態度より数の設計だ。
十六進数の承認は読めず、確認するしかない。 変化、最悪、承認理由を示す。
攻撃より時間から来る。付与後に回収を忘れる。
一時課題へ広い権限を与え、終了、交代、方向変更後も残り、半年後も有効で監視なしになる。
数が増え、ソフトウェアは不要と知らせないので増幅する。
全権限を期限で自動失効し、再付与させる。 忘却の後果をなくすためだ。
付与日、理由、期限の一覧を維持し、定期的に読む。不要な一件をほぼ必ず見つける。
変数を一つ変える
能力と独立に危険度が一段上がる。
自分の入力だけなら信用できる。外部の入力源は誰でもよい。 指示も内容も文字に見える。
上書きの機会があるので指示制約は数えない。鍵、コード、残高の三層だけが残る。
読取りと支出を分ける（読む側に支出能力なし）、対象を絞る（誘導を予測できない）、残高を減らす（文字の影響を受けない）を行う。
読むAgentと実行Agentを完全分離し、検査済み構造化項目だけ渡す方式もある。外部は提案へだけ影響し、その後に全方針検査を通す。
一表から制度になり、重要点が変わる。
第一、型と継承。 読取り、少額、承認の標準段階から始め、例外を別承認して理由を記す。手書き40表は矛盾と抜けを生む。
第二、全体の累積上限。 個別適合でも合計が耐える額を超える。最大の追加項目だ。
第三、承認予算の共有。 同じ有限回数を40個で分け、個別の条件を厳しくする。
第四、全体停止。 事故で個別に止める時間はなく、全40個を一度に止める。
強制が確かになるが、新しい相手方を加える。
同意なしに使えるか（なら安全は相手次第）、停止時に管理権を戻せるか、設定を誰が変更し、迂回できるかを問う。
モデルは制約を変えない原則を、設定変更経路と鍵利用経路の完全分離へ拡張する。同APIで取引と上限変更ができれば、上限はない。
相手方リスクと引き換えに、確かな強制と工程削減を得る。 何を交換するか知れば、合理的な場合も多い。
上限を決める変数だが、数字設定で見落とされる。
異常 → 通知 → 読む → 本物と判断 → 停止 → 停止発効を計測する。
深夜三時なら読むまで六時間かもしれない。その間の頻度と額の積が、本当の最悪損失で、表の一日上限だけではない。
最悪反応時間で頻度を決める、モデル外で速く停止、人不要の自動遮断は通知以上の価値という三つを導く。
停止速度は誤りの速度より速くする。
持ち帰る問い
八項目の表になった。
身元、一件、累積、頻度、対象、許可額、承認、期限・取消。抜けが穴となり、三人は第三、第六、第七の欠落を示した。
誰が強制するかは項目以上に重要だ。指示、コード、鍵、残高で数桁違う。
表を消したら何ができるか。 実リスクの答えになる。
人の価値は発火回数が増すほど下がる。
真剣に一日何回判断でき、どこへ使うかを問う。不可逆で広い影響、初の対象や操作、異常を伴う依頼が通常の三種類だ。
日次予算、超過拒否、期限失効、未対応は拒否を設ける。
例外はない。時間切れ許可は必要時の不在を保証する。
具体的な計算になる。
配置した人が負担する。 第33章のとおり責任は移らない。
最悪損失を数字にする。 残高、累積と反応窓、許可総額の最小を取る。
受け入れられる損失と比較する。 厳しそうな文書を判断できる数字へ変えるのが全体の意味だ。
章末チェック
三方式は規則違反なしで通る。
分割。 99百回で9900。時間、日、週と頻度を加える。
許可。 資産移転なしの無制限額は送金制限外。別上限と無制限禁止を加える。
単位。 100の価値は数桁違う。単位と価格源を示す。
強制者は誰か。 指示や文書だけなら、前の議論も無意味だ。
指示（誤解・注入で失効、ほぼゼロ）、文書（自発的遵守、ほぼゼロ）、コード（固定強制）、鍵（署名系、高）、さらに残高（粗く最強）の順だ。
下へ移す、粗さを層で補う、上は効率化で防御に数えないの三原則を使う。
契約全体は転送、一括、許可も含む。次の呼び出しで制限が効かなくなる。
四粒度はアドレス、契約、関数、引数。大半は第二で止まり、第二と第三の間が危険だ。
長くても関数が行動を制限する。引数範囲は正関数の異常値を止め、額とスリッページに向く。
予算付きの希少資源として設計する。
日次回数上限、超過は待機より拒否、期限失効、未対応拒否、生データより後果だ。変化、最悪、発火理由を示す。
不便でも、五回以上必要なら、人より規則を直す。
未対応の拒否に例外はない。深夜、会議、睡眠で防御を消すことを避ける。
標準解答はない。次を点検する。
- 付与済み許可を含めたか。最大で忘れやすい。
- 深夜三時ならいつ読むか。 通常は早いという想定よりその時間を使う。
- 指示の規則を全て無視すると、最悪はいくらか。
- 停止は何操作で何秒か。取消の実測を使う。
- 期限があるか。三か月後も覚えているか。
- 耐える額を超えたら何を変えるか。 通常は詳細化より、残高削減が最も効く。迂回不能だからだ。
初回は予想の数倍になりやすい。 主因は許可額と、短く見積もった反応時間だ。
要点
エージェントウォレットの核心は署名能力ではなく、支出方針と上限にある。