Author: Lacie Zhang, Bitget Wallet Researcher
In 1984, Apple (Macintosh) killed the command line with a mouse. In 2026, Agent is killing the mouse.
This is not a metaphor. Companies like Google, Amazon, NVIDIA, Visa, Microsoft, and Alibaba, which have spent billions of dollars refining graphical interfaces, are actively bypassing the GUI, turning to CLI, API, and Agent-native interfaces. The logic is simple: growth from 0 to 1 relies on people, but the next tenfold user base will no longer look at screens.
But what everyone is avoiding is: when the user of the software becomes an Agent, do humans still need to be present?
As early as 1950, Norbert Wiener, the founder of cybernetics, issued a warning: once humans lose the ability to observe and intervene, the feedback loop breaks, and the system goes out of control. The "Harness Engineering" emphasized by OpenAI today is essentially a continuation of this idea.
More than seventy years later, Agentic Wallet faces the encrypted version of this problem. Confirmation pop-ups, signature requests, approval processes, mnemonic backups, multi-factor authentication... The security mechanisms that crypto wallets have spent a decade building all answer one question: "Is this operation really authorized by you?" Agents are making this set of human interaction mechanisms begin to fail: continuing to require manual confirmation for each transaction prevents Agents from achieving continuous, real-time, automated execution; directly giving unlimited private key control to an Agent poses unacceptable risks for humans.
The answer is not at either extreme. Full autonomy is the sexiest narrative of the Agent era, but Wiener's warning still holds. We believe that Agentic Wallet must serve two types of entities simultaneously: on one hand, providing humans with rule-setting, risk control, and governance intervention capabilities; on the other hand, providing Agents with constrained execution permissions, enabling them to autonomously complete on-chain operations within clear boundaries. In other words, wallets need to evolve from asset containers and signing tools for human use into a permission and execution system that allows humans to set boundaries and lets Agents act within those boundaries.
What should this system look like? This is precisely the question this article aims to answer.
I. Beyond the Fat Wallet, Another Wallet War
Delphi Digital's Fat Wallet Thesis once proposed a powerful judgment: as the protocol and application layers become increasingly homogeneous, value will settle at the wallet layer because wallets are closest to users, control distribution channels and order flow, and users will also stay in a particular wallet long-term due to familiar interfaces, accumulated assets, and migration friction.
But Agents do not follow the same logic. As "ruthless" machine executors, Agents will not stay in a particular wallet due to familiar interfaces, brand preferences, or usage habits like humans do. They will continuously seek the infrastructure combination with the lowest cost, smallest delay, and most stable execution. As standards like ERC-8004 gradually become popular, the identity and reputation layer of Agents are also expected to migrate between different systems, meaning the lock-in effect wallets have on Agents is inherently weaker than on humans.
However, this does not mean the value of wallets disappears; rather, the location where value settles will change. In simple personal use cases, Agents will weaken the moat originally formed by wallets based on interface, habit, and entry points; in relatively complex organizational deployment scenarios, once an entire "Agent fleet" is configured with policy rules, approval processes, risk control parameters, and audit systems, the migration cost no longer comes from the front-end experience but from the rebuilding of the entire set of permissions, governance, and operational configurations.
Therefore, Agentic Wallet answers a different proposition beyond the Fat Wallet: Fat Wallet competes for the user entry point, while Agentic Wallet competes for the control when software begins to directly control funds.
If we review the evolution of wallets, we find that each change in product form essentially corresponds to a change in the object of user trust:
- Mnemonic wallets require users to trust themselves.
- Smart contract wallets require users to trust code.
- Embedded wallets require users to trust the service provider.
- And with Agentic Wallet, users need to trust a control system composed of permissions, policies, and governance mechanisms.
The goal of this system is not to let software take over funds, but to let software act under limited authorization while allowing humans to always retain ultimate control. Precisely because of this, the core of Agentic Wallet is not just "making wallets usable for Agents," but "enabling Agents to manage funds belonging to human users under conditions that are constrainable, auditable, and intervenable."
II. The Boundary of Wallets, The Starting Point of Agents
Existing wallets still work well in the scenarios they were originally designed for, but the problem is that more and more use cases driven by Agents are exceeding the design boundaries of existing wallets.
Scenario 1: Trading Agents need to act quickly, but "having the ability to execute" does not equal "being permitted to execute"
An investment portfolio Agent monitors cross-chain liquidity 24/7. When an opportunity arises, it needs to complete the transaction within seconds. The control logic of traditional wallets is: user opens the app - checks the transaction - clicks confirm. By the time this process is completed, the opportunity window has often already closed.
Technically, Agents already have the ability to call swap functions, generate calldata, and bridge funds. The problem is that capability does not equal permission. Just because an Agent can initiate a transaction does not mean it should be allowed to freely dispose of funds.
The role of Agentic Wallet is precisely to separate the two: Agents can act instantly, but only within preset rules, such as being limited to approved assets, subject to daily budget limits, constrained by slippage boundaries, and automatically pausing when market conditions are abnormal. Skill defines what an Agent "can do," while the wallet is responsible for constraining what an Agent "is allowed to do."
Scenario 2: Payment Agents need to spend money, but should not have full control of all funds
A payment Agent is responsible for automatically settling API bills, SaaS subscription fees, and supplier payments. In the current wallet system, it usually only has two choices: either wait for manual approval for each payment, or directly hold a private key with unlimited signing rights. The former does not scale, the latter is too risky.
Agentic Wallet provides a form of restricted authorization: it can only pay to whitelisted merchants, only use specified assets, only execute payments within a daily budget, and all expenditures are fully recorded.
Scenario 3: Multiple Agents need isolated permissions under a shared budget
An entity may run multiple Agents simultaneously: one responsible for trading, one for payments, one for review. Current wallets can certainly create multiple sub-accounts, but performing unified permission orchestration for these accounts, setting global budget caps, enforcing cross-Agent policy constraints, and forming a unified audit trail are not native capabilities of existing wallets.
Under the Agentic Wallet model, this would be treated as a priority design issue: each Agent has its own independent, clearly scoped permissions; at the same time, a unified policy layer is responsible for controlling overall risk exposure, cross-Agent frequency limits and shared budgets, and generating consistent audit records.
These scenarios point to the same conclusion: private key management remains the foundation of wallet security. Letting Agents directly access private keys is an unacceptable source of risk in any scenario. But merely managing private keys is no longer enough. When the operator changes from human to Agent, the wallet must also answer a second question: who is allowed to act, under what conditions, with what amount, on which assets, and towards which targets. Private key management is the first line of defense; permission boundary management for non-human operators is the second firewall added in the Agent era.
III. Bounded Autonomy: The Design Philosophy of Agentic Wallet
The industry's exploration of Agentic Wallet is still in its early stages, and there is no truly mature Agentic Wallet solution yet. However, as mentioned in the preface, this article believes that Agentic Wallet is a set of fund control systems that connects human governance and Agent execution: humans are responsible for setting boundaries, Agents are responsible for acting within the boundaries, and the wallet is responsible for ensuring that this constraint relationship is always executable, auditable, and intervenable.
Simultaneously, based on the degree of authorization granted to the Agent, Agentic Wallet might also serve the following 4 situations respectively:
- Human-Controlled: The Agent provides suggestions and assistance, each operation still requires human confirmation. Improves interaction efficiency, the fund control logic remains unchanged.
- Hybrid: The Agent handles routine operations, such as retrieval, quoting, reminders, or low-risk execution; human intervention frequency decreases, but edge cases still require human approval, such as involving fund transfers, contract calls, or abnormal branches.
- Bounded Autonomous: The Agent acts autonomously within clear rules, limits, and veto paths. Humans transition from per-transaction approvers to rule setters. The Agentic Wallet discussed in this article mainly points to this category.
- Fully Autonomous: The Agent possesses near-complete economic sovereignty and can independently schedule funds and bear the consequences without preset boundaries. This model is theoretically sound but remains far from mature in terms of security, governance, accountability, and compliance, currently largely停留在 the experimental stage.
For reference, Stripe's 2025 annual letter divided agentic commerce into five levels: L1 is form auto-filling (Eliminating web forms), L2 is descriptive search, L3 is persistence (memory), L4 is delegation, L5 is anticipatory purchase; while clearly judging that the industry as a whole is still "lingering on the edge of L1 and L2".
From this perspective, the biggest market demand currently comes from human-controlled and hybrid scenarios, while bounded autonomy is the real frontier today and the first production-ready form where Agents truly begin to manage funds.
Realizing this concept requires a four-layer architecture:
- Account Layer: Establish independent, isolated economic containers for each Agent, such as through EOA, smart contract accounts, server wallets, or TEE environments. The system needs to apply differentiated rules to different Agents.
- Permission Layer: Define the behavioral boundaries of the Agent, such as disposable额度, operable assets, interactable contracts, executable time windows, and action logic upon hitting boundaries. This is the core layer of the entire architecture.
- Execution Layer: Oriented towards Agent interfaces rather than human clicks. Sending, paying, swapping, bridging, rebalancing, liquidating, settling all need to be abstracted into primitives that can be called directly by programs.
- Governance Layer: Needs to provide logs, simulation, audit trails, alerts, pause switches, human veto rights, recovery mechanisms, etc. This layer determines whether Agentic Wallet can truly enter production environments.
Above the four-layer architecture, four core capabilities are needed to support system operation:
- Skills: Provide standardized on-chain operation modules. Agents can complete actions like trading, paying, bridging as if calling functions, without having to assemble underlying calldata themselves. Skill solves the ability abstraction problem of "what can be done".
- Policies + KYA / KYT: The Policies engine is responsible for performing rule checks on every operation, translating human-set boundaries into machine-executable constraints; the KYA / KYT mechanism is used to identify the source, identity, risk context, and operating history of the Agent. The former constrains behavior, the latter identifies the operator; together they ensure all fund actions remain within preset boundaries.
- Session Key: Provides a time-limited, amount-limited, scope-limited secure delegation mechanism. The Agent obtains temporary and limited authorization, not the full private key. Authorization expires automatically, no need for manual revocation, "enabling the Agent to obtain execution qualification without touching the full key".
- Audit & Notification: Provides fully traceable operation logs and a real-time alert system. Every operation is traceable, every anomaly is alertable, every Agent can be paused at any time.
Currently, we often control Agent behavior logic through instructions, but task orchestration is not equal to fund constraints. Agents can still misjudge, deviate, or suffer from attacks and malicious input pollution. The significance of the wallet layer is precisely to pre-solidify questions involving fund permissions—such as "whether funds can be moved, how much can be moved, which assets can be operated, which entities can be interacted with, and how to中止 in abnormal situations"—into system rules. Even if the Agent deviates, the actual fund actions that can occur are limited to the preset boundaries.
IV. Agentic Wallet Status: Four Paths and Four Gaps
Regarding existing Agentic Wallet solutions, we have observed 4 typical cases that have basically solved "how to let Agents into the fund system," but have not yet answered "how to let Agents use funds safely in cross-chain and complex real-world environments".
Coinbase, Safe, Privy, and Polygon have provided their respective feasible answers in infrastructure, governance, permissions, and identity layers. What remains unfinished is further integrating these partial capabilities into a unified control system that can operate cross-chain, migrate across environments, and hold up in complex adversarial scenarios. The common bottlenecks of Agentic Wallet at this stage mainly集中在 the following four gaps:
First, identity and reputation are not yet portable.
On-chain Agent identity and reputation systems can be established, but a credit system that is通用 across chains, wallets, and runtime environments still does not exist. The history and reputation accumulated by an Agent in one ecosystem cannot naturally migrate to another.
Second, the policy layer lacks unified standards.
Coinbase uses spending limits, Safe uses on-chain modules, Privy uses a policy engine, Polygon uses session-scoped wallets. The industry普遍 realizes the permission layer is core, but has not yet formed unified policy standards that are portable, composable, and reusable across products.
Third, adversarial security remains highly空白.
Prompt injection, tool poisoning, malicious Skills, polluted external inputs—these problems will not be automatically solved by traditional contract audits. The真正 new problem in the Agent era is: when the model's decision-making process is distorted by malicious input, how does the wallet identify, intervene, and阻断 risks.
Fourth, full-chain coverage is far from achieved.
Most existing solutions are attached to a single chain or a limited multi-chain scope, but Agent economic activities will not remain in a single ecosystem long-term. A truly mature Agentic Wallet must face the problems of multi-chain, multi-execution environments, and cross-domain permission consistency.
V. Beneath the Surface: The Next Decade of Agentic Wallet
Currently, the design focus of Agentic Wallet is empowering humans to exert fine-grained control over Agents. In most implementations, the wallet's role is closer to a passive signer: the Agent calls a Skill, the Skill generates a transaction, the wallet performs the signing in the backend, and on-chain execution follows.
But if Agents truly start managing funds, merely signing at the last step is clearly insufficient. A more reasonable approach is to have permission judgments occur before execution: after the Agent calls the Skill, the request first enters the wallet's internal Policy Plane, and execution is only permitted if it passes the policy check.
The so-called Wallet Policy Plane borrows from the idea of Control Plane and Data Plane in system architecture. It sits between Agent behavior and on-chain execution, integrating the engine, KYT/KYA checks, Session Key verification, risk scoring, and exception handling into a unified decision plane.
This思路 is not unfamiliar; Stripe's payment architecture follows similar logic: developers call a clean API, but before funds actually move, Stripe has already completed risk identification, rule checks, and compliance processing in the background. What Agentic Wallet needs to do is essentially the same: give developers a clean execution interface on the upper layer, and use a pre-execution policy engine to complete permission裁决 on the lower layer.
The urgency lies in the fact that the attack surface brought by prompt injection, tool poisoning, and malicious Skills is rapidly expanding, while the security infrastructure on the wallet side has not kept up. A standardized Wallet Policy Plane has not yet become a common industry primitive today.
However, the Policy Plane itself will not be the final state either. As Agent identity and reputation systems mature, authorization logic will shift from being driven by static rules to being driven by dynamic trust. Today, it relies on preset boundaries, amount limits, whitelists, and manual veto paths; in the future, on-chain transaction records, behavioral轨迹, and cross-ecosystem credit data will gradually form a verifiable Agent credit foundation, and more authorization decisions will be made based on identity, history, and actual performance.
When Agents begin economic interactions with each other at machine speed, control mechanisms must be built in from the very beginning of the system's establishment. The role of the wallet will also change accordingly: in the early stages, it is a gatekeeper, responsible for preventing out-of-bounds behavior; in the mature stage, it is closer to infrastructure, responsible for enabling trusted entities to connect accounts, permissions, and settlement systems with lower friction continuously.
In the past decade, the battlefield for wallets was that entry point on the screen. In the next decade, the battlefield is in that layer of control unseen by the user.
