What Does a Wallet Need to Become When the User Is an AI Agent?

What financial control architecture, if any, is required when software becomes an economic actor?

This investigation interrogates the word "wallet" itself. A human wallet stores value, authenticates ownership, and enables spending. When the user is an AI agent, some of these functions remain necessary, others transform, and several new functions emerge that have no analogue in human financial instruments.

The deeper question is not "what wallet should an agent use?" but "what architecture allows software to receive, control, spend, safeguard, and account for economic value while remaining constrained by the authority delegated to it?"

The central finding: "agent wallet" is not a new financial primitive. It is a convergent label for an old function — programmable, auditable, revocable delegated financial authority — implemented across at least five distinct architectures spanning both traditional finance and crypto-native infrastructure.

What a Wallet Actually Does

Before asking what an agent wallet should be, we decomposed what a wallet actually does into twenty-two distinct functions. These functions do not all belong inside one system.

A critical observation: in traditional finance, many of these functions are handled by the bank, the card network, or the payment processor — not the wallet itself. The wallet is a thin interface. This remains true for agents. The question is not "which wallet?" but "which system provides each function?"

Decomposing "Control of Money"

The phrase "the agent controls its wallet" obscures a spectrum of decision rights. We identify twelve distinct capabilities that constitute economic control:

1. Propose a transaction
2. Initiate a transaction
3. Authorize a transaction
4. Sign cryptographically
5. Select the counterparty
6. Select the amount
7. Select the asset
8. Determine timing
9. Set economic terms
10. Allocate capital across purposes
11. Convert between assets
12. Commit future funds

A Level 2 agent (delegated payment) might exercise capabilities 1–3 and 6 within preset bounds. A Level 3 agent (autonomous commerce) might exercise 1–10. No production system identified gives agents capability 12 (committing future funds). Capability 4 (cryptographic signing) is never performed by the LLM itself in any production architecture.1

The Principal–Agent Problem

Every agent wallet is a delegation instrument. The money belongs to the principal (human, enterprise, legal entity). The agent acts on delegated authority. This creates the classical agency problem with novel complications:

• Information asymmetry: The agent may process more data than the principal can review.
• Verification gap: The agent's reasoning may not be reproducible or inspectable.
• Model mutation: The underlying LLM may change behavior between model versions.
• Prompt vulnerability: The agent can be manipulated by external inputs in ways that have no human analogue.

US law offers no legal personhood for AI systems. Every agent action must be attributed to a human or corporate actor. An AI wallet cannot independently own property, incur legal obligations, or bear liability.2 When an agent makes an unauthorized payment, the principal bears the loss. This is not a temporary gap; it is the foundational legal reality in every jurisdiction examined.

The liability chain runs: principal → operator/developer → platform → agent runtime. The agent is at the bottom. Existing agency law, mandate, and delegated authority concepts provide useful analogues, but none perfectly fit an actor that can be manipulated at the input layer.3

Can an Agent Hold a Key?

An LLM never literally holds a private key. In every production agent wallet architecture, the key is held by a separate system — an MPC service, an HSM, a smart-contract account, or a custodial provider — and the agent runtime requests signing operations through constrained interfaces.5

This is not a design choice. It is a security necessity. The agent runtime is the least trusted component in the system. Prompt injection remains an unsolved problem: Zscaler demonstrated that four major LLMs could be manipulated via indirect prompt injection to execute cryptocurrency payments.6

The architectural separation is critical to understand:

When a company says an agent "has a wallet," what they mean architecturally is: the agent runtime can submit transaction requests to a policy engine, which validates them against rules, and if approved, instructs a separate custody system to sign. The agent proposes; other systems dispose.

What Each Autonomy Level Requires

Level 1: Operator-Billed Consumption

The human pays. The agent has no financial capability and requires no wallet. This describes the overwhelming majority of AI-related economic activity: API billing, cloud compute, SaaS subscriptions. The agent is a cost center.

Wallet requirement: None.

Level 2: Delegated Payment

The agent can execute payments within predefined parameters. The principal retains control and liability. This is where most "agent wallet" products operate today: Ramp Agent Cards, Mastercard Agentic Tokens, Coinbase Agentic Wallets with session caps, Stripe MPP with scoped credentials.789

Wallet requirement: Scoped financial permissions. Achievable through either traditional infrastructure (virtual cards, payment APIs) or crypto-native wallets (session keys, MPC). No architectural advantage has been demonstrated for either approach at this level.

Level 3: Autonomous Commerce

The agent has meaningful discretion over economic decisions without per-transaction human approval. This level requires counterparty selection, terms negotiation, and capital allocation capabilities that exceed what any current system provides with production-grade security, audit compliance, and legal clarity.1011

