Decentralization or loss of control? In the era of autonomous Agents, what kind of "verifiable authorization" do we need?

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

According to the official statement, this is the largest update in OpenClaw's history, with over 16,000 cumulative Pull Requests, touching almost the entire product stack including installation, messaging, memory, Skills, models, Automations, browser, native apps, 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 truly 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 every critical operation they perform doesn't cross the boundaries of what users have genuinely authorized?

1. The Dilemma of Agent Autonomy: Full Delegation or Step-by-Step 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 impact the external world—such as modifying information, clicking buttons, or directly controlling browsers through computer use (read more: The Agentic AI Inflection Point Has Arrived? When AI Learns to "Act on Its Own," How Do We Rebuild Web3's Security Boundaries?).

But this is precisely where the problem lies. 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 Session Key with sufficient permissions, and letting it judge and execute on its own.

This mode certainly offers the best automation experience, but the risks are equally concentrated. Once a prompt injection, malicious webpage, or environment pollution occurs, or if the model itself has comprehension errors, mistakes can propagate along the entire execution chain, ultimately becoming real actions (read more: Sign Is Not Just Signing: When an AI Agent Signs for You, Who Still Holds Control?).

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

The other extreme is complete non-delegation, where every operation and every sub-call triggers a signature window requesting confirmation. Security improves, but the meaning of automation significantly diminishes as well.

After all, if an Agent helps a user complete a complex DeFi strategy involving multiple steps, and the user has to pick up their phone to "Approve" each one individually, the user essentially becomes a "human seal-stamping machine" for the Agent, rather than just "pressing buttons themselves."

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 about "whether to delegate authority to Agents," but whether the granularity of authorization and the verification mechanisms have dynamic flexibility, because traditional permission management is binary (either allow or deny), while the tasks Agents face are clearly far more complex.

The same type of transaction differs greatly: $10 versus $100,000; interacting with a long-used protocol versus suddenly authorizing an unfamiliar contract; executing a Swap the user explicitly requested versus the Agent autonomously deciding to bridge assets to another chain—these are not the same risk levels.

So, the more Agents can act autonomously, the more permissions cannot simply be an on-off switch.

What's truly needed is a security mechanism that allows Agents to act freely within boundaries but automatically stops when they cross them.

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

In fact, OpenClaw hasn't ignored this issue.

It currently offers multiple layers of permission mechanisms—for instance, plugins can pause before executing specific operations and request user confirmation, and when host commands are involved, there are also independent Exec Approvals and Allowlists.

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 granular question emerges: Allowing an Agent to use a capability is not the same as authorizing the Agent to complete a specific action.

Just as allowing an Agent to use a browser doesn't mean allowing it to purchase 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 never equal 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 permissions—can the Agent use the browser, terminal, email, or wallet? The other is more specific action authorization—at this moment, is the thing it's about to execute actually what the user truly allowed it to do?

So how do we let Agents fully automate within clear boundaries while returning decision-making power to users when they truly cross those boundaries?

This is also why imToken is exploring Sigil. Its core isn't to add another traditional "confirmation popup" for Agents, but rather to attempt to establish a clearly constrained safety guardrail between users and Agents through verifiable signatures and fine-grained permission controls.

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 actions that conform to established policies to complete automatically. When an operation touches fund amounts, unfamiliar protocols, or other critical permission boundaries, execution pauses and the specific request is returned 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: what 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 be aligned does a confirmation truly hold meaning.

Around this point, Sigil also attempts to use mechanisms such as Passkey, biometrics, one-time signatures, short validity periods, and request parameter binding, so that critical authorizations are 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 ultimately executed is truly the thing that was seen at the time.

From this perspective, what Sigil truly aims to solve is not "how to make Agents do fewer things."

Quite the opposite.

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

3. From Managing Assets to Managing Agents

If we pull the perspective back further, we'll find this is actually a role change that wallets are facing.

Since the birth of Ethereum, the imToken wallet has personally 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 interaction experiences 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 continuously work.

This is also why the private key management, digital signatures, identity authentication, and permission isolation capabilities that the wallet industry has accumulated in the past 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 actually address a more universal problem: how to prove that an action genuinely received authentic authorization from a certain entity.

Today, that action might 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 a certain automation strategy over the next week.

These actions don't necessarily all happen 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, Sigil's significance may not be limited to Crypto alone.

As 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 universal question.

Therefore, Sigil may also extend 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 phase where autonomous Agents begin entering real execution environments.

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

It stands between the two.