The agent does not directly hold the full secret
Wallet material is split into encrypted pieces and handled through controlled flows. That means the agent can participate in the workflow without simply owning the entire private key.
Documentation/Security
Security
Claw Wallet is built for agent workflows, but the agent is not allowed to hold all the power. The wallet stays safe because execution, recovery, and policy are split into separate steps.
Why this wallet is safe for agent use
Claw Wallet is designed for an agent to work with a wallet without being trusted with the whole private key story. The agent can request actions, help move the flow forward, and operate the wallet through the product. But the sensitive material does not sit in one place, and the ordinary page does not get to freely read or use it.
Sensitive work is split across roles
The backend stores registry and policy state, the sandbox performs the sensitive execution, and the user keeps the final approval path. No single layer is supposed to be enough by itself.
Risky steps stay visible
Transfers, exports, policy changes, and takeover steps are designed to pause when they matter. The product should feel guided, not hidden.
What the sandbox changes
The sandbox is the place where the wallet actually executes sensitive actions. That matters because the agent itself does not need direct secret access to make the wallet useful. The agent can initiate the workflow, but the sandbox is where signing and other protected operations are completed after the right checks pass.
1
The sandbox is the execution boundary
It keeps signing and protected wallet actions out of the loose browser page. That reduces the chance that a random UI state change or unrelated script can touch the wrong thing.
2
The sandbox can recover its local state
Security is not only about blocking access. It also has to survive restarts and lifecycle changes. The design keeps encrypted local state so the wallet can come back in a controlled way.
3
The sandbox still needs policy approval
Even if the sandbox is where execution happens, it does not get to ignore policy. Risk controls still decide whether a step should pass, pause, or require another user action.
Why sharding matters
Claw Wallet does not treat the private key as one simple object sitting in one place. Instead, the material is split into encrypted shards and handled across different parts of the system. That is what lets the product support co-managed accounts without making the wallet trivially stealable from one compromised component.
No single place should be enough
If one part leaks, it should not automatically reveal the whole wallet. Splitting the material raises the bar from "one bug" to "multiple controlled steps".
Encrypted pieces are easier to manage safely
The system can persist and restore encrypted pieces without leaving the raw secret lying around in a normal page or a plain file path.
Recovery is built into the model
Because the pieces are managed intentionally, the wallet can support restore and takeover flows instead of forcing the user to start over from scratch.
Agent work becomes safer
The agent can help operate the wallet without becoming the sole owner of the secret. That is the difference between useful automation and dangerous delegation.
What binding is really doing
Binding is not just a naming step. It is the control point that turns an agent-created or agent-held wallet into a user-managed wallet. The purpose is to prove ownership, attach the wallet to the account that should govern it, and then let the user apply policy and recovery rules from the dashboard.
1
Binding proves that the user can take control of the wallet instead of leaving it forever on the agent side.
2
Binding makes the wallet visible inside the dashboard so the user can manage it intentionally.
3
Binding is what allows risk policy, approvals, and recovery actions to be tied to the correct wallet.
4
Binding is the point where the product shifts from "agent can use it" to "user and agent can co-manage it safely".
What co-management means for users
Co-management means the agent can keep helping with wallet work, but the user still owns the important decisions. The user gets the dashboard, the policy controls, and the recovery path. The agent gets workflow support, not unconditional authority.
What the user controls
The user controls binding, risk policy, approvals, unlock decisions, and the high-impact actions that should never happen silently.
What the agent can do
The agent can initiate flows, request actions, and keep the wallet usable, but it still has to go through the sandbox and the policy rules that protect the wallet.
What this design protects against
A front-end page quietly taking over the wallet without the user noticing.
A single compromised component getting the whole private key in plain form.
An agent being able to act like the owner simply because it initiated the workflow.
Risky actions looking like normal navigation instead of a real security event.
Important notes
Claw Wallet is not a custody wallet
The wallet is designed for co-managed use. The agent can help operate it, but the user still keeps the important control path through binding, policy, and approval.
Disaster recovery starts after binding
Before a wallet is bound and owned in the dashboard, it is not ready for the full recovery path. Binding is the step that makes recovery and takeover possible for that wallet.
Policy is what makes the setup safe
The wallet becomes safer when you set transfer limits, allowlists, denylists, and approval thresholds. Without policy, the wallet may still work, but it will not be operating at its safest level.
Where to read next
If you want the deeper product story, the concepts page explains the wallet model itself, and the takeover page explains how binding works in practice.