AI agents are rapidly moving beyond information assistance and into execution. In crypto, that shift means a user may no longer just ask for analysis, but may instead issue a direct instruction such as “use half of the available funds in my wallet to increase my ETH position.” From there, an agent can read balances, search liquidity pools, compare quotes, construct a route, and return with a short message asking for confirmation. The convenience is obvious, but so is the problem: at the moment of approval, what exactly has the user authorized?
That question is no longer theoretical once agents can touch wallets, accounts, payment flows, browsers, file systems, and terminals. A user may only see a summarized sentence and a “Yes” button, while the actual operation can include protocol calls, token approvals, script execution, spending limits, and transaction signing. In its latest brand update, imToken introduced a fourth “S” in addition to Store, Send, and Stake: Sign. The point is not cosmetic branding. It reflects a practical security concern: when software begins acting on a user’s behalf, how does the user retain informed consent, final approval, and meaningful control?
From clear signing to a new authorization problem in the AI agent era
Historically, many wallet-signing risks in crypto came from the fact that users could not interpret raw transaction data. Onchain actions are often represented by opaque contract addresses, function parameters, and hex payloads. Ordinary users cannot easily tell whether a request means a token transfer, a swap, or a more dangerous asset operation. That is why the wallet industry has pushed Clear Signing, sometimes framed as “what you see is what you sign”: translate machine-readable data into human-readable meaning before the user signs.
AI agents make that challenge much broader. The hidden object is no longer just a single transaction. It may be an entire action chain planned and assembled by the agent. To complete something as simple as “buy ETH with half my available liquidity,” an agent may need to inspect balances, discover pools, call third-party tools, execute scripts, and prepare the final transaction. The user cannot realistically review every low-level request in that chain, yet still needs to make the final decision before funds move.
Today, many agents still rely on an extremely lightweight authorization model: a short message in a chat window, followed by a “Yes,” “Confirm,” or a generic button click. On the surface, that looks like user approval. In reality, it is often approval of an abstract intent rather than approval of the real request that will be executed. The amount involved, the recipient, the protocol route, any token approvals, and other critical parameters may all be hidden behind compressed natural-language wording.
Why chat-based approval is insufficient
The first weakness of the “reply Yes” model is that it is effectively a black box. The user knows that something has been approved, but not necessarily how much value is being moved, who the counterparty is, what exact parameters are being signed, or what downstream actions are bundled into the request. The confirmation process therefore captures trust in the agent’s summary, not understanding of the actual operation.
The second weakness is identity assurance. A chat reply is not the same thing as a cryptographic signature. If someone can access a logged-in device, take control of a messaging account, or physically operate the device near the user, that person can also type “Yes.” At best, the system can conclude that the message came from a particular session or account. It cannot reliably prove that the approval came from the true account owner in that moment.
An even more difficult issue is that the confirmation interface itself may be controlled by the same party that initiated the action. If the agent both generates the request and controls the screen or message used to present that request, it can omit key parameters, blur the language, or even display an apparently harmless operation while submitting a different backend request. In that setup, the interface meant to constrain the agent is still produced by the agent. The result is a trust paradox: the user depends on the untrusted actor to explain what is being approved.
When an agent only summarizes articles or organizes information, this opacity may merely lead to mistakes or bad outputs. But once the same agent can interact with funds, identities, files, and terminal environments, a vague approval can translate into asset loss, data leakage, or device-level risk. The AI agent era therefore requires more than extra “Yes” buttons. It requires a signing mechanism that can demonstrate what the user saw, what the user approved, and what the system ultimately executed.
How Sigil works between the agent and the wallet
Sigil is imToken’s early proof-of-concept product under its Sign thesis. Its core principle is explicit: What you see is what you sign. Sigil does not try to eliminate automation or stop agents from doing useful work. Instead, it sits between the AI agent and the wallet as a security guardrail. The user can define boundaries at the outset, specifying which low-risk actions the agent may complete autonomously and which sensitive operations must pause and wait for independent approval.
Within those predefined boundaries, the agent can continue operating normally. It may browse the web, make reservations, send requests, or prepare a transaction in much the same way as any standard agent workflow. But once the action triggers a sensitive policy—such as sending messages, deleting files, running code, spending funds, or signing an onchain transaction—Sigil interrupts the flow. It parses the real request into a structured confirmation card and sends that card to the user through Telegram.
The user must then approve the request using a Passkey and biometric authentication. Only after the Sigil gateway verifies the user’s signature can the agent continue execution. Without approval, no funds move and no signature is released. This architecture matters because it is not merely adding another biometric checkpoint. It is redefining the relationship among display, signing, and execution. The request displayed to the user is the request the user signs, and the request ultimately executed by the system must match that signed content. If any mismatch appears, Sigil blocks the operation.
The article frames this flow in four broad stages. First, the agent initiates an action, whether browsing, booking, requesting, or assembling a trade. Second, the system checks whether the request triggers a preconfigured security policy. Third, if it does, Sigil generates a clear approval card that shows parameters such as merchant, amount, recipient, and other key details extracted from the real operation rather than written as free-form text by the agent. Fourth, the gateway verifies the user’s approval before allowing execution to proceed.
Policy tiers, Passkey approval, and independent rendering as three layers of protection
Sigil’s first protection layer is policy control. The user does not need to manually approve every single agent action. Instead, the system allows the user to choose among Relaxed, Balanced, Strict, or a Custom mode that sets rules for each class of behavior individually. In Balanced mode, some lower-risk operations can proceed without additional friction, while actions with stronger security implications—such as code execution or terminal commands tied to asset risk—must go through Sigil review. Spending funds and signing transactions, however, always require the user’s own approval regardless of policy choice. That boundary is presented as non-negotiable.
The second layer is identity verification. Sigil uses Passkey as the security entrance for approval and couples it with biometric confirmation on the device. This means that even if someone gets access to a Telegram session on a logged-in device and can read the approval message, that person still cannot approve the action simply by typing text or pressing a generic button. Approval is bound to the user, not merely to whoever is holding the device at that time.
The article also notes that Sigil adopts a mnemonic-free design. Users do not need to manage or enter a new seed phrase, nor do they have to hand a wallet private key directly to an agent. The real approval power remains under the user’s control through their own Passkey and biometrics. In operational terms, this is important because it narrows the exposed trust surface while avoiding additional key-management complexity.
The third layer of protection is the independence of the confirmation interface itself. Sigil’s confirmation page is not described as a temporary, agent-generated chat message. Instead, it is a registered independent module whose content is fixed onchain and rendered inside a sandbox. This reduces the chance that the agent can alter the page after initiating a sensitive operation, modify the display logic, or create a deceptive interface that imitates a legitimate confirmation card. The requesting party no longer fully controls the interface that describes the request.
Sigil further combines this with one-time signatures, short validity periods, and hash binding of request parameters. Together, these mechanisms aim to ensure that the content shown on the card corresponds to the exact request waiting to be executed. A signature cannot be reused indefinitely, and parameters cannot be quietly swapped after approval. If the previewed content and the actual request diverge, the operation is stopped.
Why this matters for crypto workflows and beyond
In crypto, the use case is immediate and intuitive. Future onchain agents may handle recurring investments, yield management, fee payments, position rebalancing, and risk monitoring on behalf of users. They may also move across multiple protocols according to predefined conditions. The more autonomy these systems gain, the more important it becomes to have a mechanism that can halt them when behavior departs from user expectations. Sigil is designed to provide that separate layer of constraint rather than asking the user to trust the agent’s own description of what it is doing.
At the same time, the article argues that the idea is not limited to blockchain transactions. It mentions OpenClaw, Hermes, and a broader future wave of agents operating across personal devices and cloud environments, connecting with email, messaging, calendars, files, browsers, terminals, payment tools, and online services. Although these actions may not occur onchain, the underlying pattern is similar: an agent is invoking a capability that belongs to the user, in the user’s name. Under that logic, Sigil-like authorization could eventually extend to data access, identity use, file modification, content publishing, service purchasing, and broader automation tasks.
This broader framing also explains why wallet infrastructure may gain new relevance in the AI agent era. Key management, digital signatures, identity verification, permission control, and asset security have long been core wallet capabilities. But at a deeper level, those systems were always solving a more universal problem: how to prove that an action was genuinely authorized by a specific subject. As agents increasingly act for people at scale, that capability may evolve from a crypto-native toolset into general infrastructure for machine permissions and intelligent identity management.
Seen through that lens, Sigil is presented as a joint exploration by imToken and OpenClaw that brings imToken’s decade of experience in self-custody, wallets, and digital signatures into a phase where autonomous agents are moving into real execution environments. It does not replace the agent, and it does not replace the wallet. It sits between them, trying to ensure that automation does not outrun consent.
The article ends on a practical distinction: the fact that AI can act for a user more cheaply and more quickly does not mean it has obtained valid authorization. In the coming workflow model, a single natural-language instruction may replace a long sequence of search, data entry, confirmation, and payment steps across multiple applications. But capability and consent are not the same thing. The system becomes trustworthy not merely because it can complete tasks, but because the user can still understand it, constrain it, and stop it when necessary. In that sense, Sign is not a redundant friction layer standing in the way of efficiency. It may instead be a foundational trust layer for any agent that wants to enter finance, assets, and real-world services.