As AI agents move beyond information retrieval and start operating wallets, accounts, devices, terminals, and payment flows, the security model around authorization is being tested in a new way. A user may issue a simple instruction such as “use half of my available wallet balance to add to my ETH position,” and the agent can then read balances, search liquidity pools, compare quotes, build a route, and prepare the trade. The difficult part is not the agent’s ability to execute these steps. The real problem is what the user actually sees before approval.
In many current workflows, the final user interaction is reduced to a short chat message and a broad confirmation, often no more than “Yes” or a generic button. That creates a serious visibility gap. The user may not know which pool was selected, what execution price and slippage are expected, what protocol is being called, whether token approvals are included, which wallet is used, or what exact assets will move. In effect, the user is approving the agent’s summary of an action, not the precise action itself.
This matters because the consequences have changed. When an AI agent only summarizes articles or organizes information, opacity may lead to an inaccurate answer. But when an agent can browse the web, log into services, run scripts, pay for goods, or sign on-chain transactions, a vague approval can lead to real asset loss, data exposure, or device-level risk. The question is no longer whether the agent can act. The question is whether the system can prove what the user saw, what the user approved, and what the system finally executed.
Why imToken added “Sign” to Store, Send, and Stake
In imToken’s latest brand upgrade, a fourth “S” appears next to Store, Send, and Stake: Sign. The first three map naturally to custody, value transfer, and network participation. Sign addresses a more fundamental issue for the AI era: as software increasingly acts on behalf of users, how do users retain informed consent, approval authority, and final control?
Sigil is the first early proof-of-concept product under that thesis. Its core principle is simple but strict: What you see is what you sign. In the traditional wallet world, most signing risk comes from users not understanding transaction payloads. At the protocol level, an action may look like contract addresses, function selectors, parameters, and opaque hexadecimal data. Wallets therefore need to parse raw machine-readable requests into something humans can actually verify. That is the role of clear signing.
AI agents complicate the problem significantly. The hidden object is no longer just one transaction. It may be an entire action chain planned and executed by the agent. To fulfill a request like “use half my liquid funds to increase my ETH position,” the agent might read balances, search pools, call third-party tools, run scripts, and eventually trigger a swap. The user cannot realistically inspect every low-level operation, yet still needs to make the final authorization decision before funds move. That makes the signing interface itself a critical security boundary.
Why chat-based approvals are not enough
Many current agent systems rely on a lightweight approval pattern: the agent sends a brief explanation in a chat window, then waits for the user to reply with “Yes,” “Confirm,” or click a plain button. This may look like consent, but it leaves several obvious weaknesses unresolved.
First, the process is a black box. A user might know they approved “something,” but not the precise amount, the destination, the merchant, or the exact request that was ultimately signed. Key parameters are hidden behind natural-language compression. The user is approving intent at a very high level, not a concrete instruction bound to specific execution details.
Second, a chat reply is not a digital signature. Anyone who can access a logged-in device, control the chat account, or physically interact with the device while the user is nearby may be able to type “Yes.” The system can at best infer that the message came from an account, not that it was truly authorized by the account owner. For actions involving funds, files, or privileged capabilities, that is not a strong enough standard.
Third, and more dangerously, the confirmation interface itself may be spoofed. If the same agent that initiates a sensitive operation also controls the content shown to the user, it can omit critical parameters, use ambiguous wording, or present an innocent-looking summary while submitting a materially different request in the background. This creates a direct trust paradox: the interface meant to constrain the agent is itself defined by the agent.
That paradox is tolerable only when the downside is a poor answer. It becomes unacceptable once the agent can access wallets, accounts, device environments, or payment rails. In that setting, authorization must become independently verifiable, not merely conversational.
How Sigil works between the agent and the wallet
Sigil is positioned as a guardrail between the AI agent and the wallet layer. It does not try to stop all automation. Instead, it lets users define boundaries up front. During setup, users specify which low-risk actions may proceed autonomously and which sensitive actions must pause and await explicit approval. Within those boundaries, the agent can continue operating with speed. But once the action touches user-defined sensitive categories—especially spending funds or signing transactions—the flow is interrupted.
The article describes the process in four steps. First, the agent initiates an action as usual. It can browse, book services, send requests, or prepare a transaction. Second, the system checks whether the action matches a preconfigured security policy. If it falls into a low-risk category, execution continues. If it involves sending messages, deleting files, running code, spending money, or signing on-chain requests, Sigil pauses the workflow and parses the request.
Third, a structured approval card is sent to the user through Telegram. The user does not see the agent’s own summary but a structured view extracted from the real request, including fields such as merchant, amount, recipient, and other key parameters. Fourth, the user must approve using a Passkey combined with biometric verification. Only after the Sigil gateway validates that approval can the agent continue execution.
The important part is not simply that there is one more biometric step. The important part is that display, signature, and execution are bound together again. The user sees the actual request in parsed form. The user signs what is shown. The system is then only allowed to execute what has been signed. If those three layers diverge, Sigil blocks the action.
Sigil also avoids requiring approval for every single micro-action. Users can choose among predefined policy levels such as Relaxed, Balanced, and Strict, or enter a Custom mode to define rule-by-rule behavior. In Balanced mode, some lower-risk actions can proceed without extra approval, while more sensitive behavior—such as code execution or terminal commands with strong asset-security implications—requires Sigil confirmation. Spending funds and signing transactions, however, always require explicit user approval regardless of policy level. That boundary is treated as non-negotiable.
The three protections behind “what you see is what you sign”
The first protection is visibility. Sigil aims to make sure users can accurately see what they are signing. In its approval cards, protocol information, amount, recipient, and other parameters are broken out into clear fields. Users do not need to trust the agent’s narrative summary, and they do not need to decode raw payloads. In the ETH-buying example from the article, the final view should not merely say “buy ETH.” It should include the actual asset being spent, the amount, the receiving party, key trade parameters, and any other information the user needs to understand the operation.
The same standard applies outside crypto. For a real-world payment, the interface should not simply say “confirm payment.” It should clearly identify the merchant, amount, and payee. The closer the displayed content is to the real action, the more meaningful user authorization becomes.
The second protection is signer authenticity. Sigil uses Passkey-based approval together with biometric verification on the device. That means even if someone gains access to a Telegram session on a logged-in device and can read the approval request, they still cannot complete approval merely by typing text or pressing an ordinary button. The approval capability is bound to the user, not just to possession of the device in that moment.
The article also notes that Sigil adopts a seedless design. Users do not need to store or enter a new mnemonic phrase, and they do not need to hand wallet private keys to the agent. Control over approval remains anchored in the user’s own Passkey and biometric verification, not delegated to the agent itself.
The third protection is interface independence. Sigil’s confirmation page is not a temporary message drawn by the agent. It is a registered independent module whose content is fixed on-chain and rendered in a sandboxed environment. This limits the agent’s ability to swap pages, alter display logic, or mimic a benign-looking approval interface after initiating a sensitive action.
In addition, Sigil combines one-time signatures, short validity periods, and hash binding of request parameters. Together, these mechanisms help ensure that the content in the approval card corresponds to the exact request waiting to be executed. Signatures cannot be reused indefinitely, and request parameters cannot be silently changed after approval. If the preview content and the actual request do not match, the operation is intercepted.
From crypto transaction safety to general AI agent permission infrastructure
In crypto, the need for this model is easy to understand. Future on-chain agents may help users execute recurring investments, yield management, fee payments, position adjustments, and risk monitoring, or move between protocols automatically based on predefined conditions. In such a world, the key security question is whether an agent that drifts from user intent can be stopped immediately. Sigil is designed to answer exactly that problem.
But the article makes clear that the significance of Sigil is not limited to crypto. Projects such as OpenClaw, Hermes, and future agents running on personal devices or in cloud environments are increasingly integrating with email, messaging, calendars, files, browsers, terminals, payment tools, and a wide range of online services. These actions may not occur on-chain, but the underlying trust relationship is structurally similar: the agent is invoking a capability that belongs to the user, in the user’s name.
That is why Sigil could eventually extend from on-chain transactions to data access, identity use, file edits, content publishing, service purchases, and broader automation tasks. The wallet industry’s accumulated experience in private key management, digital signatures, identity verification, permission confirmation, and asset protection may therefore gain a second life in the AI-agent era. Historically, these capabilities served blockchain transactions. At a deeper level, however, they always addressed the same question: how can a system prove that a given action was genuinely authorized by a specific subject?
As agents begin acting at scale on behalf of users, that question becomes universal. What was once crypto wallet infrastructure may evolve into infrastructure for managing machine permissions, intelligent identities, and automated execution rights more broadly.
Seen in this light, Sigil is not trying to replace the agent, and it is not trying to replace the wallet. It sits between them. The collaboration between imToken and OpenClaw attempts to bring imToken’s decade of experience in self-custody, wallet design, and digital signing into a new phase in which autonomous agents are moving from demos into real execution environments.
The final point is conceptual but practical. AI is rapidly reducing the cost of action. Tasks that once required a user to move between multiple apps, search, fill forms, confirm steps, and complete payment may eventually collapse into a single natural-language instruction. But the ability to act on behalf of a user is not the same as having valid authorization from that user. A trustworthy system is defined not only by what it can do, but by whether the user can still understand it, constrain it, and stop it when necessary.
From that perspective, Sign is not redundant friction. It may be the trust layer that makes real-world AI agent execution viable in the first place. Store gives users custody. Send enables value movement. Stake connects users to open networks. Sign addresses the final question for the agent era: when more and more machines act for people, how do people keep the last word?