After a relatively quiet period, OpenClaw released version 2.0 on August 30.
According to the project, this was the largest update in OpenClaw’s history, incorporating more than 16,000 pull requests and touching virtually every part of the product stack, including installation, messaging, memory, skills, models, automations, browser control, native apps, plugins, and security.
Yet beyond this extensive feature list, what matters more is the clearer direction behind OpenClaw 2.0: AI agents are becoming truly capable of taking action in the real world.
At the same time, this evolution is creating an unavoidable trust dilemma: as agents gain greater autonomy over how tasks are completed, how can we ensure that every critical action remains within the boundaries the user actually authorized?
1. The Autonomy Dilemma: Full Delegation or Approval at Every Step?
Over the past year, the most significant change in AI agents has not simply been that the underlying models have become more capable.
As infrastructure such as MCP, skills, plugins, browser control, and code execution has matured, agents have gained more ways to affect the external world. They can modify information, click buttons, and even control browsers directly through computer use. (Further reading: Has Agentic AI Reached an Inflection Point? When AI Learns to Act on Its Own, How Will It Redefine Web3’s Security Boundaries?)
But this is precisely where the problem begins. Under today’s interaction models, authorization often falls into one of two extremes.
The first is full delegation: handing an agent a private key or a long-lived session key with broad permissions and allowing it to decide what to execute.
This delivers the most seamless automation experience, but it also concentrates risk. A prompt-injection attack, malicious webpage, compromised environment, or simple misunderstanding by the model could propagate through the entire execution chain and ultimately result in real-world actions. (Further reading: A Signature Is More Than a Signature: When an AI Agent Signs for You, Who’s in Control?)
In a conventional internet application, the result might be an email sent to the wrong person or a file deleted by mistake. Onchain, however, an incorrect transaction is often irreversible.
The other extreme is refusing to delegate at all, requiring a confirmation or signature for every operation and every subtask. This may improve security, but it also undermines the value of automation.
If an agent is helping a user execute a complex DeFi strategy involving multiple steps, but the user must pick up their phone and manually approve each one, the user has merely gone from clicking every button themselves to serving as the agent’s human rubber stamp.
In other words, the freedom agents need to operate efficiently is also a new source of risk.
The real question is therefore not whether agents should be given authority, but whether authorization can be sufficiently granular and dynamically enforced. Traditional permission systems are largely binary: an action is either allowed or denied. The tasks handled by agents are far more nuanced.
A $10 transaction is not equivalent to a $100,000 transaction. Interacting with a protocol the user regularly uses is different from granting approval to an unfamiliar contract. Executing a swap explicitly requested by the user is also fundamentally different from an agent independently deciding to bridge assets to another network.
The more autonomous agents become, the less their permissions can resemble a simple on-or-off switch.
What is needed is a security mechanism that lets agents operate freely within clearly defined boundaries—and automatically stops them when they attempt to cross those boundaries.
2. How Do We Build a Verifiable Line of Defense for Autonomous Agents?
OpenClaw has not ignored this problem.
It currently provides multiple layers of permission controls. For example, plugins can pause before executing specific operations and request user approval, while host-level commands are governed by separate Exec Approvals and allowlists.
Compared with granting every tool and permission to an agent upfront, this is already an important step forward. But once agents enter payment, trading, and asset-management scenarios, a more precise distinction becomes necessary: allowing an agent to use a capability is not the same as authorizing it to perform a specific action.
Allowing an agent to use a browser does not mean permitting it to purchase anything from any website. Allowing it to access email does not mean authorizing it to send messages to anyone in the user’s name. Likewise, allowing an agent to access a wallet should never mean allowing it to send any amount to any address.
Permission systems for the agent era may therefore need to answer two separate questions.
The first concerns capability permissions: can the agent use the browser, terminal, email, or wallet?
The second concerns action authorization: is the specific action the agent is about to perform something the user actually authorized?
How, then, can agents remain fully automated within explicit boundaries while returning control to the user whenever those boundaries are crossed?
This is the problem imToken is exploring with Sigil. Its purpose is not simply to add another conventional confirmation pop-up. Instead, Sigil seeks to establish a clearly enforceable security boundary between users and agents through verifiable signatures and fine-grained permission controls.
One of its core principles is: “What you see is what you sign.”
In practice, users can grant agents a predefined scope of authority, allowing low-risk actions that comply with established policies to proceed automatically. When an operation reaches a spending limit, involves an unfamiliar protocol, or crosses another critical permission boundary, execution pauses and the specific request is presented back to the user for confirmation.
Crucially, the confirmation should not merely say, “The agent is about to execute a transaction. Do you approve?”
Users need to see the key parameters of the operation: which asset will be used, how much will be transferred, which address, contract, or service it will interact with, and what action will ultimately be executed.
A confirmation is meaningful only when what the user sees, what they authorize, and what the system ultimately executes all correspond to one another.
Sigil is also designed to use mechanisms such as passkeys, biometric authentication, single-use signatures, short validity periods, and cryptographic binding between signatures and request parameters. This makes critical authorization not only understandable to the user, but also verifiable by the system.
An authorization record can therefore establish more than the fact that someone clicked “Approve.” It can answer who approved the request, exactly what they approved, and whether the action ultimately executed matches what they saw.
From this perspective, Sigil is not intended to make agents do less.
Quite the opposite.
It is designed to let agents safely do more without taking away the user’s ultimate control. (Further reading: From Blind Approval to Verifiable Signing: How Sigil Adds a Guardrail for AI Agents)
3. From Managing Assets to Managing Agents
Taking a broader view, this also reflects a fundamental shift in the role of wallets.
Since Ethereum’s early years, imToken has witnessed—and evolved through—two major generations of wallets: the 1.0 era of managing individual private keys, followed by the 2.0 era, in which account abstraction improved the user experience.
As autonomous agents such as OpenClaw 2.0 become more widely adopted, wallets are entering a third generation. They will increasingly need to help users manage agents that can make decisions and operate continuously on their behalf.
This is why the capabilities the wallet industry has developed around private-key management, digital signatures, identity authentication, and permission isolation may take on new significance in the age of AI agents.
On the surface, these technologies address the question of how to securely sign an onchain transaction. At a deeper level, however, they solve a much broader problem: how to prove that an action was genuinely authorized by a specific user or entity.
Today, that action might be transferring 1 ETH. In the future, it could be sending an email, modifying a file, using a digital identity, purchasing a service, or allowing an agent to execute an automated strategy continuously for a week.
Not all of these actions will necessarily happen onchain. But the underlying relationship is similar: an agent is invoking a capability that belongs to the user and acting in the user’s name.
Sigil’s potential significance may therefore extend beyond crypto.
As OpenClaw, Hermes, and other agents running on personal devices or in the cloud become connected to email, messaging, calendars, files, browsers, terminals, and payment tools, proving that a particular action was genuinely authorized by the user will become an increasingly universal requirement.
Sigil could eventually extend from onchain transactions to data access, identity use, file modification, content publishing, service purchases, and automated tasks.
As a joint exploration by imToken and OpenClaw, Sigil seeks to bring imToken’s decade of experience in self-custody, wallets, and digital signatures into this new stage, as autonomous agents begin operating in real execution environments.
It does not replace the agent.
Nor does it replace the wallet.
It stands between them.