The "Lobster" OpenClaw, which had been quiet for a while, released version 2.0 on August 30.

According to the official statement, this is the largest update in OpenClaw's history, with over 16,000 Pull Requests accumulated, almost touching the entire product stack including installation, messaging, memory, Skills, models, Automations, browser, native applications, Plugins, and security mechanisms.

However, compared to these complex feature lists, what is actually more worth paying attention to is the increasingly clear evolution route behind OpenClaw 2.0: The Agent is becoming increasingly capable of really "getting things done."

At the same time, it has also brought the industry to an inescapable trust dilemma: As the Agent becomes more capable of autonomously deciding "how to do it," how can we ensure that each crucial operation does not exceed the boundaries truly authorized by the user?

1. The Dilemma of Agent Autonomy: Full Delegation or Layered Confirmation?

In the past year, the most obvious change in AI Agents is not just that the underlying models have become smarter.

As infrastructures such as MCP, Skills, Plugins, browser control, and code execution gradually mature, Agents begin to have more and more real "hands and feet" that can influence the external world, such as modifying information, clicking buttons, or directly controlling the browser through computer use (see also "Has the inflection point for Agentic AI arrived? When AI learns to 'act on its own,' how will it reconstruct the safety boundaries of Web3?").

But the problem arises precisely here; under the existing interaction paradigms, it is often easy to fall into two extremes.

One is full delegation, directly handing over the private key, or a long-term valid Session Key with sufficient permissions to the Agent, allowing it to make its own judgment and execute.

This mode certainly offers the best automation experience, but the risks are equally concentrated. Once encountering prompt injection, malicious web pages, or environmental contamination, or if the model itself has an understanding bias, errors can propagate all the way through the entire execution chain and ultimately turn into a real operation (see also "Signing is not just a signature: When AI Agents sign on your behalf, who still holds the control?").

After all, in ordinary internet scenarios, this might just be sending the wrong email or deleting the wrong file, but on-chain, a erroneous transaction is often irreversible.

Another is complete non-delegation, where every operation and every sub-call pops up a signature window requesting confirmation, which improves security, but significantly reduces the meaning of automation.

After all, if an Agent helps a user complete a complex DeFi strategy that involves multiple steps, if each step requires the user to pick up their phone to "Approve," then the user has merely shifted from "clicking the button" to being a "manual stamp machine" constantly stamping for the Agent.

In other words, the freedom in between is the source of the Agent's efficiency and also a new source of risk.

From this perspective, the core of the problem is not "whether to delegate power to the Agent," but whether the granularity of authorization and the verification mechanisms possess dynamic elasticity, as traditional permission management is binary (either allow or deny), while the tasks faced by Agents are evidently much more complex.

For example, a transaction of $10 is different from a transaction of $100,000; interacting with a protocol that has been used for a long time is different from suddenly authorizing a strange contract; completing a swap explicitly requested by a user is not the same risk level as having the Agent autonomously decide to move assets to another chain.

Therefore, as Agents become more capable of autonomous action, permissions can no longer be just a simple switch.

What is truly required is a set of security mechanisms that allow them to act freely within boundaries and automatically stop when crossing those boundaries.

2. How to Build a "Verifiable" Defense Line for Autonomous Agents?

In fact, OpenClaw has not ignored this issue.

Currently, it provides a multi-layered permission mechanism, for example, Plugins can pause before executing specific operations and require user confirmation, and when it involves host commands, there are independent Exec Approvals and Allowlists, etc.

Compared to giving all tools and permissions directly to the Agent, this is a significant step forward. However, when the Agent truly enters payment, trading, and asset management scenarios, a more nuanced issue arises: Allowing the Agent to use a capability is not the same as authorizing the Agent to complete a specific action.

For example, allowing the Agent to use a browser does not mean allowing it to purchase anything on any website; allowing the Agent to access an email does not equal allowing it to send an email to anyone in your name; similarly, allowing the Agent to call a wallet should never equate to allowing it to send any amount to any address.

