After a quiet stretch, OpenClaw released version 2.0 on Aug. 30.
According to the official description cited in the article, the update is the largest in OpenClaw’s history, with more than 16,000 pull requests touching almost the entire product stack, including installation, messaging, memory, Skills, models, Automations, browser functions, native apps, Plugins, and security mechanisms.
What stands out is not only the size of that feature list, but the direction behind it. OpenClaw 2.0 makes a broader trend easier to see: agents are getting closer to actually doing things on a user’s behalf.
That progress brings a trust problem with it. As agents become more capable of deciding how to complete a task, the question is no longer abstract: how can users be sure that each critical action stays within the boundary they actually approved?
The autonomy dilemma: full delegation or endless confirmations
Over the past year, the clearest shift in AI agents has not been limited to smarter base models. With infrastructure such as MCP, Skills, Plugins, browser control, and code execution maturing, agents now have more ways to affect outside systems. They can edit information, click buttons, or directly control a browser through computer use.
That is also where the problem starts. Under current interaction models, teams and users tend to end up at one of two extremes.
One option is full delegation: hand a private key, or a long-lived Session Key with broad permissions, to the agent and let it decide what to execute. The automation experience is strong, but the risk becomes concentrated. If prompt injection, a malicious webpage, environmental contamination, or simple model misunderstanding enters the flow, an error can travel through the entire execution chain and become a real action.
In a standard internet setting, that might mean a wrong email or a deleted file. Onchain, a mistaken transaction is often irreversible.
The other option is to avoid delegation altogether. Every operation and every sub-call triggers a signature window and asks the user to confirm. Security improves, but the value of automation drops sharply.
If an agent is helping a user carry out a multi-step DeFi strategy and every stage requires the user to pick up a phone and tap Approve, the user is no longer spared the work. The role simply changes from clicking buttons directly to acting as a manual stamp checker for the agent.
Put differently, the room an agent has to act is both the source of efficiency and the source of new risk. The core issue is not whether authority should be delegated, but whether authorization granularity and verification can adapt to context. Traditional permission management is binary, allow or deny. Agent tasks are not.
A $10 transaction is not the same as a $100,000 one. Interacting with a protocol a user has used for a long time is not the same as approving an unfamiliar contract. Executing a swap the user explicitly requested is not the same as an agent independently deciding to bridge assets to another chain.
The more autonomous an agent becomes, the less useful a simple on-off switch for permissions is. What is needed is a security mechanism that lets the agent move freely inside the boundary and stop automatically once it reaches beyond it.
Beyond OpenClaw, the discussion is moving toward verifiable authorization
The article notes that OpenClaw has not ignored the issue. It already offers layered permission controls. Plugins can pause before a specific action is carried out and request user confirmation, and host commands have separate Exec Approvals and an Allowlist.
That is a meaningful step beyond handing all tools and permissions to an agent at once. Still, once agents move into payments, trading, and asset management, a more precise distinction becomes necessary: allowing an agent to use a capability is not the same as authorizing a specific action.
Giving an agent browser access does not mean it should be free to buy anything on any website. Letting it access email does not mean it should be able to send messages to anyone in a user’s name. In the same way, giving an agent wallet access should not mean it can send any amount to any address.
Under that view, a permission system for the agent era may need to separate two questions:
- Capability permission: can the agent use the browser, terminal, email account, or wallet?
- Action authorization: is the exact action the agent is about to take at this moment something the user actually allowed?
The hard part is preserving automation inside clearly defined limits while returning the decision to the user once the agent crosses those limits.
Sigil: turning “What you see is what you sign” into an execution rule
That is the context for imToken’s exploration of Sigil. As presented in the article, the point is not to add one more conventional confirmation pop-up for agents. The goal is to build a constrained safety rail between the user and the agent through verifiable signatures and fine-grained permission controls.
One central principle is "What you see is what you sign."
In practice, the user can grant an agent a predefined range of permissions in advance, allowing low-risk actions that match a stated strategy to be completed automatically. When an operation hits a threshold tied to asset size, an unfamiliar protocol, or another critical boundary, execution pauses and the specific request goes back to the user.
That confirmation, the article argues, should not be vague. A notice that says only "the agent is preparing to execute a transaction" is not enough. The user needs to see the parameters that matter: which asset is being used, how much is involved, who the counterparty or interaction target is, and what action the system is about to carry out.
Only when what the user sees, what the user authorizes, and what the system finally executes match each other does the approval mean something in a real sense.
Sigil is also described as exploring mechanisms such as Passkey, biometrics, one-time signatures, short validity periods, and request parameter binding. The aim is to make critical approvals understandable to users and verifiable by the system at the same time.
Under that model, an authorization is not just proof that someone tapped confirm. It can also answer who approved the request, what exactly was approved, and whether the final execution matched the action presented at approval time.
Seen from that angle, Sigil is not trying to reduce what an agent can do. The article makes the opposite case: the goal is to let agents do more, while preserving the user’s final control.
From managing assets to managing agents
Step back one level, and the piece frames this as a broader shift in the role of wallets.
Since Ethereum was created, the article says, imToken has lived through and witnessed two major phases: a 1.0 era focused on managing a single private key, then a 2.0 era in which account abstraction, or AA, improved the user experience.
With autonomous agents such as OpenClaw 2.0 spreading, wallets are now moving into a third stage, one where they may need to help users manage agents that keep working and making judgments over time.
That is why capabilities the wallet sector built up over the years, private key management, digital signatures, identity authentication, and permission isolation, may take on new meaning in the agent era. On the surface, these tools solve the problem of signing an onchain transaction safely. At a deeper level, they address a broader question: how do you prove that an action really received authentic authorization from a specific party?
Today, that action may be a transfer of 1 ETH. In the future, it could be sending an email, editing a file, using a digital identity, purchasing a service, or allowing an agent to keep executing an automated strategy over the next week.
Not all of those actions will happen onchain, but the underlying relationship is similar. The agent is using a capability that belongs to the user, in the user’s name.
That is why the article says the significance of Sigil may not stop at crypto.
As OpenClaw, Hermes, and more agents running on personal devices or in cloud environments connect to email, instant messaging, calendars, files, browsers, terminals, and payment tools, the question of how to prove that a specific action was actually authorized by the user is likely to become more common.
In that setting, Sigil could extend from onchain transactions to data access, identity use, file modification, content publishing, service purchases, and automated tasks.
The article presents Sigil as a joint exploration by imToken and OpenClaw, one that tries to carry imToken’s decade of experience in self-custody, wallets, and digital signatures into a stage where autonomous agents are entering real execution environments.
It does not replace the agent, and it does not replace the wallet. It sits between the two.