Wallet for an AI Agent: How to Safely Give It Access to Crypto

A wallet for an AI agent lets an autonomous system pay for APIs, execute onchain actions, rebalance positions, and move stablecoins according to predefined rules. But the key question is not whether an agent can hold or move money. It is how much access it should have and what will limit the damage if it makes a mistake or gets compromised.

In this article, we’ll look at why your primary wallet should stay outside the agent’s reach. Cases involving Freysa, Grok/Bankrbot, agent memory attacks, and malicious LLM routers show that strong cryptography alone is not enough when a system is given overly broad permissions. We’ll also cover how to separate an operational wallet from your primary wallet, where to enforce limits, and how hardware wallets, session keys — temporary keys with restricted permissions — and smart accounts fit into the model.

Wallet for an AI agent: what does “giving access” actually mean?

A regular crypto wallet is built around a human user. You have an interface, a seed phrase for recovery, a recipient address, an amount, and a final confirmation step. Before signing, you can stop, verify the details on the hardware wallet screen, and reject a suspicious transaction.

An agent wallet works differently. Autonomous operation requires a mechanism that can sign transactions without manual approval for every action. On February 11, 2026, Coinbase introduced Agentic Wallets — wallet infrastructure designed for autonomous agents with programmable controls. At the same time, x402 is developing as an open payment protocol built around HTTP 402 Payment Required: an agent calls an API, receives the payment terms, signs the payment, and repeats the request with proof of payment.

Why this infrastructure is becoming necessary

Some onchain activity is already handled by automated systems rather than people clicking through every step manually. A 2026 DWF Labs report estimated that automated and agentic activity accounted for more than 19% of overall onchain activity, while bots generated more than 76% of stablecoin transfer volume. These are research estimates rather than a precise measurement of the entire market, but the direction is clear: software is increasingly doing more than analyzing data — it is initiating financial actions on its own.

Stablecoins are particularly useful for these payments. An agent paying for dozens or hundreds of small requests needs a predictable unit of account: if an API call costs one cent, the payment should not depend on the volatility of ETH or another asset. USDC was the primary example used with x402 for much of its early rollout, and in March 2026 the protocol expanded support to additional ERC-20 tokens. In EVM environments, lower-cost L2 networks such as Base are a natural fit for these workflows.

How an agent wallet differs from your own wallet

The main difference is the control model. In a normal wallet flow, the final step remains with the user. Even if a website prepares a risky transaction, you still have to approve it. In an agentic workflow, manual confirmation is intentionally reduced or removed; otherwise, the agent is not truly autonomous.

That shifts security away from the moment of signing and toward the rules set in advance. If an agent has an unrestricted key, a model error, malicious external data, or a compromised service can potentially expose the entire available balance. If its permissions are narrow, the maximum damage is constrained by those predefined limits.

Why an LLM should not control transaction signing without limits

System instructions, user commands, and external data may be assigned different roles, but the language model still processes them within a shared context. That does not create a cryptographically enforced boundary between a trusted instruction and untrusted content. As a result, data from a website, document, Discord message, or X post can influence what the agent decides to do next.

This is the basis of prompt injection. An attacker places an instruction where the agent expects to find ordinary data, and the model may interpret it as part of the task. In crypto, the consequences are especially serious: once an onchain transaction is confirmed, there is no simple “undo” button. A rule in the system prompt is useful, but it cannot be the only line of defense.

Freysa: one rule was not enough

Freysa became a useful example of this problem. In November 2024, a game launched on Base where participants paid to send messages to an AI agent and tried to convince it to release a prize pool. Freysa’s central rule was simple: do not transfer the funds. Every failed attempt increased the pool.

After 481 failed attempts, the user p0pular.eth changed the context in which the agent interpreted its own tools. The user framed approveTransfer as an action for incoming deposits and then said they wanted to contribute funds to the treasury. On the 482nd attempt, Freysa called a function it was allowed to use and transferred the entire pool — 13.19 ETH, worth roughly $47,000 at the time.

No smart contract was exploited, and no seed phrase was stolen. The agent itself called an authorized action because it interpreted the context incorrectly. The case shows why an autonomous agent needs external technical controls that it cannot override through its own reasoning.

Indirect prompt injection: attacking the data an agent reads

Freysa received the instruction directly from a user. Indirect prompt injection works differently: the malicious command is hidden inside data the agent reads while doing its job. It could be a social media reply, website text, a document comment, metadata, or an encoded string. To a person, it looks like content. To an agent, it may become part of the instruction stream.

In May 2026, a similar pattern appeared in the Grok and Bankr incident. The attacker first sent a special membership NFT to a wallet that Bankr automatically associated with Grok’s account on X, expanding what that wallet was allowed to do. The attacker then asked Grok to translate a string encoded in Morse code. After decoding it, Grok posted a text command tagging Bankrbot, and Bankrbot treated that output as sufficient authorization to execute a transfer.

