As AI agents evolve from assistants that summarize information into systems that can actually act on behalf of users, the weak point is no longer just model quality. It is authorization. The article opens with a practical scenario: a user tells an AI agent to “use half of the available funds in my wallet to add to my ETH position.” The agent checks balances, searches liquidity pools, compares quotes, builds a route, and then returns with a short message saying it has found a suitable execution plan and asks for confirmation. If the user simply replies “Yes,” the key question is obvious: what exactly has been approved?
That one-word confirmation may hide a large amount of operational detail. Which pool did the agent choose? What execution price and slippage does it expect? Which protocol is being called? Which wallet and which amount of assets are involved? Is there any token approval embedded in the flow, or any additional contract interaction the user did not explicitly ask for? In many current agent interfaces, those details are not surfaced in a way that lets the user inspect the real request. The user is effectively trusting a summary, not authorizing a concrete and verifiable action.
This is the structural risk that appears when AI agents move from “answering questions” to “doing things.” An agent can browse the web, log into services, access accounts, use tools, execute scripts, submit on-chain transactions, and potentially trigger payments. Yet the final approval step presented to the user often remains a vague line in a chat interface plus a generic confirm button. In that model, a casual “Yes” may determine the fate of funds, data, or device permissions without a corresponding level of visibility or proof of intent.
Against that backdrop, imToken’s latest brand upgrade adds a fourth “S” alongside Store, Send, and Stake: Sign. If the first three map to custody, value transfer, and network participation, Sign is aimed at a newer problem—how users can retain informed consent, approval authority, and ultimate control when software increasingly acts in their name. Sigil is introduced as the first early proof-of-concept under that Sign thesis, and its core principle is concise: What you see is what you sign.
Why chat-based approvals break down in the AI agent era
In traditional wallet security, the main signing risk usually came from incomprehensible transaction data. A blockchain request at the raw level can look like a contract address, function arguments, and hexadecimal payloads. Most users cannot easily determine whether they are about to transfer tokens, swap assets, grant approvals, or trigger a much riskier contract action. That is why wallet providers have been pushing clear signing: transforming raw machine-readable data into human-readable intent before the user signs.
AI agents raise the bar. The invisible object is no longer just a single transaction payload, but potentially an entire chain of actions planned and orchestrated by the agent. To fulfill a command such as allocating half of available liquidity into ETH, an agent may read balances, search pools, call third-party tools, run scripts, assemble execution steps, and finally submit a transaction. Users cannot realistically inspect every low-level operation one by one, but they still need to decide whether the final action should proceed.
Many agents currently solve this with a short explanation inside a chat window followed by a “Yes,” “Confirm,” or a standard button. On the surface, that looks like consent. In practice, it leaves several serious gaps. First, it is a black box. A user may know that some action is being approved, but not how much value is being spent, who the recipient is, what protocol path is involved, or what exactly will be signed at the end. The user confirms a broad natural-language intention, while the system executes a highly specific request.
Second, a chat reply is not the same thing as a cryptographic signature tied to the real owner. Anyone with access to a logged-in device, a hijacked chat session, or the user’s phone in hand could type “Yes.” At most, the system can infer that a message came from a given account. It cannot robustly prove that the account owner knowingly authorized the operation. This distinction becomes critical once actions involve money, code execution, file deletion, credentials, or device-level capabilities.
Third, and perhaps most importantly, the approval interface itself may be untrustworthy. If the same agent that initiates an operation also controls the UI that describes it, the agent can omit key parameters, blur critical distinctions, or even display a harmless-looking summary while preparing a materially different request in the background. That creates a trust paradox: the confirmation step is supposed to constrain the agent, but the agent is allowed to decide what the user sees during that confirmation. In low-stakes tasks that may merely produce a wrong answer. In high-stakes execution environments, it can lead to actual asset loss, data leakage, or device compromise.
How Sigil inserts a verifiable guardrail between the agent and the wallet
Sigil is positioned as a security layer that sits between the AI agent and the wallet. It is not designed to eliminate automation, and it does not require users to manually approve every single action an agent takes. Instead, the user defines boundaries up front. Some low-risk actions can be allowed to run autonomously. Others—especially those involving funds, signatures, code execution, or sensitive system changes—must pause and wait for an independent approval that is explicit and verifiable.
Within those preset boundaries, the agent can still work normally. It can browse websites, book services, send requests, prepare trades, and orchestrate workflows the way a typical agent would. The difference appears when the operation crosses into a sensitive class. At that point, Sigil intercepts the request, pauses execution, parses the real action into a clear approval object, and forwards that object to the user through Telegram.
The article summarizes the mechanism in four steps. First, the agent initiates an action in the same way any standard agent would. Second, the system checks whether the request triggers a previously configured policy. Low-risk actions may proceed without interruption, but actions such as sending messages, deleting files, running code, spending funds, or signing on-chain transactions trigger a stop. Third, Sigil converts the actual request into a structured confirmation card that shows the merchant, amount, recipient, and other key parameters directly, instead of relying on the agent’s own natural-language summary. Fourth, only after the Sigil gateway verifies the user’s signature can the agent continue execution. Without approval, no funds move and no signature is released.
The design goal is not merely to add an extra biometric step. The deeper objective is to rebind display, signing, and execution into one trustworthy chain. What is displayed must be the real request. What the user signs must be exactly what was displayed. And what the system executes must be exactly what was signed. If any of those three layers diverge, Sigil blocks the action. That is the core distinction between a vague “Yes” in a chat box and a verifiable authorization framework.
Sigil also supports policy-based security levels. Users can choose predefined modes such as Relaxed, Balanced, and Strict, or switch to a Custom mode to define rules for each class of action. In the Balanced mode described in the article, some lower-risk behavior can proceed without extra confirmation, while higher-risk operations—such as code execution or terminal commands tied to asset security—require Sigil approval. Spending funds and signing transactions, however, always require the user’s explicit approval regardless of the selected mode. The article treats this as a non-negotiable boundary.
The three protection layers behind Sigil’s “what you see is what you sign” model
The article frames Sigil’s value proposition around three layers of protection. The first is visibility. Users should be able to clearly see what they are signing. In a Sigil confirmation card, details such as protocol, amount, and recipient are parsed into readable fields. The user does not need to rely on the agent’s summary and does not have to interpret raw machine data. In the ETH example from the beginning, the user should not only see “buy ETH,” but also the actual asset being used, the amount involved, the recipient or destination, the key transaction parameters, and any additional information required to understand the action. The same principle applies to off-chain payments: “confirm payment” is not enough; the merchant, amount, and payee should be explicitly shown.
The second layer is identity assurance. Sigil uses Passkey as the secure approval entry point and combines it with device biometric authentication. That means even if someone has physical access to a device that is already logged into Telegram and can read the approval message, they still cannot complete approval merely by typing text or pressing a generic button. Approval is bound to the user through Passkey and biometric verification, not merely to possession of the device at that moment.
The article also notes that Sigil uses a seedless design. Users do not need to maintain or input a new mnemonic phrase, and they do not need to hand their wallet private key to the agent. In this architecture, the approval capability remains under the user’s own Passkey and biometric control. This is a meaningful distinction in any future where autonomous systems increasingly request access to economic or identity-bearing actions.
The third layer addresses the integrity of the approval interface itself. Sigil’s confirmation page is not a generic message drawn dynamically by the agent. Instead, it is a registered standalone module whose content is anchored on-chain and rendered in a sandbox environment. This matters because it prevents the request initiator from also controlling the approval presentation logic after the fact. The agent cannot freely swap the page, rewrite its display logic, or fabricate a convincing but misleading confirmation UI that imitates the real one.
Combined with one-time signatures, short validity windows, and hash binding of request parameters, this design is meant to ensure that the confirmation card corresponds to the exact request waiting to be executed. In other words, a signature cannot be replayed indefinitely, and the request parameters cannot be silently altered after the user approves. If the previewed content and the actual execution request do not match, the operation is blocked.
Why the model matters beyond crypto wallets
The article argues that the demand for a system like Sigil is especially intuitive in crypto, because blockchain-based agents are likely to take on recurring investment, yield management, fee payments, position adjustments, and risk monitoring in the future. They may also execute workflows across multiple protocols according to predefined conditions. In such environments, the crucial question is whether a user can immediately stop the process when the agent’s behavior drifts away from the intended boundary.
At the same time, the significance of Sigil is not limited to on-chain execution. The text points to projects such as OpenClaw and Hermes, as well as a broader wave of agents operating on personal devices and in cloud environments, all of which are gradually connecting to email, messaging, calendars, files, browsers, terminals, payment rails, and online services. These actions may not happen on a blockchain, but the authorization problem is structurally the same: the agent is invoking a capability that belongs to the user, in the user’s name.
Following that logic, Sigil could eventually extend from blockchain transactions into data access, identity usage, file modification, content publication, service purchases, and automated workflows. This is also why capabilities historically developed inside the wallet industry may gain new value in the age of AI agents. Private key management, digital signatures, identity verification, permission confirmation, and asset security have long served on-chain transactions, but their deeper function has always been to prove that a meaningful action was genuinely authorized by a specific subject.
As agents increasingly act for humans at scale, those wallet-native capabilities may evolve into broader infrastructure for managing machine permissions, automated tasks, and intelligent identities. In that sense, the article presents Sigil as more than a product demo. It is framed as a joint exploration by imToken and OpenClaw that attempts to carry imToken’s 10 years of experience in self-custody, wallets, and digital signatures into a new execution environment shaped by autonomous agents.
The article’s conclusion is straightforward. AI is making action cheaper. Tasks that once required users to jump across multiple apps, search manually, fill forms, confirm details, and pay through several steps may eventually be reduced to a single natural-language instruction processed by an agent. But the ability to act on behalf of a user is not the same as valid user authorization. A trustworthy intelligent system is defined not only by how many tasks it can complete, but by whether the user can still understand it, constrain it, and stop it when necessary. From that perspective, Sign is not a drag on agent efficiency. It may be the trust foundation that allows agents to safely enter the world of assets and real services.