In 1984, Apple (Macintosh) killed the command line with a mouse. In 2026, the 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 proactively bypassing GUI and turning to CLI, API, and Agent native interfaces. The logic is simple: human-dependent 0-1 growth, but the next tenfold user base won't be looking at screens anymore.

But what everyone is avoiding is: when software users transition from human to Agent, does the human still need to be present?

As early as 1950, cybernetics founder Wiener (Norbert Wiener) issued a warning: once humans lose the ability to observe and intervene, the feedback loop will break, and the system will spiral out of control. What OpenAI emphasizes today as "Harness Engineering" is fundamentally a continuation of this idea.

Over seventy years later, the Agentic Wallet is facing the encrypted version of this problem. Confirmation pop-ups, signing requests, approval processes, mnemonic phrase backups, multi-factor authentication... The security mechanisms built by the crypto wallet over the past decade all aim to answer one question: "Is this transaction really authorized by you?" The Agent is causing this human interaction mechanism to start to fail: continuing to require manual confirmation for each transaction, the Agent cannot achieve continuous, real-time, automated execution; directly giving the boundless private key control to the Agent would entail unacceptable risks for humans.

The answer is not in two extremes. Full autonomy is the most seductive narrative of the Agent era, but Wiener's warning still holds true.

We believe that the Agentic Wallet must simultaneously serve two types of entities: on one hand, providing rule-setting, risk control, and governance intervention capabilities for humans; on the other hand, providing constrained execution permissions for the Agent, allowing it to autonomously perform on-chain operations within clear boundaries. In other words, the wallet needs to evolve from an asset container and signing tool used by humans into a system that allows humans to set boundaries and enables Agents to act within those boundaries.

What Should This System Look Like? That is precisely the question this article aims to answer.

1. Beyond the Fat Wallet, Another Wallet War

Delphi Digital once made a powerful statement in the Fat Wallet Thesis: As protocols and the application layer become increasingly homogenized, value will settle into the wallet layer. Wallets are closest to the user, controlling the distribution channel and order flow. Users will remain in a wallet for the long term due to familiar interfaces, asset stickiness, and migration friction.

However, the Agent does not follow the same logic. As a "ruthless" machine executor, the Agent will not stay in a particular wallet like a human would due to interface familiarity, brand preference, or usage habits. It will continue to seek the infrastructure combination with the lowest cost, minimal latency, and most stable execution. As standards like ERC-8004 gradually become widespread, the Agent's identity and reputation layer also have the potential to migrate across different systems. This means that the wallet's locking effect on the Agent is inherently weaker than its locking effect on humans.

Nevertheless, this does not mean that the wallet's value disappears but rather that the position of value settlement will change. In a simple individual use case, the Agent will weaken the wallet's moat based on interface, habits, and entry points. In a relatively complex organizational deployment scenario, once an enterprise configures policy rules, approval processes, risk parameters, and audit systems around an entire "Agent fleet," migration costs will no longer stem from the frontend experience but from the reconstruction of the entire set of permission, governance, and operational configurations.

Therefore, the Agentic Wallet addresses another proposition beyond the Fat Wallet: While the Fat Wallet competes for user entry points, the Agentic Wallet competes for control when software directly governs funds.

Looking back at the evolution of wallets, one will find that each product form change fundamentally corresponds to a change in the user's trust object:

· Mnemonic Phrase Wallets require users to trust themselves.

· Smart Contract Wallets require users to trust the code.

· Embedded Wallets require users to trust the service provider.

And with the Agentic Wallet, what users need to trust is a control system composed of permissions, policies, and governance mechanisms.

The goal of this system is not to let the software take over funds, but to let the software act under limited authorization while allowing humans to retain ultimate control. It is for this reason that the core of the Agentic Wallet is not just to "enable Agents to use a wallet," but to "enable Agents to manage funds belonging to human users under conditions that are constrainable, auditable, and intervenable."

II. Wallet Boundaries, Agent's Starting Point

Existing wallets still operate well in their originally designed scenarios, but the issue is that more and more Agent-driven use cases are exceeding the current wallet's design boundaries.

Scenario 1: A transaction Agent needs to act swiftly, but "having the ability to execute" does not equal "being allowed to execute"

A portfolio Agent monitors cross-chain liquidity around the clock. When an opportunity arises, it needs to complete a transaction within seconds. The control logic of traditional wallets is for the user to open the app - check the transaction - click confirm. By the time this process is completed, the opportunity window has often closed.

Technically, the Agent already has the ability to call the swap function, generate calldata, and bridge funds. However, ability does not equal permission. An Agent being able to initiate a transaction does not mean it should be allowed to freely dispose of funds.

The role of the Agentic Wallet is to separate the two: The Agent can act instantly but only within preset rules, such as limited to approved assets, subject to daily budget constraints, constrained by slippage boundaries, and automatically paused in case of abnormal market conditions. The Skill defines what the Agent "can do," while the wallet is responsible for constraining what the Agent "is allowed to do."

