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

Imagine a future where you simply tell an AI Agent: "Help me add half of my available wallet funds to buy more ETH."

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

You reply with a "Yes."

But at 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 and how many assets were used? And does it include token approval or other additional operations? You haven't actually seen any of this information; you are simply trusting the Agent's summary of the operation.

This is precisely a new type of risk that has gradually emerged after AI Agents evolved from "answering questions" to "acting on behalf of users": Agents can now browse websites, log into accounts, and even complete payments and on-chain signatures. However, the authorization interface the user ultimately faces is often still just a vague chat message and an approval option that contains almost no valid information.

A single "Yes" begins to determine your funds, data, and devices.

Therefore, in imToken's latest brand upgrade, a fourth 'S' - Sign - appears alongside Store, Send, and Stake. 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 retain the ultimate right to know, approve, and control as more and more software starts acting on behalf of users.

And Sigil is the first early-stage POC product under the Sign proposition. Its core principle is fascinating: 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, at its core, might only appear as complex contract addresses, function parameters, and hexadecimal data, making it difficult for ordinary users to directly determine if it means a transfer/swap or a more dangerous asset operation.

Therefore, wallets need to parse raw data into human-readable information, allowing users to see detailed information before signing. This is Clear Signing, also known as "What You See Is What You Sign" (Read more: Ethereum Pushes 'What You See Is What You Sign': Why Clear Signing is a Necessary Capability Patch for the AI Era). It addresses the gap between machine data and user understanding.

But the problems posed by AI Agents are more complex.

Because what the user can't 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 described earlier, to achieve a goal like "help me add half of my current liquid funds to buy ETH," an Agent might need to read wallet balances, search on-chain pools, invoke third-party tools, execute scripts, and complete the transaction. **In this process, the user can neither inspect every underlying request one by one, nor can they avoid making the final decision before assets are actually swapped.**

The authorization method currently used by many Agents involves sending a brief explanation in a chat window and waiting for the user to reply "Yes," "Confirm," or click a simple button.

While this method seemingly completes user authorization, it still has some obvious issues.

First, it's a black box. The user knows they approved something, but doesn'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 generalized natural language statement. The user is only confirming a vague intention, not the imminent real action.

Second, a chat reply does not equal a digital signature. Anyone with access to a logged-in device—whether they have the phone, control the chat account, or simply operate it next to the user—could type a "Yes." The system can at most confirm this message came from an account, but it cannot confirm it was actually authorized by the account owner.

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

This creates a clear trust paradox: **We hope to limit the Agent through a confirmation interface, yet we let the Agent itself decide what the user sees when confirming.**

When an Agent is only responsible for summarizing articles or organizing information, this lack of transparency might just lead to incorrect answers. But when it starts interacting with 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 (Read more: Sign is Not Just Signing: When AI Agents Sign for You, Who Holds the Control?).

Therefore, the AI Agent era does not need more "Yes" buttons, but 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 newly launched Sigil aims to do—**position itself as a safety guardrail between the AI Agent and the wallet.**

It does not attempt to stop the Agent from automatically performing all tasks. Instead, users can clearly authorize the Agent during initial setup, specifying which low-risk operations can be performed autonomously and which sensitive operations must be paused, awaiting an independent, clear, and verifiable approval from the user.

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

But **as long as 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 must complete the signing via a Passkey and biometrics before the operation proceeds.

Overall, the entire process can be summarized into four steps:

1. Agent Initiates Operation: The Agent can continue browsing the web, booking services, sending requests, or preparing a transaction, just like a normal Agent.
2. Check Against Pre-set Security Policies: If it belongs to a low-risk operation allowed for autonomous execution, the process can continue. If it involves sensitive actions like sending messages, deleting files, running code, spending funds, or on-chain signing, 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 is not a sentence written by the Agent, but structured content parsed from the actual operation.
4. Execution Only After Sigil Gateway Verification: Only after the Sigil gateway verifies the user's signature can the Agent continue execution. Without user approval, no funds or signatures are moved.