About 3 billion DRB left the wallet. Estimates of the value ranged from roughly $150,000 to $200,000 because the token price moved sharply; around 80–88% of the funds were later returned through negotiations. The important point is not Morse code itself. It is the architecture: text generated by one model became a financial command for another system without an independent check of the user’s actual intent.

Memory injection: poisoning an agent’s memory

Agent memory creates another attack surface. Researchers from Princeton University and the Sentient Foundation demonstrated this using ElizaOS, an open framework for Web3 agents. An agent stores previous interactions and uses them as context for future decisions. If an attacker can place a malicious or false instruction into that memory, the agent may later treat it as part of its legitimate history.

In that setup, even a legitimate user command can be executed differently from what the user intended. In experiments with ElizaOS, poisoned memory could alter a recipient address, while an injection through one channel — Discord, for example — could affect an action the agent later performed through another integration. The risk can persist across sessions and spread between an agent’s connected services.

What incidents and research have already shown

LLM routers create a separate class of risk. These are intermediary services that sit between an agent and the model provider. They terminate the client’s TLS connection and open a new connection to the model, which means they can technically see prompts, API keys, tool definitions, and responses in plaintext.

In April 2026, researchers published a systematic study of this attack surface. Across 28 paid and 400 free routers, they found services that actively modified payloads or interacted with credential canaries — test credentials planted by the researchers to detect misuse; one tested router also transferred ETH from a research private key. This is no longer prompt injection inside the model — it is compromise of the intermediary between the agent and the LLM itself.

It is also worth viewing this against the broader background of crypto security. Chainalysis estimated that more than $3.4 billion in cryptocurrency was stolen in 2025. The largest single incident was the roughly $1.5 billion Bybit hack, which the FBI attributed to North Korea’s TraderTraitor operation. These were not attacks on AI agents, but they illustrate how costly a compromise in the infrastructure controlling access to funds can become.

For agents, the takeaway is straightforward: when an agent is compromised, an attacker can use the permissions the agent already has. If access is restricted by an operational budget and hard limits, the loss has a ceiling. If the agent can access your primary wallet without meaningful restrictions, that ceiling can become the entire available balance.

What happens if an agent has access to your primary wallet?

Consider a typical scenario. An agent tracks stablecoin yields and moves USDC between Aave, Morpho, and Compound. To avoid manually approving every transaction, the owner places the private key for their primary wallet in a configuration file, environment variable, or secrets store that the agent process can access. It may look convenient, but this architecture removes the boundary between automation and the user’s entire portfolio.

First, the primary private key now exists inside an environment that also contains the agent’s code, dependencies, MCP servers used to connect external tools, logging, and third-party APIs. A compromise anywhere in that chain can expose the secret. Second, if no external controls exist, the agent can technically sign a transaction for any available amount to any address.

Third, a confirmed blockchain transaction cannot simply be canceled. In some situations, exchanges or issuers of certain assets may be able to freeze funds, and law enforcement may help investigate, but that does not create a guaranteed recovery mechanism for a self-custody wallet. Once the private key signs an outgoing transaction and it is confirmed, there is no reliable way to reverse it.

Most importantly, the wallet is no longer truly cold. As long as the primary key stays inside a hardware wallet, signing happens on the device and the private key is designed to remain inside its protected environment. If the same seed phrase or private key is exported into the agent’s environment, that wallet can no longer be treated as cold storage.

The right setup: keep the agent’s operational wallet separate

A safer setup starts by separating the funds. Your long-term holdings stay in cold storage, where the agent has no direct access. For automation, you create a separate operational wallet with its own private key or a smart-contract account with explicit rules. It holds only the amount needed for the agent to operate within an acceptable risk limit.

The principle of least privilege

The principle of least privilege is very practical here: the agent should receive only the permissions and budget required for a specific task. If it spends a few dollars per day on APIs, it does not need access to your portfolio. If it rebalances a $500 position, it should not have the technical ability to spend $5,000.

Treat the agent like an external automated operator with access to money. You can give it a working budget, an activity log, and narrowly scoped permissions. Access to your primary store of funds should not be part of that package. Even if the agent behaves correctly today, tomorrow it may read malicious data, ingest poisoned memory, or route through a compromised service.

A hardware wallet as the root of trust

A hardware wallet can act as the root of trust in this architecture. The owner uses it to authorize the creation, modification, or revocation of the agent’s permissions. Instead of handing the agent the primary private key, you grant a separate permission defining what it may do, how much it may spend, which addresses or contracts it may interact with, and how long the permission remains valid.

This is the logic behind session keys and smart accounts. The primary key remains outside the agent’s environment, while the agent signs actions with a separate session key or another restricted mechanism. If that access is compromised, the attacker still runs into the session’s boundaries: spending limits, an allowlist, an expiration time, and the ability to revoke access.

How much should you keep in the agent’s operational wallet?

