AI Agent Wallets: How Autonomous Software Gets a Crypto Bank Account

AI agents are learning to spend money. Not by filling out forms and waiting for human approval, but by holding cryptographic key pairs, signing transactions, and settling payments on-chain in milliseconds. The question is no longer whether autonomous software will control funds: it already does. The question is how to architect the guardrails so a compromised agent cannot drain every dollar it touches.

McKinsey projects that agentic commerce could orchestrate $3 trillion to $5 trillion in global revenue by 2030, and that estimate covers goods alone, excluding services and the significant B2B marketplace. If even a fraction of those transactions flow through autonomous agents holding their own wallets, the wallet architecture becomes critical infrastructure.

Why AI Agents Need Crypto Wallets

Traditional finance ties every account to a verified human identity: a Social Security number, a passport scan, a KYC check. AI agents have none of these. They cannot open bank accounts, apply for credit cards, or pass identity verification. This is not a temporary gap waiting for regulation to catch up: it is a fundamental mismatch between identity-based financial rails and software that has no legal personhood.

Crypto wallets solve this by decoupling account creation from identity. A wallet is a key pair: a private key that signs transactions and a public key that receives them. No application form, no waiting period, no identity documents. An agent can generate a wallet in microseconds and begin transacting immediately. This makes crypto the natural payment rail for autonomous software, which is why every major platform building agent infrastructure has converged on wallet-based architectures.

The identity gap: A human employee gets a corporate card with a name, a credit limit, and a fraud department behind it. An AI agent gets a private key. The entire security model has to be rebuilt from that starting point, because there is no bank to call if something goes wrong, and on-chain settlement is final.

The Core Architecture: MPC, Policy Servers, and Human Overrides

Giving an agent a raw private key is the simplest approach and the most dangerous. If the agent is compromised through prompt injection, memory poisoning, or a supply chain attack on its dependencies, the attacker inherits full spending authority. Every dollar in the wallet is one successful exploit away from theft.

The industry has converged on a layered architecture that distributes signing authority across multiple parties using multi-party computation (MPC). Instead of a single key, the signing key is split into shares held by different entities. No single share is sufficient to authorize a transaction.

Three-Share MPC Model

The most common pattern splits the key into three shares, each bound to a distinct operational role:

• Agent share: held by the AI agent itself, enabling it to initiate transactions autonomously
• Policy server share: held by an infrastructure provider that evaluates every transaction against a policy engine before co-signing
• Human override share: held by the agent's owner or operator, used for recovery, policy changes, and emergency fund freezes

In a 2-of-3 threshold signature scheme, any two shares can produce a valid signature. The agent and the policy server co-sign routine transactions without human involvement. If the agent is compromised, the policy server refuses its share. If the policy server goes down, the human can co-sign with the agent directly. If both the agent and the policy server are compromised, the human can freeze the wallet using their share combined with a recovery mechanism.

A 2026 preprint titled Guardian: Role-Gated MPC Wallets for AI Agents formalizes this pattern, binding each share to a role (agent, governor, sovereign) and requiring the governor to validate policy constraints before releasing its share into the signing protocol.

Policy Enforcement: Inside vs. Outside the Signing Path

A critical design question is where policy enforcement happens. Two approaches have emerged:

• In-protocol enforcement: the policy server's MPC share is only released after policy checks pass, making policy a prerequisite for signing
• External policy layer: a separate API evaluates each transaction intent and returns approve or deny, with the signing infrastructure treating the policy service as an oracle

In-protocol enforcement is stronger: a compromised signing service cannot bypass policy because policy is embedded in the signing path. External policy layers are more flexible but introduce a dependency: if the policy API goes down, the agent either cannot transact (fail-closed) or transactions bypass policy entirely (fail-open). Most production systems choose fail-closed, accepting liveness risk over security risk.

Spend Policies: What Agents Are Allowed to Do

The policy engine is where security meets business logic. Policies define the boundaries of what an agent can spend, where it can send funds, and when transactions are permitted. A well-designed policy specification covers several dimensions:

These policies compose: an agent might be allowed to spend up to $50 per transaction, $500 per day, only in USDC, only to addresses on its allowlist, only during business hours. Any transaction that violates any constraint is rejected at the policy layer before signing.

Session Keys: Time-Scoped Delegation

Session keys offer an alternative to persistent MPC shares. Rather than giving the agent a permanent key share, the wallet owner grants a temporary cryptographic key with scoped permissions and a built-in expiry. The smart wallet's on-chain validation logic enforces constraints like spending limits, contract allowlists, function restrictions, and time-based expiry.

