从盲目點「Yes」，到看清再簽名：Sigil 如何為 AI Agent 加上一道安全護欄？

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

The Agent then reads the balance, searches liquidity pools, compares quotes, and constructs a transaction path. Dozens of seconds later, it sends you a message: "Found a suitable buy方案. 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 price and slippage? Which protocol was invoked? Which wallet and how many assets were used? Does it include token approval or other additional operations? You didn't truly see any of this information; you only chose to trust the Agent's summary of the operation.

This is precisely a new type of risk gradually exposed as AI Agents transition from "answering questions" to "taking actions on behalf of users": The Agent can now browse the web, log into accounts, and even complete payments and on-chain signatures. Yet, the final authorization interface the user faces often remains a vague chat message and a confirmation option that contains almost no effective information.

A single "Yes" begins to decide your funds, your data, and your device.

Therefore, in imToken's latest brand upgrade, a fourth "S"—Sign—has appeared 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 how users can continue to retain the ultimate right to know, the right to approve, and the right to control when more and more software begins to act on their behalf.

And Sigil is precisely the first early-stage POC (Proof of Concept) 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 Re-understand Sign?

In the past, most signing risks faced by crypto wallets 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. 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 the raw data into information humans can understand, allowing users to see the details before signing. This is Clear Signing, aiming to bridge the gap between machine data and user comprehension. (For more details, see the article: Ethereum Promotes 'What You See Is What You Sign': Why Clear Signing is a Necessary Capability Patch for the AI Era?)

But the problem introduced by AI Agents is far more complex.

Because what the user can no longer see isn't just a single on-chain transaction, but potentially an entire operational chain automatically planned and executed by the Agent.

As mentioned earlier, to accomplish a goal like "use half my current liquid funds to add to my ETH position," an Agent might need to read the wallet balance, search on-chain pools, call third-party tools, execute scripts, and complete the transaction. In this process, it's impossible for the user to check every underlying request one by one, yet they must make the final decision before the assets are actually swapped.

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

While this method ostensibly completes user authorization, it still has some obvious problems.

First, it's a black box. The user knows they approved something, but doesn't necessarily know the specific amount approved, the exact recipient, or what the Agent ultimately signed on their behalf. The real operational parameters are hidden behind a highly generalized natural language sentence. The user is confirming a vague intention, not the imminent real action.

Second, a chat reply is not a digital signature. If someone gains access to a logged-in device (retrieving the phone, controlling the chat account, or operating directly near the user), they could type a "Yes." The system can at most confirm the message came from a certain account, but cannot confirm it was genuinely authorized by the account owner.

More problematic is that the confirmation interface itself can be forged. If the Agent can generate the approval message, then the party initiating the operation also controls the interface showing the operation details 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 a clear trust paradox: We want to constrain the Agent through a confirmation interface, but we let the Agent decide what the user sees when confirming.

When the Agent is only responsible for summarizing articles or organizing information, this lack of transparency might just result in incorrect answers. But when it starts accessing accounts, funds, file systems, and terminal environments, the consequences of a vague approval can escalate from "inaccurate answer" to real asset loss, data leaks, or device risks. (For more details, see the article: Sign is Not Just Signing: When an AI Agent Signs for You, Who Holds the Control?)

Therefore, the era of AI Agents 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 precisely what imToken's newly launched Sigil aims to do—to position itself as a security guardrail between the AI Agent and the wallet.

It doesn't attempt to prevent the Agent from automatically executing all tasks. Instead, during the initial setup, users can explicitly authorize the Agent, specifying which low-risk operations it can handle autonomously, and which sensitive operations must be paused, waiting for an independent, clear, and verifiable approval from the user.

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

But as soon as an operation tagged as sensitive by the user is involved—especially spending funds or signing transactions—Sigil pauses the process, parses the real request into a clear confirmation card, and sends it to the user's Telegram. The user must pass key and biometric authentication to sign before the operation continues.

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

