From blindly clicking "Yes" to verifying before signing: How Sigil adds a safety guardrail for AI Agents?

Imagine a future where you only need to tell an AI Agent: "Use half of the available funds in my wallet to buy more ETH."

The Agent then reads the balance, searches liquidity pools, compares quotes, and constructs a transaction path. A few dozen seconds later, it sends you a message: "Found a suitable buy plan. Confirm?"

You reply with a "Yes."

But in that very moment, what exactly did you approve? Which trading pool did it choose? What is the expected execution price and slippage? Which protocol was invoked? Which wallet was used and how much asset? Did it include token approvals or other additional operations? You never truly saw any of this information; you only chose to trust the Agent's summary of the operation.

This is precisely a new type of risk emerging as AI Agents evolve from "answering questions" to "acting on your behalf": Agents can now browse the web, log into accounts, and even complete payments and on-chain signatures. Yet, the authorization interface users ultimately face often remains a vague chat message and a confirmation option that contains almost no effective information.

A single "Yes" begins to decide the fate of your funds, data, and devices.

Therefore, in imToken's latest brand upgrade, a fourth 'S' has appeared alongside Store, Send, and Stake - Sign. If the first three S's correspond to asset custody, value transfer, and network participation, then Sign aims to solve the problem of how users can continue to retain the ultimate right to know, right to approve, and right to control when more and more software begins to act on their behalf.

And Sigil is the first early-stage exploration POC product under the Sign proposition. Its core principle is very interesting: What you see is what you sign.

1. When Agents Start Acting, Why Does the Wallet Need to Reunderstand Sign?

In the past, most signing risks faced by crypto wallets primarily stemmed from users not understanding the transaction content.

An on-chain transaction might, at its core, only manifest as complex contract addresses, function parameters, and hexadecimal data. It's difficult for ordinary users to directly judge whether it means a transfer/swap, or a more dangerous asset operation.

Therefore, wallets need to parse raw data into information humans can understand, allowing users to see detailed information before signing (extended reading: Ethereum Pushes "What You See Is What You Sign": Why is Clear Signing a Necessary Capability Patch in the AI Era?). Clear Signing is precisely designed to bridge the gap between machine data and user understanding.

But the problem introduced by AI Agents is more complex.

Because what users cannot see is no longer just a single on-chain transaction, but potentially an entire chain of operations automatically planned and executed by the Agent.

As mentioned earlier, to achieve a goal like "use half of my current liquid funds to buy more ETH," an Agent might need to read wallet balances, search on-chain pools, call third-party tools, execute scripts, and complete transactions. In this process, users can neither review all underlying requests one by one, nor can they postpone making the final decision until after the assets are actually swapped.

The authorization method currently adopted by many Agents is to send a brief explanation in the chat window, and then wait for the user to reply "Yes," "Confirm," or click a common button.

While this method seemingly completes user authorization, it still presents several obvious problems.

Firstly, it's a black box. Users know they approved something but don't necessarily know the specific amount approved, the recipient, or what the Agent ultimately signed on their behalf. The actual operation parameters are hidden behind a highly summarized natural language sentence. Users are confirming a vague intention, not the real action about to take place.

Secondly, a chat reply does not equal a digital signature. As long as someone has access to a logged-in device—whether they've picked up the phone, taken control of the chat account, or are operating it right next to the user—they can input a "Yes." The system can, at most, confirm the message came from a certain account, but not that it was indeed authorized by the account owner themselves.

More troublesome is that the confirmation interface itself could be forged. If the Agent can generate the approval message itself, then the party initiating the operation also controls the interface showing the operation's content to the user. It could easily omit key parameters, use vague wording, or even display a seemingly harmless operation while submitting a different request in the background.

This creates an obvious trust paradox. We want to restrict the Agent through a confirmation interface, yet we let the Agent decide what the user can see during that confirmation.