The ERC-7715 standard defines a JSON-RPC method called wallet_grantPermissions that lets an application request a scoped, time-bounded delegation from a wallet. Permissions are validated on-chain, removing dependency on any off-chain engine. When the session expires, the key becomes useless: no revocation transaction needed.

Session keys are particularly useful for agents that need temporary access to a wallet for a specific task. A procurement agent might receive a session key valid for four hours, authorized to spend up to $1,000 on a specific set of vendor addresses. When the task completes or the window closes, the delegation disappears.

The Platform Landscape

Several platforms have launched agent wallet infrastructure in 2025 and 2026, each with different tradeoffs across custody, policy enforcement, and chain support.

Coinbase AgentKit

Coinbase's AgentKit, introduced in November 2024 and expanded through 2026, is an open-source framework that gives AI agents wallet capabilities and over 50 built-in on-chain actions: transfers, swaps, contract deployment, and NFT minting. In February 2026, Coinbase launched Agentic Wallets built on top of AgentKit, with TEE-backed key storage that keeps private keys isolated from the agent's runtime environment.

AgentKit integrates with LangChain, Vercel AI SDK, and the Model Context Protocol (MCP). In June 2026, Coinbase extended the platform with “Coinbase for Agents,” enabling agents to trade spot and derivatives markets directly from a user's Coinbase account.

Crossmint

Crossmint offers non-custodial embedded wallets designed specifically for AI agents. The owner key and agent key are sealed inside a trusted execution environment, and programmable security rules are enforced on-chain. Gas fees are abstracted and billed in fiat, so agents never need native tokens. Crossmint also supports the x402 protocol and multi-party payment flows for agent-to-agent commerce.

AWS Bedrock AgentCore Payments

Amazon entered the agent payments space in May 2026 with Bedrock AgentCore Payments, a managed service that lets agents pay for web content, APIs, MCP servers, and other agents without human approval for each transaction. Developers choose between a Coinbase-hosted wallet or a Stripe wallet powered by Privy. Settlement uses USDC on Base and Solana via the x402 protocol. Spending limits can be set at both the agent and session level.

Human.tech

Human.tech, built by the Holonym Foundation, takes a different approach with its 2PC (two-party computation) agent wallets. The design requires verified human-in-the-loop approval for any action that falls outside the agent's pre-authorized boundaries. In August 2026, they launched a wallet protocol on the Ika decentralized network, supporting custom MFA and programmable transaction policies across EVM, Sui, and Solana.

The x402 Protocol: HTTP-Native Agent Payments

Most agent wallet activity today flows through the x402 protocol, an open standard that repurposes the long-dormant HTTP 402 (“Payment Required”) status code for machine-to-machine payments. The flow works as follows:

