People have their uses: Agentic Wallet and the next decade of wallets

Written by: 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 their graphical interfaces, are actively bypassing GUIs and turning to CLI, API, and native Agent interfaces. The logic is simple: growth from 0 to 1 relies on people, but the next tenfold user base will no longer be looking at a screen.

But what everyone is avoiding is: when the user of the software changes from a person to an agent, is it still necessary for the person to be present?

As early as 1950, Norbert Wiener, the founder of cybernetics, warned that once humans lose the ability to observe and intervene, feedback loops will break and systems will go 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 an encrypted version of this problem. Confirmation pop-ups, signature requests, approval processes, mnemonic phrase backups, multi-factor authentication... the security mechanisms that encrypted wallets have spent ten years building all answer one question: "Did you really authorize this operation?" Agents have made this human interaction mechanism fail: continuing to require manual confirmation for each transaction makes it impossible for agents to achieve continuous, real-time, and automated execution; directly handing over boundless control of private keys to agents would expose humans to unacceptable risks.

The answer isn't at either of the two extremes. Complete autonomy is the most appealing narrative of the Agent era, but Wiener's warnings still hold true. We believe that Agentic Wallets must serve two types of entities simultaneously: on the one hand, providing humans with the ability to set rules, control risks, and intervene in governance; on the other hand, providing agents with constrained execution permissions, enabling them to autonomously complete on-chain operations within clearly defined boundaries. In other words, wallets need to evolve from asset containers and signature tools used by humans into a permission and execution system where humans set boundaries and agents act within those boundaries.

What should this system look like? That's the question this article will answer.

I. Beyond Fat Wallet, another wallet war

In their article "Fat Wallet Thesis, " Delphi Digital made a compelling assertion: as protocols and application layers become increasingly homogenized, value will accumulate at the wallet layer. This is because wallets are closest to users, controlling distribution channels and order flows. Users, due to familiar interfaces, accumulated assets, and migration friction, will tend to remain in a particular wallet for an extended period.

However, agents do not follow the same logic. As "ruthless" machine executors, agents do not stay in a particular wallet like humans do, based on interface familiarity, brand preference, or usage habits. Instead, they continuously seek the infrastructure combination with the lowest cost, least latency, and most stable execution. With the gradual popularization of standards such as ERC-8004, the identity and reputation layers of agents are expected to migrate between different systems. This means that the locking effect of a wallet on an agent is naturally weaker than its locking effect on a person.

However, this does not mean that the value of wallets disappears, but rather that the location where the value is stored will change. In simple personal use cases, agents will weaken the original moat formed by the wallet based on the interface, habits, and entry points; while in relatively complex organizational deployment scenarios, once an enterprise has configured policy rules, approval processes, risk control parameters, and auditing systems around the entire "Agent fleet," the migration cost will no longer come from the front-end experience, but from the reconstruction of the entire set of permissions, governance, and operation and maintenance configurations.

Therefore, Agentic Wallet answers a different question than Fat Wallet: Fat Wallet competes for user access, while Agentic Wallet competes for control when the software begins to directly manage funds.

Looking back at the evolution of wallets, we can see that each change in product form essentially corresponds to a change in the object of user trust:

• A mnemonic phrase wallet requires users to trust itself.

• Smart contract wallets require users to trust the code.

• Embedded wallets require users to trust the service provider.

• With Agentic Wallet, users need to trust a control system comprised of permissions, policies, and governance mechanisms.

The goal of this system is not to allow software to take over funds, but to allow software to act with limited authorization, while ensuring that humans retain ultimate control. Therefore, the core of Agentic Wallet is not just "enabling agents to use wallets," but "allowing agents to manage funds belonging to human users under conditions that are constrained, auditable, and subject to intervention."

II. The Boundaries of the Wallet, the Starting Point of the Agent

Existing wallets still function well in the scenarios they were originally designed for, but the problem is that more and more agent-driven use cases are exceeding the design boundaries of existing wallets.

Scenario 1: The transaction agent needs to act quickly, but "having the ability to execute" does not equate to "being permitted to execute."

A portfolio agent monitors cross-chain liquidity around the clock. When an opportunity arises, it needs to complete the transaction within seconds. The control logic of traditional wallets is that the user opens the application, checks the transaction, and clicks to confirm. By the time this process is completed, the opportunity window has often closed.

Technically, agents already possess the ability to invoke swap functions, generate call data, and bridge funds. The problem is that capability does not equate to authority. An agent's ability to initiate transactions does not mean it should be allowed to freely dispose of funds.

The purpose of an Agentic Wallet is to separate the two: an Agent can act instantly, but only within preset rules, such as being limited to approved assets, subject to daily budget constraints, and subject to slippage limits, and automatically pausing when market conditions are abnormal. Skills define 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 over the funds.