When an Agent is only responsible for summarizing articles or organizing information, this opacity might only lead to incorrect answers. But when it starts accessing accounts, funds, file systems, and terminal environments, the consequences of a vague approval can escalate from "inaccurate answers" to real asset losses, data breaches, or device risks (extended reading: Sign is More Than Just Signing: When AI Agents Sign For You, Who Holds the Control?).

Therefore, the AI Agent era doesn't need more "Yes" buttons. It needs a signing mechanism that can prove "what the user saw, what the user approved, and what the system ultimately executed."

2. Sigil: The Signature Shield Between AI Agent and Wallet

This is exactly what imToken's latest product, Sigil, aims to do—positioning itself as a security guardrail between the AI Agent and the wallet.

It doesn't try to prevent the Agent from executing all tasks automatically. On the contrary, users can explicitly authorize the Agent during initial setup, defining which low-risk operations can be completed autonomously and which sensitive operations must be paused, awaiting an independent, clear, and verifiable approval from the user.

Within these set boundaries, the Agent can still act quickly.

But whenever an operation marked as sensitive by the user is involved, especially spending funds or signing transactions, Sigil will pause the process, parse the real request into a clear confirmation card, and send it to the user's Telegram. The user needs to complete the signing using a Passkey and biometrics before the operation proceeds.

Overall, the entire flow can be summarized in four steps:

1. Agent Initiates Operation: It can continue browsing the web, booking services, sending requests, or preparing a transaction, similar to how a regular Agent works.
2. Security Policy Check: It determines if a pre-set security policy is triggered. If it's a low-risk operation allowed for autonomous completion, the flow continues. If it involves sensitive actions like sending messages, deleting files, running code, spending funds, or signing on-chain transactions, Sigil pauses execution and parses the request.
3. User Explicit Approval via Passkey: A clear confirmation card is sent to Telegram, directly displaying the merchant, amount, recipient, and other key parameters. What the user sees isn't a sentence written by the Agent itself, but structured content parsed from the real operation.
4. Agent Executes Only After Sigil Verification: Finally, only after the Sigil gateway verifies the user's signature can the Agent proceed with execution. Without user approval, no funds or signatures will be moved.

The key of this mechanism is not just adding one more biometric verification; it's about re-establishing the relationship between display, signing, and execution: What is displayed is the actual request, what the user signs is the displayed content, and what the system ultimately executes must be the signed request.

If these three are inconsistent, Sigil blocks the operation.

Essentially, Sigil doesn't require users to approve every single action of the Agent. Instead, through policy settings, it lets users decide in advance which behaviors can be automated and which must be approved by themselves. Users can directly choose security levels like Relaxed, Balanced, or Strict, or enter Custom mode to set rules for each type of operation individually.

Taking Balanced mode as an example, some low-risk actions may proceed without additional approval, while actions related to high asset security, like code execution or terminal commands, must pass through Sigil confirmation.

As for spending funds and signing transactions, regardless of the security strategy chosen, they always require personal approval.

This is a boundary that Sigil will not compromise on.

3. From Crypto to AI Agents: What Does Sigil Aim to Protect?

Centered around "What you see is what you sign," Sigil provides three layers of protection.

First, users can accurately see what they are signing. For instance, in Sigil's confirmation card, parameters like protocol, amount, and recipient are parsed into clear fields. Users don't need to trust the Agent's summary, nor face incomprehensible raw data.

This card itself is the content of the user's authorization. Taking the ETH transaction example from the beginning, what the user ultimately sees shouldn't just be a sentence like "Buy ETH," but should include the actual asset and amount used, the transaction recipient, key transaction parameters, and other operational information the user needs to understand.

Similarly, for real-world payment scenarios, it shouldn't just display "Confirm Payment," but clearly list the merchant, amount, and payee. After all, the closer the displayed content is to the real operation, the more meaningful the user's authorization becomes.

At the same time, only the user themselves can truly sign. This is because Sigil uses Passkey as the secure entry point for approving operations and uses device biometrics to verify the user's identity. Therefore, even if someone gets hold of a device logged into Telegram and can see the confirmation message, they cannot complete approval just by typing text or clicking a regular button.

