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