A payment agent is responsible for automatically settling API bills, SaaS subscription fees, and vendor payments. In the current wallet system, it typically has only two options: either wait for manual approval for every payment, or directly hold a private key with unlimited signing rights. The former is scalable, and the latter is too risky.

Agentic Wallet offers a restricted license: it can only pay whitelisted merchants, can only use specified assets, can only execute payments within a daily budget, and all expenditures are fully logged.

Scenario 3: Multiple agents need to have isolated permissions under a shared budget.

An entity may run multiple agents simultaneously: one for transactions, one for payments, and one for review. While current wallets can certainly create multiple sub-accounts, unified permission orchestration for these accounts, setting global budget caps, enforcing cross-agent policy constraints, and forming a unified audit chain are not native capabilities of existing wallets.

In the Agentic Wallet model, this is treated as a priority design issue: each agent has its own independent and clearly defined permissions; at the same time, a unified policy layer is responsible for controlling overall risk exposure, frequency limits and shared budgets across agents, and generating consistent audit logs.

These scenarios all point to the same conclusion: private key management remains the foundation of wallet security. Allowing agents direct access to private keys is an unacceptable source of risk in any scenario. However, simply managing private keys is no longer sufficient. When the operator changes from a human to an agent, the wallet must also answer a second question: who is allowed to act, under what conditions, at what limits, on which assets, and towards which objects? Private key management is the first line of defense, while the management of the permission boundaries of non-human operators is the second firewall added in the agent era.

III. Bounded Autonomy: The Design Philosophy of Agentic Wallet

The industry is still in the early stages of exploring Agentic Wallets, and there are no truly mature Agentic Wallet solutions yet. However, as mentioned in the introduction, this article views Agentic Wallets as a fund control system that connects human governance with agent execution: humans are responsible for setting boundaries, agents are responsible for actions within those boundaries, and the wallet is responsible for ensuring that this set of constraints is always enforceable, auditable, and operable.

Depending on the level of authorization obtained by the agent, Agentic Wallet may also serve the following four scenarios:

• Human-controlled: The agent provides suggestions and assistance, but each operation still requires human confirmation. The improvement lies in the efficiency of interaction; the logic of fund control remains unchanged.

• Hybrid: Agents handle routine operations such as retrieval, quoting, alerts, or low-risk execution; human intervention is less frequent, but boundary situations still require human approval, such as fund transfers, contract calls, or abnormal branches.

• Bounded autonomy: Agents act autonomously within clearly defined rules, limits, and veto paths. Humans shift from approving each transaction to setting the rules. The Agentic Wallets discussed in this article primarily refer to this type.

• Fully autonomous: Agents possess near-complete economic sovereignty, capable of independently allocating funds and bearing the consequences without pre-defined boundaries. While this model is theoretically sound, it remains far from mature in terms of security, governance, accountability, and compliance, and is currently largely in the experimental stage.

As a reference, Stripe divided aggression into five levels in its 2025 annual letter: L1 Eliminating web forms, L2 Descriptive search, L3 Persistence, L4 Delegation, and L5 Anticipation; it also clearly stated that the industry as a whole is still "on the edge between L1 and L2".

From this perspective, the greatest market demand may currently come from human-controlled and hybrid scenarios, while bounded autonomy is the real cutting edge and the first production-level form in which agents truly begin to manage funds.

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.

• Permissions Layer: Defines the behavioral boundaries of the Agent, such as the amount of money that can be spent, the assets that can be manipulated, the contracts that can be interacted with, the execution time window, and the action logic after the boundary is reached. This is the core layer of the entire architecture.

• Execution layer: Interfaces are agent-oriented, not human-click-oriented. Sending, payment, swapping, bridging, rebalancing, clearing, and settlement all need to be abstracted into primitives that can be directly invoked by the program.

• Governance layer: This layer needs to provide logging, simulation, audit trails, alerts, pause/on/off functionality, human veto power, recovery mechanisms, etc. This layer determines whether Agentic Wallet can truly be deployed to the production environment.

Above the four-layer architecture, four core capabilities are also needed to support the system's operation:

• Skills: Provides standardized on-chain operation modules. Agents can perform actions such as transactions, payments, and bridging as if calling functions, without having to assemble the underlying calldata themselves. Skills solve the problem of abstracting the capabilities of "what can be done".

• Policies + KYA / KYT: The Policies engine is responsible for validating rules for each operation, transforming human-defined boundaries into machine-executable constraints; the KYA / KYT mechanism is used to identify the agent's origin, identity, risk context, and operational history. The former constrains behavior, while the latter identifies the operator; together, they ensure that all financial transactions remain within preset boundaries.

• Session Key: Provides a time-limited, limit-based, and scope-limited secure delegation mechanism. The agent receives temporary and limited authorization, not the full private key. The authorization expires automatically without manual revocation, "allowing the agent to gain execution privileges without access to the full key."