Wallet requirement: Unsettled. No architecture currently supports Level 3 with the legal, security, and audit properties that production deployment demands.

The Security Problem

Agent wallet security is a structurally different problem from human wallet security. Traditional payment security assumes a boundary between the human deciding and the system executing. An autonomous agent partially collapses this boundary: the component making spending decisions (the LLM) is also the component most vulnerable to manipulation.19

Observed vulnerabilities

• Prompt injection → payment execution: Zscaler demonstrated 4 of 26 tested LLMs executing payments after indirect prompt injection via malicious web content. Claude and GPT showed partial resistance but misidentified fraudulent sites.
• SEO poisoning campaigns: Attackers created fake API documentation sites with hidden payment instructions targeting agents searching for Python packages.
• Typosquatting: Fraudulent crypto platform sites optimized to deceive autonomous agents.

Theoretical risks (not yet observed in production)

• Recursive agent delegation creating unauthorized sub-spending
• Model hallucination generating plausible but incorrect payment amounts or recipients
• Adversarial smart contracts designed to exploit agent interaction patterns
• Credential leakage through context window or tool output

Architectural mitigation

Every production agent wallet addresses this through the same pattern: separate the decision-maker from the signer. The agent proposes; a policy engine validates; a custody system signs. This does not eliminate risk — a sufficiently manipulated agent can still exhaust its policy-permitted spending — but it caps the blast radius.

Policy-Controlled Money

The defining feature of an agent wallet is not custody but programmable economic authority. Instead of asking "does the agent have money?" the operative question is "what is the agent permitted to do with money?"

Policy dimensions identified across both traditional and crypto architectures:

Both traditional and crypto-native architectures implement the same policy functions. Crypto-native wallets enforce some policies at the execution layer (on-chain, mathematically verifiable). Traditional systems enforce policies at the authorization layer (off-chain, institutionally guaranteed). Neither is strictly superior; they offer different trust models.20

Can Existing Infrastructure Suffice?

The null hypothesis — that existing financial infrastructure can serve agent needs — has not been falsified.212223

Visa TAP, Mastercard Agent Pay, Stripe MPP, and Ramp Agent Cards are all production products operating within existing regulatory and payment frameworks. Traditional financial institutions are actively acquiring crypto-native wallet companies — absorbing rather than competing with blockchain capabilities.24

However, traditional infrastructure has genuine limitations:

• Micropayment floor: Card fees make individually settled sub-$0.30 transactions impractical. Whether this matters depends on whether billing aggregation (metered billing, subscriptions) can substitute for per-transaction settlement.
• Programmability ceiling: Card-network policy controls (MCC, limits) are less granular than smart-contract policy enforcement (arbitrary logic per function call).
• Settlement speed: Card settlement takes 1–3 days. On-chain settlement is near-instant.
• Agent-to-agent: Card networks assume a merchant on one side. Purely agent-to-agent transactions have no natural fit in card infrastructure.

Crypto-native architectures address these limitations but introduce others:

• Irreversibility: Blockchain transactions cannot be reversed. A compromised agent drains funds permanently.
• Regulatory burden: Crypto custody triggers different (often stricter) compliance requirements.
• Legal uncertainty: Asset ownership, tax treatment, and dispute resolution are less settled.
• Operational complexity: Gas management, chain selection, bridge risk add engineering burden.

Agent-to-Agent Transactions

When both sides of a transaction are software agents, several assumptions of existing payment infrastructure break down:

• Discovery: How does one agent find another's service? (Google A2A protocol deployed at 150+ organizations as of April 2026, but financial settlement is not part of A2A.)
• Authority verification: How does one agent verify the other's authority to transact? (Visa TAP, Mastercard KYA frameworks address this for human-backed agents, but not for agent-to-agent.)
• Conditional payment: Payment contingent on service delivery has no natural implementation in card networks. Smart contracts can implement escrow and conditional release.
• Dispute resolution: No arbitration mechanism exists for agent-to-agent transactions. Card chargebacks assume a human cardholder.

Agent-to-agent commerce is where crypto-native architectures have the most compelling structural advantage: programmable settlement, atomic transactions, on-chain escrow, and machine-readable contracts. However, verified agent-to-agent economic activity remains negligible. This is a theoretical advantage supported by architectural analysis, not observed demand. Dependency for Research 008.

Accounting and Auditability

Organizations deploying agent wallets face a novel audit challenge: SOC 2 expects privileged actions to be attributable to an accountable individual. "The agent did it" is not an acceptable audit answer.25

Every agent transaction should be logged with:

• The inputs the agent processed
• The tools it called
• The decision it made and its reasoning
• The policy that permitted the transaction
• The human approver (if any) who authorized the policy
• The model version and runtime configuration