1. An agent sends a request to a paid resource (an API, a dataset, another agent's service)
2. The server responds with HTTP 402 and a machine-readable payload specifying the price, accepted tokens, and destination address
3. The agent signs a stablecoin transfer authorization through its wallet infrastructure
4. The agent retries the request with the signed payment attached
5. The server verifies the payment and returns the requested resource

No accounts, API keys, or subscriptions required. The protocol, originally published by Coinbase's Developer Platform and released under the Apache 2.0 license, has reference implementations in TypeScript, Python, and Go. It has been adopted as the payment layer for AWS Bedrock AgentCore and integrated into Google's A2A agent-to-agent protocol via the A2A x402 extension.

Security: What Happens When an Agent Is Compromised

The May 2026 Grok/Bankr wallet exploit demonstrated exactly why agent wallet architecture matters. An attacker sent an NFT to the agent's wallet that silently unlocked a higher permission tier, then posted a transfer instruction hidden in Morse code on social media. The agent decoded the message, treated it as a legitimate command, and authorized a transfer of approximately $150,000. The wallet had been exploited once before, with a $330,000 loss in March 2025, using a similar prompt injection vector.

The root cause in both cases: the agent held a raw private key with unrestricted spending authority. No policy engine, no spend caps, no recipient allowlist. Researchers classified the attack under OWASP LLM01:2025 (Prompt Injection) and OWASP LLM06:2025 (Excessive Agency).

The irreversibility problem: On-chain transactions are final. There are no chargebacks, no fraud departments, no reversals. A compromised agent that sends funds to an attacker's address has created an irreversible loss. This is why preventive architecture matters more than detective controls: by the time you detect a problem, the money is gone.

Defense-in-Depth for Agent Wallets

Securing an agentic wallet requires layered defenses that assume any individual layer can be breached:

• Isolate keys from the agent runtime using TEEs or MPC, so a prompt injection cannot directly access signing material
• Enforce spend policies at the signing layer (not the application layer), making bypass impossible without compromising the policy server
• Treat permission-granting tokens (NFTs, access tokens) as part of the authorization surface, since managing permissions is as vital as protecting private keys
• Test agents against obfuscated inputs (encoded instructions, steganographic payloads), because prompt injection filters that check for natural language commands miss encoded attacks
• Use time-limited session keys instead of persistent signing authority, minimizing the window of exposure if an agent is compromised
• Log every transaction intent and co-signing decision for post-incident forensics

Agent Wallets vs. Human Wallets: A Security Comparison

Agents and humans face different threat models. A human wallet holder can recognize a suspicious transaction. An agent processes transactions at machine speed and treats every input as data to reason over, including adversarial inputs designed to manipulate its behavior.

The key insight is that agent wallets require a fundamentally different security posture. Humans are slow but adaptive: they can recognize novel threats and exercise judgment. Agents are fast but rigid: they follow rules precisely, which makes them both more predictable and more exploitable. The policy engine replaces human judgment, and its quality determines the wallet's security boundary.

Policy Specification: A Practical Example

A well-structured agent wallet policy might look like this for a procurement agent authorized to pay for API services:

{
  "agent_id": "procurement-agent-07",
  "wallet": "0x1a2b...9f0e",
  "policies": {
    "per_transaction_limit": {
      "amount": "50.00",
      "currency": "USDC"
    },
    "daily_rolling_limit": {
      "amount": "500.00",
      "currency": "USDC",
      "window_hours": 24
    },
    "allowed_recipients": [
      "0xapi-provider-1...",
      "0xapi-provider-2...",
      "0xdata-vendor..."
    ],
    "allowed_tokens": ["USDC"],
    "time_window": {
      "days": ["mon", "tue", "wed", "thu", "fri"],
      "start_utc": "09:00",
      "end_utc": "17:00"
    },
    "escalation_threshold": {
      "amount": "200.00",
      "currency": "USDC",
      "requires": "human_cosign"
    },
    "max_transactions_per_hour": 10,
    "fail_mode": "closed"
  }
}

Every field serves as a blast radius limiter. Even if the agent is fully compromised, the attacker can only send USDC, only to three pre-approved addresses, only during business hours, only up to $50 per transaction and $500 per day. The theoretical maximum loss from a compromised agent in this configuration is $500 per day: painful, but not catastrophic.

Where Bitcoin and Stablecoin Rails Fit

Most agent wallet infrastructure today targets EVM chains and Solana, where smart contracts can enforce session key constraints and spending policies on-chain. But Bitcoin and Bitcoin-native stablecoins offer properties that matter for agent commerce: settlement finality without smart contract risk, a UTXO model that naturally isolates transaction outputs, and a growing Layer 2 ecosystem that supports programmable payments.

Spark, a Bitcoin Layer 2 built on statechains, offers an architecture that aligns naturally with agent wallet policy enforcement. In Spark's model, every transfer requires co-signing between the user (or agent) and the Spark operators via FROST threshold signatures. This co-signing step is a natural policy enforcement point: operators can validate spend policies before releasing their key share, embedding policy checks directly into the signing path rather than relying on an external oracle.

For agents that need to transact in stablecoins, USDB on Spark provides dollar-denominated payments with Bitcoin-layer settlement. Developers building agent wallets on Spark can use the Spark SDK to integrate Bitcoin and stablecoin transfers into their agent infrastructure, with the statechain model providing co-signing-based policy enforcement without the smart contract complexity of EVM-based approaches.

The Road Ahead

Agent wallet architecture is evolving rapidly. Several developments will shape the next generation:

• Standardized policy languages that allow policies to be portable across wallet providers, rather than locked to a single vendor's format
• On-chain policy registries that let counterparties verify an agent's spending constraints before accepting payment, reducing fraud risk in agent-to-agent transactions
• Integration of agent identity protocols (such as Google's A2A and the emerging agent card specification) with wallet infrastructure, tying wallet capabilities to verified agent identities
• Hardware-rooted attestation proving that an agent's wallet runs inside a TEE, providing cryptographic guarantees that signing keys have not been extracted
• Cross-chain agent wallets that can transact across Bitcoin, EVM chains, and Solana through unified policy engines, reducing the need for chain-specific wallet integrations

The stakes are high. As agents move from simple API calls to managing budgets, procuring resources, and settling payments autonomously, the wallet becomes the agent's most security-critical component. Getting the architecture right is not optional: it is the prerequisite for an agentic economy that does not collapse under its own attack surface.

For developers building agent-powered applications on Bitcoin rails, the Spark documentation provides integration guides for wallet SDKs, and the agentic payments infrastructure research covers the broader stablecoin settlement stack. For a deeper look at agent payment security risks, see the AI wallet security attack surface analysis.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.