In other words, the Passkey is bound to the user, not to the "person currently holding the phone." It's worth noting that Sigil adopts a seedless design. Users don't need to manage or input a new set of seed phrases, nor hand over the wallet's private key to the Agent. The real control over approval capability remains with the user's own Passkey and biometrics.

Furthermore, Sigil's confirmation page is not a regular message temporarily generated by the Agent. It is an independent, registered module whose content is fixed on-chain and rendered in a sandbox environment. This means the Agent cannot, after initiating a sensitive operation, replace the page, modify the display logic, or forge a similar-looking confirmation interface to trick the user into signing.

The entity initiating the request no longer simultaneously controls the interface displaying that request. Combined with single-use signatures, short validity periods, and hash binding of request parameters, Sigil ensures that the content in the confirmation card corresponds exactly to the request awaiting execution. Signatures cannot be reused long-term, and request parameters cannot be silently swapped after user approval.

As long as the preview content doesn't match the actual request, the operation is intercepted.

Therefore, viewing Sigil in this context, it is not just a new wallet feature, but imToken's product-oriented exploration of the Sign proposition. Its focus is on another, more fundamental question: When an Agent starts doing things, how do we ensure it still acts within the user's allowed scope?

This need is particularly intuitive in the Crypto scenario. In the future, on-chain Agents could help users with regular investments, yield management, fee payments, position adjustments, and risk monitoring. They might even automatically execute operations across multiple protocols based on preset conditions. This makes it even more crucial to consider whether an Agent can be immediately stopped when its behavior deviates from user expectations.

At the same time, Sigil's significance is not limited to Crypto. Currently, whether it's OpenClaw, Hermes, or more Agents running on personal devices and cloud environments in the future, they are all gradually integrating with email, instant messaging, calendars, files, browsers, terminals, payment tools, and various online services.

Although these operations don't necessarily happen on the blockchain, their underlying relationship is essentially the same: the Agent invokes a user's capability on their behalf. Therefore, Sigil could potentially expand from on-chain transactions to data access, identity usage, file modification, content publishing, service purchasing, and automated tasks in the future.

This also explains why the capabilities accumulated by the wallet industry in the past might gain new value in the AI Agent era. Private key management, digital signatures, identity verification, permission confirmation, and asset security were primarily used for on-chain transactions. But the more fundamental problem they addressed has always been how to prove that an action received genuine authorization from a specific entity.

As Agents begin to act on behalf of humans on a large scale, this set of capabilities has the opportunity to extend beyond the Crypto world and become infrastructure for users to manage their smart identities, automated tasks, and machine permissions.

Therefore, as a joint exploration by imToken and OpenClaw, Sigil attempts to bring imToken's decade-long experience in self-custody, wallets, and digital signing into the new phase where autonomous Agents enter real execution environments.

It doesn't replace the Agent, nor does it replace the wallet.

It stands between them.

Final Thoughts

Overall, AI is making the ability to act increasingly cheap.

Things that previously required users to switch between multiple apps, going through searching, filling, confirming, and paying, might in the future only need a single natural language command for the Agent to automatically decompose and execute.

But "being able to act on the user's behalf" and "having obtained valid user authorization" are always two different things.

Because what truly determines whether an intelligent system is trustworthy is not just how many tasks it can complete, but whether the user can always understand it, limit it, and make it stop when necessary. From this perspective, Sign is not an unnecessary step hindering Agent efficiency. On the contrary, it may be the most important layer of trust foundation before Agents truly enter the realm of assets and real-world services.

Store lets users own assets, Send lets value flow freely, Stake lets users participate in open networks, and Sign aims to solve how users can retain the ultimate decision-making power when more and more machines start acting on their behalf.

The value of Sigil lies in taking this seemingly abstract control proposition and pushing it for the first time into a product that can be verified and continuously improved through a real demo.

Let's wait and see.