Thus, the permission system in the Agent era may need to distinguish between two different issues. One is capability permission, which is whether the Agent can use the browser, terminal, email, or wallet? The other is a more specific action authorization, such as at this moment, is the action it is about to execute truly something the user has permitted?

So how can we allow the Agent to fully automate within clear boundaries while returning decision-making power back to the user when truly crossing those boundaries?

This is also the reason why imToken is exploring Sigil. Its core is not to add another traditional "confirmation pop-up" for the Agent but to attempt to establish a layer of security barriers that can be clearly constrained between the user and the Agent through verifiable signatures and fine-grained permission control.

One important principle is "What you see is what you sign," you sign what you see.

In simple terms, users can pre-authorize the Agent with a certain range of permissions to automatically complete low-risk actions that comply with established strategies; when actions touch on monetary amounts, unfamiliar protocols, or other critical permission boundaries, execution should pause and hand the specific request back to the user for confirmation.

More importantly, this confirmation should not just be a vague "The Agent is preparing to execute a transaction, do you agree," but what the user really needs to see are the key parameters that have changed in this operation: what assets are being used, how much is the amount, who the interaction is with, and ultimately what is truly prepared for execution.

Because only when what the user sees, what the user authorizes, and what the system ultimately executes correspond can a confirmation truly make sense.

Sigil, focusing on this point, also attempts to use mechanisms such as Passkeys, biometrics, one-time signatures, short validity periods, and request parameter bindings, allowing key authorizations to be comprehensible to users and verifiable by the system.

This means that an authorization is not just "someone clicked confirm," but can further answer who approved it, what was approved, and whether what was ultimately executed was what was seen at the time.

From this perspective, what Sigil truly aims to solve is not "how to make the Agent do less."

On the contrary.

It is trying to solve how to allow the Agent to do more, without taking away the user's ultimate control (see also "From blindly clicking 'Yes' to understanding before signing: How does Sigil add a safety fence for AI Agents?").

3. From Managing Assets to Managing Agents

Stepping back further, one can see that this is also a role shift that wallets are facing.

Since the birth of Ethereum, the imToken wallet has experienced and witnessed two critical generations: from the 1.0 era of managing a single private key to the evolution into the 2.0 era of optimizing interaction experiences through account abstraction (AA).

With the popularization of autonomous Agents like OpenClaw 2.0, wallets are undoubtedly entering a third-generation evolution, needing to further assist users in managing Agents that can autonomously judge and work continuously.

This is also why the private key management, digital signature, identity verification, and permission isolation capabilities accumulated in the wallet industry over the years may gain new meaning in the Agent era.

Because on the surface, these technologies solve "how to securely sign an on-chain transaction," but what they are actually handling is a more universal problem: how to prove that an action has genuinely obtained authorization from a specific subject.

Today, this action might be transferring out 1 ETH. In the future, it could also be sending an email, modifying a document, using a digital identity, purchasing a service, or allowing the Agent to continuously execute a set of automated strategies over the next week.

These actions do not necessarily all occur on the blockchain, but the underlying relationship is very similar: the Agent is invoking a capability that belongs to the user in the user’s name.

Therefore, the significance of Sigil may not be limited to Crypto.

As OpenClaw, Hermes, and more Agents operating in personal devices or cloud environments gradually connect to emails, instant messaging, calendars, documents, browsers, terminals, and payment tools, "how to prove that this action has indeed been authorized by the user" will become an increasingly common issue.

Thus, Sigil may also extend from on-chain transactions to data access, identity usage, document modification, content publishing, service purchases, and automated tasks in the future.

Overall, as a joint exploration by imToken and OpenClaw, Sigil aims to bring the expertise amassed by imToken in self-custody, wallets, and digital signatures over the past decade into a new stage where autonomous Agents begin to enter real execution environments.

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

It stands between the two.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。