Scenario 2: A payment Agent needs to spend money but should not have full control over all funds

A payment Agent is responsible for automatically settling API bills, SaaS subscription fees, and vendor payments. In the current wallet system, it usually only has two options: either wait for manual approval for each payment or hold a private key with unrestricted signing authority. The former is not scalable, and the latter is too risky.

The Agentic Wallet provides a restricted authorization: It can only make payments to whitelisted merchants, use specified assets, execute payments within the daily budget, and all expenditures are fully recorded.

Scenario 3: Multiple Agents Need Isolated Permissions Under a Shared Budget

One entity may run multiple Agents simultaneously: one for transactions, one for payments, one for reviews. The current wallet can certainly create multiple subaccounts, but it is not a native capability of the existing wallet to uniformly arrange permissions for these accounts, set a global budget cap, enforce cross-Agent policy constraints, and form a unified audit trail.

However, in the Agentic Wallet model, this would be treated as a priority design issue: each Agent has independent, clearly defined permissions; at the same time, a unified policy layer is responsible for controlling overall risk exposure, cross-Agent frequency limits and shared budget, and generating consistent audit records.

These scenarios point to the same conclusion: private key management is still the foundation of wallet security, allowing Agents direct access to private keys is an unacceptable risk in any scenario. But merely managing private keys is not enough.

When operators transition from humans to Agents, wallets must also address the second question: who is allowed to act under what conditions, to what extent, on which assets, towards which entities. Private key management is the first line of defense, and boundary management of non-human operator permissions is the second firewall added in the Agent era.

III. Bounded Autonomy: Agentic Wallet Design Philosophy

The industry is still in the early exploration stage of Agentic Wallets, and there is no mature Agentic Wallet solution yet. However, as mentioned in the preface, the Agentic Wallet envisioned in this article is a fund control system that connects human governance with Agent execution: humans are responsible for setting boundaries, Agents are responsible for actions within the boundaries, and the wallet is responsible for ensuring that this set of constraint relationships is always executable, auditable, and intervenable.

At the same time, depending on the level of authorization granted to Agents, an Agentic Wallet may also cater to the following 4 scenarios respectively:

Human-Controlled: Agent provides suggestions and assistance, with each operation still requiring human confirmation. The improvement lies in interaction efficiency, while the fund control logic remains unchanged.

Hybrid: The Agent handles routine operations such as retrieval, quoting, reminders, or low-risk execution; human intervention frequency is reduced, but edge cases still require human approval, such as touching fund transfers, contract calls, or abnormal branches.

Bounded Autonomy: The Agent acts autonomously within explicit rules, limits, and veto paths. Humans transition from per-transaction approvers to rule makers. The Agentic Wallet discussed in this article primarily refers to this type.

Full Autonomy: The Agent has near-complete economic sovereignty, able to autonomously schedule funds and take on outcomes without predefined boundaries. This model is theoretically sound, but is still immature in terms of security, governance, responsibility, and compliance, and is currently mostly in the experimental phase.

For reference, in its 2025 annual letter, Stripe categorized agentic commerce into five levels: L1 as Form Fill (Eliminating web forms), L2 as Descriptive Search, L3 as Persistence, L4 as Delegation, L5 as Anticipation; while unequivocally stating that the industry as a whole still "hovers at the edge of L1 and L2."

From this perspective, the current largest market demand may come from human-controlled and hybrid scenarios, with bounded autonomy being the true frontier and the first production-grade form in which Agents truly begin to manage funds.

Implementing this concept requires a four-layer architecture:

· Account Layer: Establishing independent, isolated economic containers for each Agent, such as through EOA, smart contract accounts, server wallets, or TEE environments. The system needs to enforce differentiated rules for different Agents.

· Permission Layer: Defining the boundaries of Agent behavior, such as disposable limits, operable assets, interactable contracts, executable time windows, and post-boundary action logic. This is the core layer of the entire architecture.

· Execution Layer: Geared towards Agent interfaces rather than human clicks. Sending, paying, swapping, bridging, rebalancing, clearing, and settling all need to be abstracted as primitives that can be directly invoked by programs.

· Governance Layer: Needs to provide logging, simulation, audit trail, alerts, pause switch, human override, recovery mechanism, and more. This layer determines whether the Agentic Wallet can truly go into production.

Above the Four-Layer Architecture, four core capabilities are also needed to support system operation:

Skills: Provides standardized on-chain operation modules. An Agent can perform transactions, payments, bridging, and other actions like calling functions without having to manually assemble the underlying calldata. Skills address the ability abstraction issue of "what can be done."

Policies + KYA / KYT: The Policies engine is responsible for rule validation for each operation, translating 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, the latter identifies the operator, ensuring all fund actions always remain within preset boundaries.

