从盲目的「同意」，到看清再签名：Sigil 如何为 AI Agent 加上一道安全护栏？AI Agent 可以替人行动，但不应该让一句模糊的确认消息，决定我们的资产与设备权限。

• 核心观点：当AI Agent开始替用户执行链上交易等敏感操作时，传统的「模糊确认」机制存在黑箱、伪造和信任悖论等风险。imToken推出的Sigil产品通过「所见即所签」原则，将实际请求解析为清晰确认卡片，要求用户通过Passkey和生物识别独立批准，从而在Agent与钱包之间建立安全护栏，确保用户保留最终知情权与控制权。
• 关键要素：
  1. AI Agent行动中的新风险：用户授权面临「黑箱」问题，批准的是模糊意图而非真实操作；聊天回复缺乏数字签名，确认界面可能被Agent伪造，导致资产损失或数据泄露。
  2. Sigil的核心机制：用户可预设策略，允许Agent自主执行低风险操作；针对敏感操作（如资金交易、链上签名），Sigil暂停流程，解析出清晰的确认卡片发送至Telegram，要求用户通过Passkey和生物识别独立签署。
  3. 三层安全保障：首先，用户能准确看见（What you see is what you sign）实际资产、金额、接收方等参数；其次，签署人必须是用户本人（通过Passkey验证）；最后，确认页面由独立模块在沙箱中渲染，无法被Agent伪造或篡改。
  4. 产品定位与适用场景：Sigil是imToken对「Sign」命题的产品化探索，不仅适用于加密链上交易，未来可延伸至数据访问、文件修改、服务购买等各类AI Agent代理操作，旨在成为用户管理智能身份和权限的基础设施。

あなたがAIエージェントに「ウォレットにある利用可能な資金の半分をETHに追加購入して」と指示する未来を想像してみてください。

エージェントはすぐに残高の読み取り、流動性プールの検索、見積もりの比較、取引経路の構築を開始し、数十秒後には「適切な買い付け案が見つかりました。確認しますか？」というメッセージを送信します。

あなたは「はい」と返答します。

しかし、その瞬間、あなたは一体何を承認したのでしょうか？ どの取引プールを選択し、予想される取引価格とスリッページはいくらで、どのプロトコルを呼び出し、どのウォレットと資産を使用し、さらにトークン承認やその他の追加操作が含まれているのでしょうか？ これらの情報を実際に確認することなく、あなたはエージェントによるこの操作の要約を信頼するしかありません。

これはまさに、AIエージェントが「質問に答える」ことから「代わりに行動する」へと移行したことで徐々に露呈してきた、新たな種類のリスクです。エージェントはすでにウェブページの閲覧、アカウントへのログイン、さらには支払いの完了やオンチェーン署名を実行できますが、ユーザーが最終的に直面する承認インターフェースは、依然として曖昧なチャットメッセージと、有効な情報をほとんど含まない確認オプションだけであることが多いのです。

「はい」という一言が、あなたの資金、データ、そしてデバイスを動かし始めます。

そのため、imTokenの最新のブランドアップデートでは、Store、Send、Stakeに加えて、4つ目のSとしてSignが登場しました。最初の3つのSがそれぞれ資産の保管、価値の移動、ネットワークへの参加に対応するならば、Signが解決しようとしているのは、ますます多くのソフトウェアがユーザーに代わって行動し始める中で、ユーザーがどのようにして最終的な知情権、承認権、そして管理権を維持し続けるかという問題です。

そしてSigilこそが、Signという命題の下で初期に探求された最初のPOC製品であり、その中核となる原則は非常に興味深いものです：What you see is what you sign——あなたが見たものが、あなたが署名するものです。

一、エージェントが行動を開始する時、ウォレットはなぜSignを再定義する必要があるのか？

これまで、暗号資産ウォレットが直面する署名リスクの大半は、ユーザーが取引内容を理解できないことに起因していました。

オンチェーン取引は、その内部では複雑なコントラクトアドレス、関数パラメータ、16進数データとして表現されることが多く、一般のユーザーがそれが単なる送金・交換を意味するのか、それともより危険な資産操作を意味するのかを直接判断することは困難です。

そのため、ウォレットは生のデータを人間が理解できる情報に解析し、ユーザーが署名する前に詳細な情報を確認できるようにする必要があります（関連記事：『イーサリアムが推進する「What You See Is What You Sign」：なぜClear SigningがAI時代に必須の能力パッチなのか？』）。Clear Signing、すなわち「明確な署名」または「見たものが署名するもの」はまさに、機械データとユーザー理解の間のギャップを解決するためのものです。

しかし、AIエージェントがもたらす問題はさらに複雑です。

なぜなら、ユーザーが見えなくなったものは、もはや単一のオンチェーン取引だけではなく、エージェントによって自動的に計画・実行される一連の操作チェーン全体である可能性があるからです。