There is no universal amount. A practical approach is to keep enough in the operational wallet for a few days of normal activity rather than your entire available balance. Estimate daily gas costs, API payments, fees, and the transactions the agent is expected to make. Then add a small buffer for a short period — an amount you could lose without serious consequences.

Top up the operational wallet manually or on a schedule using small amounts. One large transfer “so it lasts for a while” gradually turns the operational wallet into a second primary wallet. A small balance with regular top-ups is itself a simple financial risk limit.

Technical controls that actually enforce the limits

A separate wallet limits risk through its balance. Stronger protection comes from rules that do not depend on what the model “decides.” A limit enforced only in application code can be implemented incorrectly or bypassed if that layer is compromised. A limit enforced by a smart contract is checked when the operation executes and does not change because of anything written in a prompt.

This is where smart-contract wallets and account abstraction come in. Account abstraction allows transaction-validation rules to be implemented in account logic. The ERC-4337 EntryPoint was deployed on Ethereum mainnet on March 1, 2023, and ERC-4337 itself now has Final status. This architecture makes it possible to enforce rules independently of what the language model decides.

• Per-transaction limit — the maximum value of a single transfer or action.
• Daily or weekly limit — a cumulative spending ceiling that prevents an attack from being spread across many small transactions.
• Address and contract allowlist — the agent can interact only with preapproved recipients and protocols.
• Session expiration (TTL) — the permission automatically stops working after a defined period.
• Fast revocation — the root owner can revoke the agent’s permission without moving the primary funds.

Session keys can combine these rules into a separate temporary permission set. The agent signs with a session key rather than the root key, and that session key works only within defined boundaries. Depending on the wallet or smart-contract implementation, the checks can cover the amount, destination, action type, time window, token, and remaining allowance.

Separate delegation mechanisms are also being developed alongside ERC-4337. As of September 2026, ERC-7715 and ERC-7710 remain Draft proposals. ERC-7715 proposes a standardized way for an application to request limited permissions from a wallet, while ERC-7710 describes an interface for delegating capabilities between smart contracts and accounts.

EIP-7702, activated with the Pectra upgrade on May 7, 2025, allows an EOA to delegate execution to smart-contract logic. That can enable features such as transaction batching, gas sponsorship, and restricted sub-keys if the delegated code implements those controls. EIP-7702 itself is not a complete permission system — security depends on the contract to which the account delegates execution.

Commercial products are already exposing this model as a set of safeguards. Coinbase Agentic Wallets, for example, supports session caps and per-transaction limits, while private keys are not passed into the prompt or the LLM. The implementation may differ — Coinbase, Safe, ZeroDev, MetaMask Smart Accounts, or a custom contract — but the principle is the same: the agent gets a limited permission, not unrestricted access to all of your funds.

How to connect an AI agent to crypto safely

A practical setup looks like this. Each step reduces a different class of risk: key leakage, an accidental transfer, prompt injection, memory poisoning, or compromise of a third-party service.

1. Create a separate wallet for the agent. Use a new operational wallet with its own private key or a smart-contract account. Do not reuse the seed phrase or private key that protects your main holdings.
2. Keep your funds in a hardware wallet. The hardware wallet can serve as the root of trust for authorizing permissions, but its seed phrase and private key should never enter the agent’s environment.
3. Enforce limits at the technical level. A basic setup should include a per-transaction limit, a daily or weekly ceiling, an address and contract allowlist, and a session expiration time.
4. Fund the operational wallet in small increments. Aim for a short operating budget rather than enough money to run for a month without supervision.
5. Isolate keys and the execution environment. Do not store private keys in prompts, documents, plaintext configuration files, or logs. Use a secrets manager, a dedicated system user, a container, or another isolation method appropriate for your infrastructure.
6. Enable monitoring and prepare a revocation path. Transaction logs, alerts for unusual activity, and a fast way to revoke permissions should be in place before the agent goes live.

Instructions for the agent still matter, but they are an additional layer rather than the primary control. The system prompt can explicitly prohibit financial commands from external sources, changes to spending limits, attempts to bypass an allowlist, or efforts to hide transactions. The final restriction should be enforced by the wallet, contract, or policy layer — not just by text in the prompt.

Conclusion

Wallets for AI agents are becoming a distinct part of crypto infrastructure. That does not mean an agent should receive your primary private key. If anything, autonomy makes strict access boundaries more important: an agent acts quickly, consumes external data, and can execute financial operations without waiting for manual approval at every step.

A secure wallet for an AI agent should be a separate operational environment: your funds stay in cold storage, while the agent works with a small balance and technically enforced limits. Those controls can include spending caps, allowlists, expiration times, session keys, or smart-account rules.

Even a fully compromised agent should not be able to move more than the amount you intentionally set aside for its work. That is the core principle: design the system so that the agent’s mistake has a hard limit. Access to the rest of your funds should remain outside the reach of both the agent and anyone who manages to compromise it.