Imagine a future in which all you need to tell an AI agent is:
“Use half of the available funds in my wallet to buy more ETH.”
The agent immediately begins checking your balance, searching across liquidity pools, comparing quotes, and building an execution route. A few dozen seconds later, it sends you a message:
“I found a suitable route. Confirm?”
You reply with a simple “Yes.”
But what exactly have you approved?
Which pool did the agent choose? What execution price and slippage should you expect? Which protocol will it interact with? Which wallet will it use, and how much will it spend? Does the operation involve token approvals or any other actions?
You have not actually seen any of this information. You are simply choosing to trust the agent’s summary.
This is a new category of risk emerging as AI agents move from answering questions to acting on behalf of users.
Agents can now browse websites, log in to accounts, complete payments, and even initiate or sign on-chain transactions. Yet the final authorization step presented to users is often still little more than a vague chat message and a confirmation option containing almost no meaningful information.
A single “Yes” can determine what happens to a user’s funds, data, and devices.
This is why imToken’s latest brand evolution introduces a fourth S alongside Store, Send, and Stake: Sign.
If the first three pillars correspond to asset custody, value transfer, and network participation, Sign addresses a new question: as more software begins acting on behalf of users, how can users retain the right to understand, approve, and remain in control?
Sigil is the first proof-of-concept product built around this Sign vision.
Its core principle is simple but important:
What you see is what you sign.
1. When Agents Start Acting, Why Do Wallets Need to Rethink Signing?
Historically, many signing risks in crypto wallets have stemmed from users not understanding what they were signing.
At the protocol level, an on-chain transaction may appear only as a contract address, function parameters, and hexadecimal data. For ordinary users, it can be extremely difficult to determine whether the request represents a transfer, a swap, or a more dangerous asset operation.
That is why wallets need to translate raw transaction data into human-readable details that users can review before signing.
Clear signing, also known as “what you see is what you sign,” is designed to bridge the gap between machine-readable data and human understanding.
Further reading: Why Clear Signing Is Becoming Essential in the AI Era.
AI agents, however, make the problem more complex.
Users may no longer be authorizing a single on-chain transaction. Instead, they may be authorizing an entire chain of actions planned and executed by an agent.
To complete a goal such as “use half of my available liquid funds to buy more ETH,” an agent may need to check wallet balances, search on-chain liquidity pools, call third-party tools, run scripts, and prepare a transaction.
Users cannot realistically inspect every underlying request one by one. Yet before any assets are exchanged, they still need to make the final decision.
Many agents today handle authorization by sending a short message in a chat window and waiting for the user to reply “Yes” or “Confirm,” or to tap a standard confirmation button.
This may resemble user authorization, but in practice it creates several obvious problems.
First, it is a black box.
Users know they are approving something, but they may not know the exact amount, recipient, protocol, or action the agent will ultimately execute on their behalf.
The real execution parameters are hidden behind a highly summarized natural-language sentence. The user is confirming only a vague intent, not the exact action the system is about to perform.
Second, a chat reply is not equivalent to a digital signature.
Anyone with access to an already authenticated device or session may be able to type “Yes.” At most, the system can verify that the message came from an authenticated account or session. It cannot necessarily confirm that the approval was intentionally provided by the account owner.
More importantly, the confirmation interface itself may also be manipulated.
If the same agent that initiates an operation also controls how that operation is presented to the user, it could omit key parameters, use ambiguous wording, or display something that appears harmless while submitting a different request in the background.
This creates a clear trust paradox.
We want the confirmation interface to constrain the agent, yet we may also allow the agent itself to determine what the user sees at the moment of confirmation.
When an agent is only summarizing articles or organizing information, this lack of transparency may result in an inaccurate answer.
But when an agent gains access to accounts, funds, file systems, and terminal environments, vague approval can lead to real asset loss, data leakage, or device-level risk.
Further reading: A Signature Is More Than a Signature: When an AI Agent Signs for You, Who’s in Control?
What agent-based systems need is not more “Yes” buttons.
They need an authorization mechanism that can create a verifiable link between what the user saw, what the user approved, and what the system ultimately executed.
2. Sigil: A Signing Guardrail Between AI Agents and Wallets
This is the problem Sigil, imToken’s newly introduced proof of concept, is designed to address.
Sigil acts as a safety guardrail between AI agents and wallets.
It does not seek to prevent agents from automating tasks altogether.
Instead, during setup, users can explicitly authorize an agent and define which low-risk actions it may complete autonomously and which sensitive actions require separate, explicit, and verifiable user approval.
Within the boundaries defined by the user, the agent can continue operating efficiently.
But when an operation involves something the user has classified as sensitive—particularly spending funds or authorizing on-chain transactions—Sigil pauses the flow, parses the actual request into a structured confirmation card, and delivers it to the user through Telegram.
The user must then approve the request using a passkey and biometric verification before the operation can continue.
The flow can be summarized in four steps.
Step 1: The agent initiates an action
The agent continues its task, whether that involves browsing websites, booking services, sending requests, or preparing a transaction.
Step 2: Sigil checks the user’s security policy
Sigil determines whether the action triggers the user’s preconfigured security policy.
If the action is classified as low risk and the user has allowed the agent to complete it autonomously, the flow can continue.
If it involves actions such as sending messages, deleting files, executing code, spending funds, or authorizing on-chain transactions, Sigil pauses execution and parses the request.
Step 3: The user reviews and approves the request
A structured confirmation card is delivered through Telegram.
Depending on the operation, the card may display key parameters such as the action type, merchant, protocol, asset, amount, recipient, and other relevant details.
The confirmation is not based solely on a natural-language summary generated by the agent. It is based on structured information parsed from the actual request.
The user then provides explicit approval using a passkey and biometric verification.
Step 4: Sigil verifies the approval
Only after the Sigil gateway verifies the user’s signature can the agent continue.
Without user approval, no funds are moved and no transaction is signed.
The key point is not simply that Sigil adds another biometric verification step.
More importantly, it establishes a verifiable connection between display, signing, and execution.
What is displayed is derived from the actual request.
What the user signs is cryptographically bound to the displayed content.
What the system executes must match the signed request.
If these elements do not match, Sigil blocks the operation.
Sigil does not require users to approve every action an agent takes.
Instead, it allows users to define in advance which actions may be automated and which require personal approval.
Users can select different security levels, such as Relaxed, Balanced, or Strict, or use Custom mode to define rules for individual categories of actions.
In Balanced mode, for example, some lower-risk actions may proceed without additional approval, while higher-risk actions involving code execution, terminal access, sensitive data, or asset security must go through Sigil confirmation.
Spending funds and authorizing on-chain transactions always require user approval, regardless of the selected security mode.
This requirement applies across all security settings.
3. From Crypto to AI Agents: What Is Sigil Trying to Protect?
Built around the principle of “What you see is what you sign,” Sigil provides three layers of protection.
First, users can clearly see what they are approving
In Sigil’s confirmation card, key parameters such as the protocol, amount, asset, recipient, and action type are presented as structured fields.
Users do not need to rely solely on the agent’s summary, nor do they need to interpret raw data they cannot understand.
The user’s approval is bound to the content shown on the card.
Returning to the ETH transaction at the beginning of this article, the final confirmation should not simply say “Buy ETH.”
It should show the asset being spent, the amount, the recipient or contract, the relevant protocol, and the key transaction parameters the user needs in order to make an informed decision.
The same principle applies to real-world payments.
The interface should not merely display “Confirm payment.” It should clearly show the merchant, amount, recipient, and other relevant details.
The more closely the displayed information reflects the actual operation, the more meaningful the user’s authorization becomes.
Second, approval requires the user’s registered authentication method
Sigil uses a passkey as the authentication mechanism for approvals and verifies the request through device biometrics.
This means that even if someone gains access to a device already logged in to Telegram and can view the confirmation message, they cannot complete approval simply by typing a sentence or tapping an ordinary button.
Approval is tied to the user’s registered passkey and biometric verification, not merely to whoever has access to the active device or messaging session.
Sigil also adopts a mnemonic-free design.
Users do not need to store or enter a new mnemonic phrase, nor do they need to expose their wallet private key to the agent.
The ability to approve requests remains controlled through the user’s passkey and biometric verification.
Third, the confirmation interface is independent of the agent
Sigil’s confirmation page is not an ordinary message dynamically generated and controlled by the agent.
It is a separately registered module whose rendering logic is anchored on-chain and executed in a sandboxed environment.
This means that after initiating a sensitive operation, the agent cannot simply replace the page, alter its display logic, or imitate the confirmation interface in order to mislead the user.
The party initiating the request no longer controls how that request is presented for approval.
Sigil also uses mechanisms such as single-use approvals, short validity periods, and cryptographic binding between the signature and the request parameters.
These mechanisms help ensure that the content displayed in the confirmation card corresponds to the request awaiting execution.
An approval cannot be reused indefinitely, and the underlying request parameters cannot be altered after approval without invalidating the signature.
If the previewed content does not match the request submitted for execution, the operation is blocked.
Seen in this context, Sigil is not merely another wallet feature.
It is imToken’s product-level exploration of the Sign vision and addresses a more fundamental question:
When agents begin to act, how can we ensure that they continue operating only within the boundaries users have authorized?
In crypto, this need is especially intuitive.
On-chain agents may eventually help users manage recurring purchases, yield strategies, transaction fees, position adjustments, risk monitoring, and automated execution across multiple protocols based on predefined conditions.
In that environment, one question becomes increasingly important:
If an agent’s behavior deviates from the user’s expectations, can it be stopped immediately?
At the same time, Sigil’s relevance is not limited to crypto.
Whether through OpenClaw, Hermes, or future agents running on personal devices and in cloud environments, agents are gradually gaining access to email, messaging apps, calendars, files, browsers, terminals, payment tools, and a growing range of online services.
These operations may not take place on-chain, but the underlying relationship is fundamentally similar.
The agent is exercising a capability owned by the user and acting under the user’s identity or authority.
Sigil could therefore extend beyond on-chain transactions into areas such as data access, identity use, file modification, content publishing, service purchases, and automated workflows.
This also explains why capabilities developed by the wallet industry may take on new significance in the AI agent era.
Private key management, digital signatures, identity verification, permission confirmation, and asset security were once used primarily for on-chain transactions.
But the more fundamental problem they have always addressed is how to prove that an action was genuinely authorized by a specific user or entity.
As agents begin acting on behalf of users at scale, these capabilities may expand from the crypto world into broader infrastructure for managing agent identities, automated actions, and machine permissions.
As a joint exploration by imToken and OpenClaw, Sigil applies imToken’s ten years of experience in self-custody, wallets, and digital signatures to a new environment in which autonomous agents are beginning to perform real actions.
It does not replace the agent.
Nor does it replace the wallet.
It stands between the two.
Closing Thoughts
AI is making complex actions easier and cheaper to execute than ever before.
Tasks that once required users to switch between multiple applications, search for information, complete forms, verify details, and make payments may soon be planned and executed automatically by an agent in response to a single natural-language instruction.
But being capable of acting on behalf of a user and having received valid authorization from that user are two different things.
What determines whether an intelligent system can be trusted is not only how many tasks it can complete.
It is whether users can understand what the system is doing, limit its authority, and stop it when necessary.
From this perspective, Sign is not merely an additional layer of friction that slows agents down.
It may become one of the most important layers of trust required before agents can be safely integrated into financial and real-world services.
Store gives users custody of their assets.
Send enables value transfer.
Stake enables participation in open networks.
Sign helps users retain final authority when machines act on their behalf.
The value of Sigil lies in turning this abstract question of control into a functional proof of concept that can be tested, validated, and continuously improved.