1. Agent Initiates Operation: It can continue browsing the web, booking services, sending requests, or preparing a transaction. It works no differently from a standard Agent.
2. Judgment on whether to trigger pre-set security policies: If it's a low-risk operation allowed for autonomous execution by the Agent, the process continues. 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 gives explicit approval via Passkey: A clear confirmation card is sent to Telegram. It directly displays the merchant, amount, recipient, and other key parameters. What the user sees is not a sentence written by the Agent itself, but structured content parsed from the real operation.
4. Finally, 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 isn't just adding an extra biometric check. It's about re-establishing the relationship between display, signing, and execution: the display shows the actual request, the user signs what is displayed, and the system ultimately executes only the request that was signed.

If these three are inconsistent, Sigil blocks the operation.

Ultimately, Sigil doesn't require users to approve every single action of the Agent. Instead, through policy settings, it lets users 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 the Balanced mode as an example, some low-risk behaviors can proceed without extra approval, while actions related to high asset security, like running code or executing terminal commands, must be confirmed by Sigil.

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

This is a boundary 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 a three-layer guarantee.

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 user's authorization content. Taking the initial ETH transaction as an example, the user shouldn't just see "Buy ETH." They should see the actual assets and amount used, the transaction recipient, key transaction parameters, and other operational information needed for user understanding.

For real-world payment scenarios, it's similar. 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 actual operation, the more meaningful the user's authorization becomes.

Simultaneously, the only person who can truly sign is the user themselves. This is because Sigil uses Passkey as the secure entry point for approving operations, confirming the user's identity through device biometrics. Therefore, even if someone gains access to a device logged into Telegram and sees the confirmation message, they cannot approve it merely 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 store or input a new set of seed phrases, nor do they need to directly hand over wallet private keys to the Agent. The true control over approval capability remains with the user's own Passkey and biometrics.

Furthermore, Sigil's confirmation page isn't a regular message temporarily generated by the Agent. It's an independently registered module. Its content is fixed on-chain and rendered within 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 party initiating the request no longer simultaneously controls the interface displaying the request. Combined with single-use signatures, short validity periods, and hashing request parameters, Sigil ensures the content in the confirmation card corresponds to the final request awaiting execution. This prevents signatures from being reused long-term and prevents request parameters from being quietly swapped after user approval.

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

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

In the Crypto scenario, this need is particularly intuitive. Future on-chain Agents could help users complete regular investments, yield management, fee payments, position adjustments, and risk monitoring, even automatically executing operations across multiple protocols based on pre-set conditions. This makes it even more critical to consider whether an Agent's behavior can be stopped immediately if it deviates from the user's expectations.

Simultaneously, Sigil's significance isn't limited to Crypto. Currently, whether it's OpenClaw, Hermes, or future Agents running on personal devices and cloud environments, they are gradually accessing email, instant messaging, calendars, files, browsers, terminals, payment tools, and various online services.

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

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. However, the more fundamental problem they address has always been how to prove an action received genuine authorization from a subject.

When Agents start acting on a large scale, this set of capabilities has the potential to extend from the Crypto world and become 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 of experience in self-custody, wallets, and digital signatures into the new phase where autonomous Agents begin to operate in real execution environments.

It doesn't replace the Agent. It doesn't replace the wallet.

It stands between them.

Final Thoughts

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

Tasks that previously required users to switch back and forth between multiple apps, involving searching, filling forms, confirming, and paying, might soon be automatically broken down and executed by an Agent with just a single natural language command.

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

Because what truly determines whether an intelligent system is trustworthy isn't just how many tasks it can complete, but whether the user can always understand it, constrain it, and make it stop when necessary. From this perspective, Sign is not a redundant step hindering Agent efficiency. On the contrary, it might 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 continue to retain the final say when more and more machines start acting on their behalf.

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

Let's wait and see.