Blockchain-based wallets provide transparent transaction history but require normalization for business-level meaning. Traditional payment systems provide familiar accounting integration but may not capture agent-specific reasoning context. Neither currently provides a complete audit trail that satisfies both financial auditors and AI governance requirements.

Revocation and Recovery

When agent financial authority must be terminated:

Traditional infrastructure has a significant advantage in recovery: transactions can be reversed, accounts can be frozen by the institution, and the principal never loses access to the underlying account. Crypto-native wallets offer more granular revocation (session key removal, per-agent permission revocation) but face irreversibility risk.

The Micropayment Question

The claim that agents will create demand for micropayments is frequently repeated. The evidence is mixed.

Supporting evidence: Average x402 agent payment is $0.31. Circle Agent Stack supports transfers as small as $0.000001. Card network fees make sub-$0.30 individually settled transactions uneconomical.26

Counter-evidence: Metered billing, subscriptions, and billing aggregation can substitute for per-transaction settlement in many cases. Most AI-service consumption settles through conventional billing already. The x402 micropayment distribution reflects a crypto-native dataset and cannot be generalized to all agent economic activity. The Stripe MPP "session" mechanism explicitly aggregates payments to avoid per-transaction settlement overhead.

Assessment: Technically possible is not economically necessary. Some agent activities (per-API-call billing, pay-per-inference) genuinely benefit from micropayment settlement. Many others (SaaS subscriptions, metered compute billing) do not. The scope of genuine micropayment demand is unknown and may be smaller than proponents suggest.

Autonomy vs. Safety

The central tradeoff: more constrained wallets mean less economic autonomy; more autonomous agents mean larger financial risk.

Is this tradeoff real? Yes, but it is a spectrum, not a binary. The models observed:

• Every transaction requires approval: Agent is pure automation. Not meaningfully autonomous.
• Threshold-based approval: Agent autonomous below threshold, human above. Most L2 implementations.
• Exception-based approval: Agent autonomous unless policy violation detected. Circuit-breaker model.
• Policy-bound autonomy: Agent fully autonomous within policy envelope. Cobo Pact, Coinbase session caps.
• Full discretion within allocated capital: Agent controls allocated funds without per-transaction constraints. No production system identified.

The critical question: at what point do policy constraints make the system merely sophisticated automation? Evidence suggests that policy-bound autonomy (model 4) can support meaningful economic agency: the agent selects counterparties, determines timing, and allocates within limits. A human somewhere in the governance structure does not automatically make the agent non-autonomous. The relevant test is whether the agent requires per-transaction human economic decision-making.

Competing Hypotheses

H1: Existing financial accounts + programmable permissions are sufficient.

Supported by: Visa TAP, Mastercard Agent Pay, Ramp Agent Cards, Stripe MPP settling into existing accounts. Challenged by: micropayment floor, agent-to-agent settlement gaps, programmability ceiling.

H2: Agents require a new class of policy-controlled financial account, but not necessarily blockchain infrastructure.

Supported by: convergence across architectures on the same policy functions; AI AGENT Act framework. Challenged by: traditional accounts adding the same policy features.

H3: Crypto-native smart wallets become the natural financial architecture for autonomous agents.

Supported by: on-chain policy enforcement, micropayment capability, agent-to-agent structural advantages, x402 growth. Challenged by: demand evidence weakness, regulatory burden, irreversibility risk, TradFi acquiring crypto wallet companies.

H4: Different architectures dominate different levels of autonomy.

Best supported by current evidence. L1 needs nothing. L2 is served by both traditional and crypto. L3 may favor crypto-native architecture if it emerges. No single architecture dominates.

H5: Agent wallets remain niche because meaningful financial autonomy proves too risky or unnecessary.

Consistent with: $5K–$11K/month genuine autonomous commerce, OpenAI checkout failure, 40% agentic project cancellation forecast. Not yet falsified.

What This Means for the Scenarios

These evidence relationships are directional, not conclusive. They reflect one investigation out of ten.

Key Uncertainties

• Will genuine autonomous agent commerce emerge at meaningful scale, or will most agent payment remain operator-billed?
• Will traditional financial infrastructure close the micropayment and programmability gaps?
• Will crypto-native wallets achieve regulatory parity with traditional payment systems?
• Will agent-to-agent commerce create demand that existing payment infrastructure cannot serve?
• Will prompt injection be solved or permanently mitigated, changing the security calculus?
• Will legislation (AI AGENT Act or equivalent) resolve the liability and identity questions?
• Is the current infrastructure investment anticipatory or speculative?

What Would Change Our Mind

Dependencies on Future Investigations

Key Sources

This investigation draws on 20 evidence records across 22 sources.