Session Key: Provides a time-limited, amount-limited, and scope-limited secure delegation mechanism. The Agent receives temporary and limited authorization, not a complete private key. The authorization expires automatically and invalidation does not require manual revocation, enabling the Agent to obtain execution eligibility without accessing the full key.

Audit and Notification: Provides a fully traceable operation log and real-time alert system. Each operation is traceable, each anomaly is alertable, and each Agent can be paused at any time.

Currently, we typically control Agent behavior logic through instructions, but task orchestration is not the same as fund constraint.

An Agent may still misjudge, deviate, or be subject to attacks and malicious input pollution. The significance of the Wallet Layer is to predefine system rules related to fund permissions such as "whether funds can be used, how much can be used, which assets can be operated, which entities can be interacted with, and how to abort in exceptional circumstances." Even if an Agent deviates, the actual fund actions that can occur are still confined within preset boundaries.

IV. Agentic Wallet Status: Four Paths and Four Gaps

Around the existing Agentic Wallet solutions, we have identified 4 typical cases that have essentially addressed "how to onboard an Agent into the financial system," but have not yet answered "how to enable an Agent to securely use funds across chains and in a complex real-world environment."

Coinbase, Safe, Privy, and Polygon have each provided their feasible answers at the infrastructure, governance, permission, and identity levels, respectively. What remains to be done is to further integrate these localized capabilities into a unified control system that can operate across chains, migrate across environments, and remain viable in complex adversarial scenarios. The current bottleneck of the Agentic Wallet mainly lies in the following four gaps:

First, identity and reputation are not yet portable.

An on-chain Agent identity and reputation system can be established, but a universal credit system that is interoperable across chains, wallets, and operational environments is still lacking. 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, and Polygon uses a session-scoped wallet. The industry has generally recognized that the permission layer is core, but a portable, composable, and cross-product reusable unified policy standard has not yet been established.

Third, adversarial security is still highly undeveloped.

Prompt injection, tool poisoning, malicious Skills, contaminated external inputs—these issues will not be automatically resolved by traditional contract audits. The truly new problem introduced in the Agent era is: when the decision-making process of a model is distorted by malicious inputs, how does the wallet identify, intervene, and block the risk.

Fourth, full-chain coverage is far from achieved.

Existing solutions mostly rely on a single chain or a limited multi-chain scope, but an Agent's economic activity will not remain within a single ecosystem for long. A truly mature Agentic Wallet must address the challenges of multi-chain, multi-execution environments, and cross-domain permission consistency.

Chapter Five: Beneath the Surface - Agentic Wallet in the Next Decade

Currently, the design focus of the Agentic Wallet is to empower humans to exert fine-grained control over an Agent. In most implementations, the wallet's role is closer to that of a passive signer: The Agent calls a Skill, the Skill generates a transaction, the wallet signs in the backend, and on-chain execution follows.

However, if the Agent truly begins to manage funds, merely signing at the final step is evidently insufficient. A more reasonable approach is to have permission checks occur before execution: after the Agent calls a Skill, the request enters the wallet's internal Policy Plane, where execution is only approved after passing through policy validation.

The so-called Wallet Policy Plane borrows from the Control Plane and Data Plane concept in system architecture. It sits between Agent behavior and on-chain execution, integrating Policy engines, KYT/KYA checks, Session Key validation, risk scoring, and exception handling into a unified decision surface.

This concept is not unfamiliar; Stripe's payment architecture follows a similar logic: developers interact with a simple API, but before funds actually move, Stripe has already completed risk identification, rule checks, and compliance processing in the background. The essence of what the Agentic Wallet must do is similar - provide developers with a clean execution interface at the top layer, while using a front-facing policy engine at the lower layer for permission adjudication.

The urgency lies in the rapidly expanding attack surface due to Prompt Injection, Tool Poisoning, and malicious Skills, while the security infrastructure on the wallet side has lagged far behind. A standardized Wallet Policy Plane has yet to become an industry-wide foundational primitive today.

However, the Policy Plane itself will not be the end state. As Agent identities and reputation systems mature gradually, authorization logic will transition from static rule-driven to dynamic trust-driven. Today relies on preset boundaries, limit constraints, whitelists, and manual override paths; in the future, on-chain transaction records, behavioral trajectories, and cross-ecosystem credit data will gradually form a verifiable Agent credit foundation, and more authorization decisions will be based on identity, history, and actual performance.

When Agents begin to interact economically at machine speed with other Agents, the control mechanism must be built into the system from the very beginning. The role of the wallet will also evolve: in the early stages, it is a gatekeeper, responsible for preventing unauthorized behavior; in the mature stage, it becomes closer to infrastructure, responsible for allowing trusted entities to continuously connect to accounts, permissions, and settlement systems with lower friction.

Over the past decade, the battleground of the wallet has been that entry point on the screen. In the next decade, the battleground will be in the layer of control invisible to the user.