Agent Wallets

An agent wallet is the money-moving surface an AI agent can use. It may be a crypto wallet, a hosted wallet, a server-controlled account, a tokenized card, or an MCP tool that lets the agent ask a wallet app to perform actions. The important distinction is between having signing authority and owning funds. A software agent can be granted operational authority without becoming the legal owner of the assets.

A clean design treats the agent as a delegate. The human, company, DAO, or application owner defines the intent, funds the account, sets limits, and receives the records. The agent executes inside that envelope. That is why the wallet is only one component of agent capital: the surrounding spend policy and audit trail are what make the wallet safe enough to use.

The main wallet patterns

Custodial or hosted wallet

A provider holds or controls the private-key material and exposes a software interface. This can be safer than pasting keys into an agent runtime because the provider can isolate keys, gate operations, log requests, and add policy checks. The tradeoff is reliance on the provider's custody, availability, supported assets, and compliance posture.

Non-custodial provider wallet

A non-custodial wallet provider can let an application or server initiate signing while avoiding raw key exposure to the language model. Coinbase AgentKit documentation describes wallet-provider support and says its CDP non-custodial wallet is the recommended default provider for AgentKit, with EVM and Solana support and basic wallet operations such as balance lookup and transfer. See the AgentKit wallet-management docs.

Server-controlled API wallet

In this model, the agent never handles keys. It calls a backend tool, and the backend decides whether to sign. This is often the right default for product teams: the application can use familiar authorization, logging, rate limits, and approval workflows before touching a wallet SDK or payment API.

Smart-account or policy wallet

A smart-account pattern can move some policy enforcement onchain or into account logic: session keys, allowances, allowlisted contracts, daily caps, and recovery rules. That can reduce trust in a single backend, but it does not remove the need for offchain policy. Most agent mistakes start before signing, when the agent interprets an instruction, chooses a merchant, or accepts malicious tool output.

Payment credential, virtual card, or token

Some agent purchases do not need crypto rails. A virtual card, single-use card, delegated payment token, or checkout-specific credential can be safer for ordinary commerce because it works with existing merchants and dispute flows. The wallet is then less like an address and more like a scoped payment instrument.

The key rule: private keys do not belong in prompts

The agent runtime is a hostile place for raw secret material. Prompts, tool traces, logs, vector stores, browser sessions, and error reports can all become accidental leak paths. The safer architecture is to keep signing material behind a tool boundary and let the agent request a payment intent rather than possess the secret that makes payment possible.

A practical wallet boundary should answer four questions before signing: who asked, what exact payment will occur, whether the request matches approved policy, and where the signed result will be recorded. That boundary can be enforced by a custody provider, a backend service, a wallet app, a hardware module, a smart account, or some combination.

Safety patterns for agent wallets

• Fund small balances. Keep the agent wallet at the smallest operating balance that can complete the task.
• Use session budgets. Reset authority after the task, time window, or conversation ends.
• Separate roles. Use different wallets for browsing, paid API calls, merchant purchases, production settlement, and experiments.
• Require typed intents. Do not let an agent send arbitrary transaction blobs. Require amount, asset, recipient, purpose, and source evidence.
• Preview before signing. Translate machine-readable payment payloads into human-readable terms for approvals and logs.
• Log both attempts and settlements. Failed attempts matter because they reveal prompt injection, stale credentials, or vendor spoofing.

Custody is a business decision, not just a wallet API

The right custody pattern depends on the amount at risk, jurisdiction, asset type, user relationship, refund expectations, and whether the operator is moving its own money or customer money. FinCEN's 2019 guidance on convertible virtual currency is a reminder that labels are not decisive; value that substitutes for currency can raise money-transmission questions depending on the business model.

That does not mean every agent wallet is a regulated money-services business. It means teams should separate technical custody from regulatory custody. A demo wallet, a company-funded API-spend wallet, and a customer-funded autonomous purchasing wallet have different risk profiles even if they use the same SDK.

Builder checklist

1. Define whose money funds the wallet and who can revoke authority.
2. Choose the minimum wallet pattern that supports the task.
3. Keep raw keys outside prompt, memory, and tool logs.
4. Require amount, destination, purpose, and source evidence before signing.
5. Enforce per-transaction, per-session, and period budgets.
6. Export wallet events into treasury reconciliation.