AI Agent 正在从“帮你回答问题”快速走向“替你完成动作”。在加密场景里，这意味着用户不再只是阅读建议，而是可能直接把“帮我把钱包里一半可用资金加仓 ETH”这样的指令交给 Agent 去执行。问题也随之出现：当 Agent 读取余额、搜索流动性池、比较报价、构建交易路径，最后只抛给用户一句“方案已找到，是否确认”时，用户真实批准的到底是什么，往往并不清楚。
这类风险在 Agent 能接触钱包、账户、终端和支付能力后变得更敏感。用户看到的可能只是一条高度概括的自然语言说明，以及一个简单的“Yes”按钮；但在背后，实际执行的却可能涉及协议调用、代币授权、资金支出、脚本运行甚至链上签名。imToken 在最新品牌升级中把 Sign 作为 Store、Send、Stake 之外的第四个 S，意在解决一个更底层的问题：当软件开始代表用户行动，用户如何保有最终的知情权、批准权与控制权。
从“清晰签名”到 AI Agent 时代的新风险
过去，加密钱包的多数签名风险，主要来自用户看不懂链上交易的底层数据。一笔交易往往表现为复杂的合约地址、函数参数和十六进制内容，普通用户很难直接判断这究竟是转账、兑换，还是更危险的资产操作。因此，钱包行业推动的 Clear Signing，也就是“清晰签名”或“所见即所签”，核心就是把机器数据解析成人能理解的内容，让用户在签名前看到足够明确的信息。
但 AI Agent 带来的问题比传统交易签名更复杂。用户看不到的，已经不只是一笔链上交易，而可能是一整条由 Agent 自动规划的执行链路。以“买入 ETH”为例，Agent 可能依次完成读取钱包余额、筛选池子、调用第三方工具、执行脚本、生成交易等多个步骤。用户既不可能逐条检查每个底层请求，又必须在资金真正动用之前做出最终决定。
当前不少 Agent 的授权方式，仍然停留在聊天窗口里发送一段简短说明，再等待用户回复“Yes”“确认”或点击按钮。表面上看，用户似乎完成了授权；但本质上，这种模式只是在批准一个模糊意图，而不是批准一项被完整展示的真实请求。金额多少、收款方是谁、调用了哪个协议、是否包含附加授权，这些关键参数往往都被隐藏在一句概括性描述后面。
聊天式授权为什么不够安全
这种“回复 Yes 即通过”的方式，首先是一个典型黑箱。用户知道自己在批准某件事，却未必知道批准了多少资金、授权给谁、最终签署了什么内容。更关键的是，聊天回复并不等于数字签名。只要有人接触到已登录的设备，无论是拿到手机、控制聊天账户，还是在用户身旁代为操作，都可能输入一个“Yes”。系统最多只能确认消息来自某个会话，却很难证明确实是账户所有者本人完成了批准。
另一个更棘手的问题，是确认界面本身也可能被发起操作的一方控制。如果 Agent 既负责生成请求，又负责向用户展示批准页面，它完全可以故意省略关键参数、使用模糊措辞，甚至展示一个看似无害的操作，却在后台提交另一项真正执行的请求。这样一来，原本用于约束 Agent 的确认环节，反而再次建立在对 Agent 的信任上，形成明显的信任悖论。
当 Agent 只是总结文章、整理资料时，不透明更多带来的是结果偏差；但一旦它开始接触账户、资金、文件系统和终端环境，模糊批准的后果就会升级为真实资产损失、数据泄露或设备风险。因此，AI Agent 时代需要的不是更多“确认”按钮，而是一套能够证明“用户看到了什么、批准了什么、系统最终执行了什么”的签署机制。
Sigil 如何充当 Agent 与钱包之间的安全护栏
Sigil 是 imToken 在 Sign 方向上的一个早期 POC 产品，其核心原则很明确：What you see is what you sign。它不试图阻止 Agent 自动化执行所有任务，而是站在 AI Agent 与钱包之间，为敏感操作增加一道独立、可验证的批准流程。用户在初次设置时，可以先定义边界：哪些低风险行为允许 Agent 自主完成，哪些敏感行为必须暂停，等待本人确认。
在这些边界内，Agent 依旧可以继续浏览网页、预订服务、发送请求或准备链上交易，工作方式与普通 Agent 并无区别。一旦操作触发预设安全策略，例如发送消息、删除文件、运行代码、花费资金或链上签名，Sigil 就会中断流程，把真实请求解析成结构化的确认卡片，并发送到用户的 Telegram。
用户随后需要通过 Passkey 和生物识别完成批准，Sigil 网关验证签名后，Agent 才能继续执行；如果没有用户批准，任何资金和签名都不会移动。这个设计的重点，不只是多加了一次生物识别，而是重新绑定了展示、签署与执行三者之间的关系：展示的是实际请求，签署的是展示出来的内容，最终执行的也必须是已经签署的请求。只要三者不一致，Sigil 就会拦截操作。
策略分级、Passkey 与链上固定页面构成三层保障
从产品结构看，Sigil 先通过策略分级减少不必要的打扰。用户可以选择 Relaxed、Balanced、Strict 三种安全级别，也可以进入 Custom 模式，对不同类型的行为逐项设定规则。以 Balanced 模式为例，部分低风险操作可以由 Agent 直接完成，而涉及高资产安全风险的代码执行或终端命令，则必须经过 Sigil 审核。至于花费资金和签署交易，不论选择哪种策略，都始终需要用户本人批准，这是 Sigil 明确设下的底线。
第二层保障是身份确认。Sigil 把 Passkey 作为批准入口，并结合设备生物识别验证本人身份。这样即使有人拿到了已登录 Telegram 的设备，能够看到确认消息，也不能仅靠输入文字或点击普通按钮完成批准。与此同时，Sigil 采用无助记词设计，用户不需要额外保存一组新的助记词，也不需要把钱包私钥直接交给 Agent。真正掌握批准权的，仍然是用户自己的 Passkey 与生物识别能力。
第三层保障来自展示界面的独立性。Sigil 的确认页面不是由 Agent 临时生成的一条普通消息，而是一个经过注册的独立模块，内容被固定在链上，并在沙箱环境中渲染。这样一来，发起请求的一方不再同时控制展示请求的界面，Agent 也不能在敏感操作发起后自行替换页面、修改展示逻辑，或伪造一个外观相似的确认页来诱导签署。再配合单次签名、较短有效期以及对请求参数进行哈希绑定，Sigil 可以确保确认卡片与最终执行请求一一对应，避免签名被长期复用或参数在批准后被悄悄替换。
从加密钱包能力延展到更广泛的 Agent 授权基础设施
在 Crypto 场景中，Sigil 的应用空间相当直接。未来链上 Agent 可以替用户执行定投、收益管理、费用支付、仓位调整和风险监控，也可能在多个协议之间按预设条件自动切换操作。Agent 的自动化能力越强，用户就越需要一种机制，在其行为偏离预期时立即叫停。Sigil 试图承担的，正是这层独立于 Agent 本身的制衡能力。
但 Sigil 的意义并不只局限于链上交易。原文提到，OpenClaw、Hermes 以及未来更多运行在本地设备和云端环境中的 Agent，都在逐步接入邮件、即时通信、日历、文件、浏览器、终端、支付工具和各类在线服务。虽然这些行为未必发生在区块链上，但底层关系是一致的：Agent 正在以用户名义调用本应只属于用户的能力。因此，这套机制未来也可能延伸到数据访问、身份使用、文件修改、内容发布、服务购买和自动化任务等更广泛场景。
从这个角度看，钱包行业过去在私钥管理、数字签名、身份验证、权限确认和资产安全上积累的经验，到了 AI Agent 时代可能获得新的价值。它们服务的从来不只是链上交易，而是一个更根本的问题：如何证明一项行动确实获得了某个主体的真实授权。作为 imToken 与 OpenClaw 的共同探索，Sigil 试图把 imToken 过去十年在自托管、钱包和数字签名领域的经验，带入一个“自主 Agent 开始进入真实执行环境”的新阶段。
归根结底，AI 正在显著降低行动成本。过去需要用户在多个应用之间搜索、填写、确认和支付的一整套流程，未来可能只需一句自然语言指令就能由 Agent 自动拆解并完成。但“能够替用户行动”和“已经获得用户有效授权”始终不是一回事。Sigil 想解决的，正是这条边界：当机器开始频繁替人行动时，用户是否仍能看清、限制并在必要时叫停它。对 imToken 而言，Store 关乎资产保管，Send 关乎价值流动，Stake 关乎网络参与，而 Sign 关乎最后的决定权。