OpenClaw 2.0 and Sigil: Building Verifiable Authorization for Autonomous AI Agents

After a period of inactivity, "Lobster" OpenClaw 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 combined, touching nearly the entire product stack—including installation, messaging, memory, Skills, models, Automations, browser, native apps, Plugins, and security mechanisms.

But more noteworthy than this extensive list of features is the increasingly clear evolution path behind OpenClaw 2.0: Agents are becoming truly capable of "taking action."

At the same time, it has led the industry into an unavoidable trust dilemma: as Agents become increasingly capable of autonomously deciding "how" to act, how can we ensure that each of their critical actions stays within the boundaries of what users have truly authorized?

Over the past year, the most noticeable change in AI agents has not been just that the underlying models have become smarter.

As infrastructure such as MCP, Skills, Plugins, browser control, and code execution becomes increasingly mature, Agents are gaining more and more real-world "limbs" capable of directly influencing the external world—such as modifying information, clicking buttons, or directly controlling browsers via computer use (see further reading: Has the Agentic AI Tipping Point Arrived? How AI Learning to “Act on Its Own” Is Reshaping Web3’s Security Boundaries?).

But the issue also arises precisely here: under existing interaction paradigms, it's easy to fall into two extremes.

One approach is to grant full authority by directly handing over the private key or a long-term valid, highly privileged Session Key to the Agent, allowing it to autonomously decide and execute actions.

The automated experience of this model is certainly ideal, but the risks are also highly concentrated: if遭遇 prompt injection, malicious websites, or data pollution, or if the model itself develops misinterpretations, errors may propagate along the entire execution chain and ultimately become real actions (see further reading: Sign Is More Than a Signature: When an AI Agent Signs for You, Who Still Holds Control?).

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

The other approach grants no authority at all, popping up a signature confirmation window for every action and every sub-call; while security is improved, the value of automation is significantly reduced.

After all, when an Agent helps a user execute a complex DeFi strategy involving multiple steps, requiring the user to manually approve each one with their phone turns them from someone pressing buttons into nothing more than a human stamping machine for the Agent.

In other words, the intermediate flexibility is both the source of the Agent’s improved efficiency and a new source of risk.

From this perspective, the core issue is not whether to delegate authority to Agents, but whether the granularity of authorization and the verification mechanism can be dynamically adaptive, since traditional access control is binary (either allowed or denied), while the tasks faced by Agents are far more complex.

A $10 transaction is not the same as a $100,000 transaction; interacting with a protocol you’ve used long-term is different from suddenly authorizing an unfamiliar contract; completing a Swap explicitly requested by the user is not the same risk level as an Agent independently deciding to move assets across chains.

Therefore, the more autonomous an Agent is, the more its permissions cannot be just a simple on/off switch.

What is truly needed is a safety mechanism that allows it to move freely within boundaries and automatically stop when crossing them.

In fact, OpenClaw has not overlooked this issue.

It currently offers a multi-layered permission system, such as plugins being able to pause and require user confirmation before executing specific actions, and for host commands, additional features like independent Exec Approvals and Allowlists are available.

This is a significant step forward compared to giving the Agent all tools and permissions at once. However, when the Agent truly enters scenarios involving payments, trading, and asset management, a more nuanced issue arises: allowing the Agent to use a certain capability is not the same as authorizing it to perform a specific action.

Just as allowing an Agent to use a browser does not mean it can purchase anything on any website; allowing an Agent to access your email does not mean it can send emails on your behalf to anyone; similarly, allowing an Agent to access your wallet should never mean it can send any amount to any address.

Therefore, the permission system in the Agent era may need to distinguish between two different issues. One is capability permission—whether the Agent is allowed to use a browser, terminal, email, or wallet. The other is more specific action authorization—whether the action it is about to perform at this moment is truly permitted by the user.

How can we enable the Agent to operate with full automation within clearly defined boundaries, while returning decision-making authority to the user when those boundaries are truly crossed?

This is also why imToken is exploring Sigil. Its core is not to add another traditional "confirmation popup" for Agents, but rather to establish a clearly bounded security guardrail between users and Agents through verifiable signatures and granular permission controls.

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

In simple terms, users can pre-authorize an Agent with a defined range of permissions to automatically carry out low-risk actions that align with established policies; when an operation reaches financial limits, involves unfamiliar protocols, or crosses other critical permission boundaries, execution is paused and the specific request is returned to the user for confirmation.

More importantly, this confirmation should not be just a vague statement like "Agent is ready to execute the transaction, do you agree?" Users need to see the actual key parameters that will change in this operation: which assets are being used, the amount involved, who the counterparty is, and exactly what action will be executed.

A confirmation is only truly meaningful when what the user sees, what the user authorizes, and what the system ultimately executes are all aligned.

Sigil also attempts to use mechanisms such as Passkeys, biometrics, single-signature, short expiration times, and request parameter binding to ensure that critical authorizations are not only understandable to users but also 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 the action that was ultimately executed was indeed the one seen at the time.

From this perspective, what Sigil is truly trying to solve is not "how to make agents do less."

On the contrary.

It aims to address how an Agent can be trusted to do more without taking ultimate control away from the user (further reading: From Blindly Clicking 'Yes' to Understanding Before Signing: How Sigil Adds a Safety Guardrail for AI Agents?).

If we step back even further, we can see that this is also a shift in the role that wallets are undergoing.

Since Ethereum's inception, imToken wallet has experienced and witnessed two key generations: the transition from the 1.0 era of managing single private keys to the 2.0 era optimized for interaction through account abstraction (AA).

With the adoption of autonomous agents like OpenClaw 2.0, wallets are undoubtedly entering their third generation and require further assistance in helping users manage individual agents that can make autonomous decisions and operate continuously.

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

Although these technologies appear to address the question of “how to securely sign an on-chain transaction,” they are fundamentally tackling a more general issue: how to prove that an action has been genuinely authorized by a specific party.

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

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

Therefore, the significance of Sigil is not necessarily limited to Crypto.

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, the question of “how to prove that this action was truly authorized by the user” will become increasingly common.

Therefore, Sigil may also expand in the future to include data access, identity usage, file modifications, content publishing, service purchases, and automated tasks.

Overall, as a joint exploration by imToken and OpenClaw, Sigil aims to bring imToken’s decade of experience in self-custody, wallets, and digital signatures into the new phase where autonomous agents are beginning to operate in real-world environments.

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

It stands between the two.