• Auditing and Notification: Provides fully traceable operation logs and a real-time alert system. Every operation is traceable, every anomaly can trigger an alert, and every agent can be paused at any time.

Currently, we typically control the behavior of agents through instructions, but task orchestration is not equivalent to fund constraints. Agents can still misjudge, deviate from their intended path, or be susceptible to attacks and malicious input contamination. The significance of the wallet layer lies in pre-establishing system rules for questions concerning fund permissions, such as "whether funds can be used, how much can be used, which assets can be manipulated, which objects can be interacted with, and how to terminate operations in abnormal situations." Even if the agent deviates, the actual fund actions that can occur are still limited within the preset boundaries.

IV. Current Status of Agentic Wallets: Four Paths and Four Gaps

Regarding the existing Agentic Wallet solutions, we have focused on four typical cases, which have basically solved the problem of "how to allow agents to enter the fund system", but have not yet answered the question of "how to allow agents to use funds securely in cross-chain and complex real-world environments".

Coinbase, Safe, Privy, and Polygon have each provided feasible solutions at the infrastructure, governance, permissions, and identity levels, respectively. What remains to be done is to further integrate these partial capabilities into a unified control system that can operate across chains, migrate across environments, and still function effectively in complex adversarial scenarios. Currently, the common bottlenecks of Agentic Wallets mainly focus on the following four gaps:

First, identity and credibility are not transferable.

While on-chain agent identity and reputation systems can be established, a universal credit system that is applicable across chains, wallets, and operating environments still does not exist. The history and reputation an agent accumulates in one ecosystem cannot be naturally transferred to another.

Second, there is a lack of unified standards at the strategy level.

Coinbase uses spending limits, Safe uses on-chain modules, Privy uses a policy engine, and Polygon uses a session-scoped wallet. The industry has generally recognized that the permission layer is core, but a unified strategy standard that is portable, composable, and reusable across products has not yet been formed.

Third, adversarial security remains largely undeveloped.

Prompt injection, tool poisoning, malicious skills, and contaminated external inputs are issues that traditional contract auditing cannot automatically address. The real challenge in the Agent era is how wallets can identify, intervene, and mitigate risks when the model's decision-making process is distorted by malicious input.

Fourth, full-chain coverage is far from being achieved.

Most existing solutions rely on a single blockchain or a limited multi-chain scope, but the economic activities of agents will not remain within a single ecosystem in the long run. A truly mature agentic wallet must address the challenges of multiple blockchains, multiple execution environments, and cross-domain permission consistency.

V. Beneath the Surface: The Next Decade for Agentic Wallets

Currently, the design focus of Agentic Wallets is to empower humans to exert fine-grained control over agents. In most implementations, the wallet's role is more like a passive signer: the agent invokes the Skill, the Skill generates the transaction, the wallet completes the signing on the backend, and on-chain execution follows.

However, if the agent actually begins managing funds, simply signing at the final step is clearly insufficient. A more reasonable approach is to have permission checks occur before execution: after the agent invokes the skill, the request first enters the wallet's internal Policy Plane; only after passing the policy verification will execution be permitted.

The so-called Wallet Policy Plane borrows the concepts from the Control Plane and Data Plane in system architecture. It sits between agent behavior and on-chain execution, integrating the Policy engine, KYT/KYA verification, Session Key verification, risk scoring, and anomaly handling into a unified decision plane.

This approach is not unfamiliar; Stripe's payment architecture follows a similar logic: developers call a concise API, but before funds actually move, Stripe has already completed risk identification, rule checks, and compliance processing in the background. Agentic Wallet essentially does the same thing: it provides developers with a clean execution interface at the upper layer, and uses a front-end policy engine at the lower layer to handle permission decisions.

The urgency lies in the fact that the attack surface, posed by prompt injections, tool poisoning, and malicious skills, is rapidly expanding, while the security infrastructure on the wallet side is far from keeping up. A standardized Wallet Policy Plane has not yet become a universally accepted primitive in the industry.

However, the Policy Plane itself will not be the final state. As the Agent identity and reputation system matures, the authorization logic will shift from static rule-driven to dynamic trust-driven. Today, it relies on preset boundaries, quota limits, whitelists, and manual veto paths; in the future, on-chain transaction records, behavioral patterns, 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 to engage in economic interactions at machine speed, control mechanisms must be built into the system from its inception. The role of the wallet will also change: in the early stages, it acts as a gatekeeper, preventing unauthorized actions; in the mature stage, it becomes closer to the infrastructure, enabling trusted entities to continuously connect accounts, permissions, and settlement systems with lower friction.

For the past decade, the battleground for wallets has been the entry point on the screen. In the next decade, the battleground will be the layer of control that users can't see.