冒頭で述べたように、エージェントが「現在の流動資金の半分をETHに追加購入する」という目標を達成するためには、ウォレット残高の読み取り、オンチェーンプールの検索、サードパーティツールの呼び出し、スクリプトの実行、そして取引の完了が必要となる可能性があります。このプロセスにおいて、ユーザーはすべての基盤リクエストを一つ一つチェックすることは不可能であり、同時に、資産が実際に交換される前に最終決定を下さなければなりません。

現在、多くのエージェントが採用している承認方法は、チャットウィンドウに短い説明を送り、ユーザーが「Yes」「確認」と返信するか、通常のボタンをクリックするのを待つというものです。

この方法は一見ユーザー承認を完了しているように見えますが、実際にはいくつかの明らかな問題をはらんでいます。

まず、それはブラックボックスです。ユーザーは何かを承認したことは分かっていても、具体的にどの程度の金額を、どの受取先に対して承認したのか、そしてエージェントが最終的に自分の代わりに何に署名したのかを正確には知りません。実際の操作パラメータは高度に要約された自然言語の背後に隠され、ユーザーが確認するのは、これから発生する実際の動作ではなく、曖昧な意図だけです。

次に、チャットでの返信はデジタル署名と同等ではありません。誰かが既にログイン済みのデバイスにアクセスできる場合、スマートフォンを手に取ったり、チャットアカウントを制御したり、ユーザーの隣で直接操作したりすることで、「Yes」と入力することが可能です。システムは、このメッセージが特定のアカウントから来たことだけを確認できても、それが本当にアカウント所有者本人によって承認されたものかを確認することはできません。

さらに厄介なのは、確認インターフェース自体も偽装される可能性があることです。エージェントが承認メッセージを自分で生成できる場合、操作を開始する側が同時にユーザーに操作内容を表示するインターフェースも制御することになります。そのため、重要なパラメータを省略したり、曖昧な表現を使用したり、一見無害に見える操作を表示しながら、バックグラウンドで別のリクエストを送信することも完全に可能です。

これにより、明らかな信頼のパラドックスが生じます。我々は確認インターフェースを通じてエージェントを制限しようとしながら、エージェント自身にユーザーが確認時に何を見るかを決めさせているのです。

エージェントが記事の要約や情報整理だけを行う場合、この不透明さは誤った回答をもたらすだけかもしれません。しかし、アカウント、資金、ファイルシステム、端末環境にアクセスし始めると、一度の曖昧な承認がもたらす結果は、「不正確な回答」から、実際の資産損失、データ漏洩、デバイスリスクへと格上げされる可能性があります（関連記事：『Signは署名だけではない：AIエージェントがあなたの代わりに署名する時、誰が制御権を握っているのか？』）。

したがって、AIエージェントの時代に必要なのは、さらに多くの「はい」ボタンではなく、「ユーザーが何を見たか」「ユーザーが何を承認したか」「そしてシステムが最終的に何を実行したか」を証明できる署名メカニズムです。

二、Sigil：AIエージェントとウォレットの間にある署名の盾

これこそが、imTokenが新たにリリースしたSigilが実現しようとしていることです——自身をAIエージェントとウォレットの間にある安全ガードレールとして位置づけること。

Sigilは、エージェントがすべてのタスクを自動実行するのを妨げようとはしません。それどころか、ユーザーは初回設定時にエージェントを明確に承認し、どの低リスク操作を自律的に完了させてもよいか、どのセンシティブな操作は一時停止して、ユーザーによる独立した、明確で検証可能な承認を待つ必要があるかを規定できます。

設定された境界内では、エージェントは依然として迅速に行動できます。

しかし、ユーザーがセンシティブと指定した操作、特に資金の使用や取引への署名が関わる場合、Sigilはプロセスを一時停止し、実際のリクエストを解析して明確な確認カードに変換し、ユーザーのTelegramに送信します。ユーザーはPasskeyと生体認証を使用して署名を完了する必要があり、その後初めて操作の実行が続行されます。

全体的に見ると、プロセス全体は次の4つのステップに要約できます：

1. エージェントが操作を開始する：ウェブの閲覧、サービスの予約、リクエストの送信、取引の準備など、通常のエージェントの動作と変わりません。
2. 事前に設定されたセキュリティポリシーがトリガーされるかどうかを判断：エージェントの自律実行が許可された低リスク操作の場合は、プロセスは続行されます。メッセージの送信、ファイルの削除、コードの実行、資金の使用、オンチェーン署名などのセンシティブな行為が関わる場合、Sigilは実行を一時停止し、そのリクエストを解析します。
3. ユーザーがPasskeyを使用して明確に承認：明確な確認カードがTelegramに送信されます。そこには、事業者、金額、受取先、その他の重要なパラメータが直接表示されます。ユーザーが見るのは、エージェント自身が作成した説明文ではなく、実際の操作から解析された構造化されたコンテンツです。
4. 最後に、Sigilゲートウェイがユーザーの署名を検証した後にのみ、エージェントは実行を続行できます。ユーザーの承認がなければ、資金も署名も移動しません。

