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