The key to this mechanism is not just adding one more biometric check, but re-establishing the relationship between display, signing, and execution: **What is displayed is the actual request, the user signs what is displayed, and the system ultimately executes what has been signed.**

If these three are inconsistent, Sigil will block the operation.

Ultimately, Sigil does not require the user to approve every single action of the Agent. Through policy settings, it lets the user decide in advance which actions can be automated and which require personal approval. Users can directly select different security levels like Relaxed, Balanced, or Strict, or enter Custom mode to set individual rules for each type of operation.

Taking Balanced mode as an example, some low-risk behaviors may proceed without additional approval, while activities related to high asset security, such as code execution or terminal commands, must be confirmed by Sigil.

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

This is a boundary that Sigil will not compromise on.

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

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

Firstly, the user can accurately see what they are signing. For instance, in Sigil's confirmation card, parameters like the protocol, amount, and recipient are parsed into clear fields. The user doesn't need to trust the Agent's summary or face incomprehensible raw data.

This card itself constitutes the user's authorization content. Taking the initial ETH transaction as an example, what the user ultimately sees shouldn't just be "Buy ETH," but should include the actual assets and amounts 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 should clearly list the merchant, amount, and payee. The closer the displayed content is to the actual 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, verifying the user's identity through device biometrics.** Therefore, even if someone gets hold of an already logged-in Telegram device and can see the confirmation message, they cannot complete the approval by merely typing text or clicking a regular button.

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

Furthermore, Sigil's confirmation page is not a regular message temporarily drawn by the Agent, but a registered independent module with its content fixed on-chain and rendered in a sandbox environment. This means that **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 party initiating the request no longer simultaneously controls the interface displaying the 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 to the request waiting to be executed. This prevents signatures from being reused long-term and prevents request parameters from being silently swapped after user approval.

If the preview content does not match the actual request, the operation is blocked.

Therefore, viewing Sigil in this context, it is not just a new wallet feature. It is imToken's product exploration under the Sign proposition, focusing on a more fundamental question: **When an Agent starts taking action, how do we ensure it still operates within the user's allowed scope?**

This need is particularly intuitive in the Crypto context. In the future, on-chain Agents could help users with routine investments, yield management, fee payments, position adjustments, and risk monitoring, even automatically executing operations across multiple protocols based on preset conditions. This makes it even more critical to consider whether deviations from user expectations can be immediately stopped.

Meanwhile, **Sigil's significance is not limited to Crypto. Whether it's OpenClaw, Hermes, or more Agents running on personal devices and cloud environments in the future,** they are all gradually connecting to email, instant messaging, calendars, files, browsers, terminals, payment tools, and various online services.

While these operations may not necessarily occur on the blockchain, their fundamental relationship is essentially the same: the Agent invokes a user's capability on their behalf. Therefore, Sigil could potentially extend from on-chain transactions to data access, identity usage, file modification, content publishing, service purchases, 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 have mainly served on-chain transactions. However, the more fundamental problem they address has always been how to prove that an action received genuine authorization from a subject.

When Agents start acting on behalf of humans on a large scale, this set of capabilities has the opportunity to extend further from the Crypto world, becoming an infrastructure for users to manage 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 signatures into the new phase where autonomous Agents enter real execution environments.

It does not replace the Agent, nor does it replace the wallet.

It stands between the two.

Final Thoughts

Overall, AI is making the ability to take action increasingly cheap.

In the past, tasks requiring users to switch between multiple apps, involving searching, filling, confirming, and paying, might in the future be automatically decomposed and executed by an Agent following just one natural language instruction.

But "being able to act for the user" and "having obtained effective user authorization" remain two different things.

Because what truly determines whether an intelligent system is trustworthy is not just how many tasks it can accomplish, but whether the user can always understand it, limit it, and stop it when necessary. From this perspective, Sign is not an unnecessary step hindering Agent efficiency. On the contrary, it is arguably the most crucial layer of trust before an Agent can truly access assets and real-world services.

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

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

Let's wait and see.