このメカニズムの鍵は、単に生体認証を追加したことではなく、表示、署名、実行の関係を再構築したことにあります：表示されるのは実際のリクエストであり、ユーザーが署名するのは表示された内容であり、システムが最終的に実行するのも、署名済みのリクエストでなければなりません。

これら3つが一致しない場合、Sigilは操作を阻止します。

つまり、Sigilはユーザーにエージェントのすべての動作を一項目ずつ承認するよう要求するのではなく、ポリシー設定を通じて、ユーザーが事前にどの動作を自動完了させるか、どの動作を本人が承認する必要があるかを決定できるようにします。ユーザーはRelaxed、Balanced、Strictなどの異なるセキュリティレベルを直接選択でき、Customモードに入って、操作の種類ごとに個別にルールを設定することもできます。

例えば、Balancedモードでは、低リスク度の行動の一部は追加の承認なしで実行できますが、高資産セキュリティに関連するコード実行や端末コマンドは、Sigilによる確認が必須となります。

そして、資金の使用と取引への署名については、ユーザーがどのセキュリティポリシーを選択しても、常に本人の承認が必要です。

これはSigilが譲歩しない一線です。

三、CryptoからAIエージェントへ、Sigilは何を守ろうとしているのか？

「What you see is what you sign」に基づき、Sigilはさらに3層の保証を提供します。

まず第一に、ユーザーが自分が何に署名しているのかを正確に見ることができることです。例えば、Sigilの確認カードでは、プロトコル、金額、受取先などのパラメータが明確なフィールドに解析されます。ユーザーはエージェントの要約を信頼する必要も、理解できない生データに直面する必要もありません。

このカード自体がユーザーの承認内容です。冒頭のETH取引の例で言えば、ユーザーが最終的に目にするのは「ETHを購入」という一言ではなく、実際に使用する資産と金額、取引の受取先、重要な取引パラメータ、そしてユーザーが理解する必要のあるその他の操作情報を含むべきです。

現実世界の支払いシーンにおいても、「支払いを確認」とだけ表示するのではなく、事業者、金額、受取先を明確にリストアップすべきです。表示される内容が実際の操作に近ければ近いほど、ユーザーの承認は意味を持つからです。

同時に、実際に署名できるのはユーザー本人だけです。これは、SigilがPasskeyを承認操作の安全な入り口として使用し、デバイスの生体認証を通じてユーザー本人であることを確認するためです。そのため、たとえ誰かが既にログイン済みのTelegramデバイスを入手し、確認メッセージを見ることができたとしても、単にテキストを入力したり、通常のボタンをクリックしたりするだけで承認を完了することはできません。

言い換えれば、Passkeyはユーザー本人に結びついており、「現在スマートフォンを手にしている人」に結びついているわけではありません。特筆すべき点として、Sigilはニーモニックフリーデザインを採用しており、ユーザーは新しいニーモニックフレーズを追加で保管したり入力したりする必要はなく、ウォレットの秘密鍵を直接エージェントに渡す必要もありません。承認能力を実際に制御しているのは、依然としてユーザー自身のPasskeyと生体認証です。

さらに、Sigilの確認ページは、エージェントがその場で描画する通常のメッセージではなく、登録された独立したモジュールであり、その内容はチェーン上に固定され、サンドボックス環境でレンダリングされます。これは、エージェントがセンシティブな操作を開始した後、ページを独自に置き換えたり、表示ロジックを変更したり、あるいは外見が似ている確認インターフェースを偽造してユーザーを騙して署名させることができないことを意味します。

リクエストを開始する側は、もはやリクエストを表示するインターフェースを同時に制御しません。さらに、単回署名、短い有効期間、リクエストパラメータのハッシュバインディングと組み合わせることで、Sigilは確認カードの内容と最終的に実行を待つリクエストが対応していることを保証し、署名が長期にわたって再利用されることや、ユーザー承認後にリクエストパラメータが密かに置き換えられることを防ぎます。

プレビュー内容と実際のリクエストが一致しなければ、操作は阻止されます。

したがって、Sigilをこの文脈で捉えると、それは単なる新しいウォレット機能ではなく、imTokenがSignという命題に対して行ったプロダクト化の探求であり、より根本的な問題に注目しています：エージェントが行動を開始する時、それが依然としてユーザーの許可した範囲内で行動していることをどのように保証するか？

Cryptoのシナリオにおいて、このニーズは特に直感的です。将来、オンチェーンエージェントは、ユーザーによる定期投資、収益管理、手数