放權還是失控？Agent 自主時代，我們需要怎樣的「可驗證授權」？

The "Lobster" OpenClaw, which had been quiet for some time, released version 2.0 on August 30th.

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

But compared to these extensive feature lists, what's more noteworthy is the increasingly clear evolution path behind OpenClaw 2.0: Agents are becoming genuinely capable of "taking action."

At the same time, it also brings the industry to an unavoidable trust dilemma: As Agents become more capable of autonomously deciding "how to do things," how can we ensure that each of their critical operations doesn't cross the boundaries of what users have truly authorized?

1. The Dilemma of Agent Autonomy: Full Delegation or Layer-by-Layer Confirmation?

Over the past year, the most obvious change in AI Agents isn't just that the underlying models have become smarter.

As infrastructure like MCP, Skills, Plugins, browser control, and code execution gradually matures, Agents are gaining more and more "hands and feet" that can truly influence the external world—such as modifying information, clicking buttons, or directly controlling a browser through computer use (Further reading: Has the Agentic AI Inflection Point Arrived? When AI Learns to "Act on Its Own," How Do We Rebuild Web3's Security Boundaries?).

But the problem lies precisely here. Under the existing interaction paradigm, we often fall into two extremes.

One is full delegation—directly handing the Agent a private key, or a long-term, highly privileged Session Key, letting it judge and execute on its own.

This model naturally offers the best automation experience, but risks are equally concentrated. Once a prompt injection, malicious webpage, or environment pollution occurs, or the model itself has an understanding偏差, errors can propagate along the entire execution chain, eventually turning into real-world actions (Further reading: Sign Isn't Just Signing: When an AI Agent Signs for You, Who Still Holds the Control?).

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

The other extreme is no delegation at all—requiring confirmation pop-ups for every action and every sub-call. Security is improved, but the value of automation diminishes significantly.

After all, if an Agent helps a user execute a complex DeFi strategy involving multiple steps, and the user has to pick up their phone to "Approve" each one, then the user is essentially just transforming from "pressing buttons themselves" to becoming a "manual approval stamp" for the Agent.

In other words, the freedom in between is both the source of Agent efficiency gains and a new source of risk.

From this perspective, the core issue isn't really "whether to delegate authority to Agents," but whether the granularity of authorization and verification mechanisms possess dynamic flexibility, because traditional permission management is binary (either allow or deny), while the tasks Agents face are clearly much more complex.

Similarly, for a transaction, $10 and $100,000 are different; interacting with a protocol you've used long-term is different from suddenly authorizing an unfamiliar contract; completing a Swap the user explicitly requested is different from the Agent autonomously deciding to bridge assets to another chain—these are not the same risk level.

Therefore, the more autonomously Agents can act, the less permissions can be just a simple on/off switch.

What's truly needed is a security mechanism that allows the Agent to act freely within boundaries, but automatically stops when it's about to cross them.

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

In fact, OpenClaw hasn't ignored this issue.

It currently provides multi-layered permission mechanisms. For example, plugins can pause and request user confirmation before executing specific actions, and there are separate Exec Approvals and Allowlists for host commands.

Compared to handing all tools and permissions over to the Agent at once, this is already a significant step forward. But when Agents truly enter payment, trading, and asset management scenarios, a more nuanced issue arises: Allowing an Agent to use a capability and authorizing an Agent to complete a specific action are actually not the same thing.

Just like allowing an Agent to use a browser doesn't mean allowing it to buy anything on any website; allowing an Agent to access email doesn't mean allowing it to send emails to anyone on your behalf; similarly, allowing an Agent to call a wallet should absolutely not mean allowing it to send arbitrary amounts to arbitrary addresses.

So, the permission system for the Agent era may need to distinguish between two different questions. One is capability permission: Can the Agent use the browser, terminal, email, or wallet? The other is more specific action authorization: At this moment, is the specific thing it's about to execute actually something the user truly allows it to do?

So how do we let Agents fully automate within clear boundaries, while returning decision-making power to the user when they're truly about to cross those boundaries?

This is also why imToken is exploring Sigil. Its core isn't just adding another traditional "confirmation pop-up" for Agents, but rather attempting to establish a safety barrier between users and Agents through verifiable signatures and fine-grained permission controls, one that can be explicitly constrained.

One of the most important principles is "What you see is what you sign."

Simply put, users can pre-grant Agents a certain scope of permissions, allowing low-risk behaviors that conform to established policies to complete automatically. When an operation touches funding limits, unfamiliar protocols, or other critical permission boundaries, execution pauses, and the specific request is handed back to the user for confirmation.

More importantly, this confirmation shouldn't just be a vague "Agent is about to execute a transaction, do you agree?" What users truly need to see are the key parameters that actually change in this operation: which asset is used, what the amount is, who the counterparty is, and what exactly is ultimately going to be executed.

Because only when what the user sees, what the user authorizes, and what the system ultimately executes can correspond to each other, does a confirmation truly hold meaning.

Around this point, Sigil also attempts to use mechanisms like Passkey, biometrics, single-use signatures, short validity periods, and request parameter binding, making critical authorizations not only understandable to users but also verifiable by the system.

This means an authorization isn't just "someone clicked confirm," but can further answer who approved it, what was approved, and whether what was finally executed is actually the same thing that was seen at the time.

From this perspective, what Sigil truly aims to solve isn't "how to make Agents do fewer things."

Quite the opposite.

It's trying to solve how to let Agents confidently do more, without stripping away the user's ultimate control (Further reading: From Blindly Clicking "Yes" to Seeing Clearly Before Signing: How Does Sigil Add a Safety Barrier for AI Agents?).

3. From Managing Assets to Managing Agents

If we zoom out one step further, we'll see that this is actually a role change wallets are facing.

Since the birth of Ethereum, the imToken wallet has experienced and witnessed two key generations: evolving from the 1.0 era of managing a single private key, to the 2.0 era of optimizing the interaction experience through Account Abstraction (AA).

With the proliferation of autonomous Agents like OpenClaw 2.0, wallets are undoubtedly entering a third generation of evolution, needing to further help users manage Agents that can autonomously make judgments and work continuously.

This is why the capabilities the wallet industry has accumulated—private key management, digital signatures, identity authentication, and permission isolation—may gain new significance in the Agent era.

Because these technologies, on the surface, solve "how to securely sign an on-chain transaction," but underneath, they deal with a much more universal problem: how to prove that an action genuinely received authentic authorization from a specific entity.

Today, that action could be transferring 1 ETH. In the future, it could also be sending an email, modifying a file, using a digital identity, purchasing a service, or allowing an Agent to continuously execute an automation strategy for the next week.

These actions may not all happen on the blockchain, but the underlying relationship is very similar: the Agent is invoking a user's capability in the user's name.

Therefore, Sigil's significance may not be limited to Crypto.

When OpenClaw, Hermes, and more Agents running on personal devices or cloud environments gradually connect to email, instant messaging, calendars, files, browsers, terminals, and payment tools, "how to prove that this action was indeed authorized by the user" will become an increasingly common problem.

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

Overall, 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 stage where autonomous Agents begin entering real execution environments.

It doesn't replace Agents, nor does it replace wallets.

It stands between the two.