When an AI agent accidentally sends crypto, the transfer usually cannot be reversed: a confirmed blockchain transaction is final, and there is no bank to call. The damage is decided before the transfer, by how much the agent's wallet holds and which checks run before a transaction is signed. Agent toolkits such as Solana Agent Kit give agents tools to move tokens directly from a wallet, which makes those checks the real safety layer (Solana Agent Kit on GitHub).
​

This article covers why mistaken agent transfers happen, what can and cannot be done afterward, and the controls that stop them.
​

A mistaken crypto transfer cannot be undone because blockchains settle transactions without a central party that can reverse them. Once a transaction is confirmed, the tokens belong to the receiving address. Recovery depends on the recipient choosing to send them back, or on the token issuer having freeze powers, which applies only to some assets.
​

This is the core difference from card payments, where chargebacks exist. It is why limits on agents that pay onchain must work before a transfer, not after. For background on how agents hold funds, see agent wallets.
​

AI agents send crypto by mistake for four main reasons: the model misreads an address, amount or token; injected text in content the agent reads tells it to pay someone; a retry or schedule repeats a payment; or the agent acts on stale prices. Each one passes through the same point: the moment a transaction is signed.

AI agent payment mistakes are prevented by limits the model cannot change: a wallet that holds only what the agent may spend, allowlists of approved recipients, per-transaction caps, human approval for large transfers, and conditions checked inside the transaction. Instructions in a prompt help, but they are not enforcement.
​

The last row is where Eco's Sauce SDK fits. A Sauce program checks conditions such as recipient, amount and minimum received against live onchain state, and the program refuses to settle outside the limits it encodes: an uncaught failure reverts the whole transaction (Sauce docs). Earlier approvals and network fees sit outside that rollback.
​

After a mistaken agent transfer, stop the agent, revoke its token approvals and keys, record the transaction hash, and identify the recipient. If the recipient is an exchange or known service, contact its support with the hash. If the token issuer can freeze assets, report it to the issuer. Recovery is never guaranteed.
​

Then fix the control that failed before restarting the agent. See security risks of autonomous AI agents and agentic trading.
​

Agent payment mistakes follow a small number of patterns. Knowing them makes it easier to decide which control stops which mistake.
​

An agent copies an address from a message, a web page or its own memory and gets it wrong, or picks up a lookalike address planted by someone else. Address poisoning, where an attacker sends a tiny transfer from an address that resembles one the victim uses, targets exactly this kind of copy-from-history behavior. A recipient allowlist stops it, because the agent can only pay addresses the owner approved in advance.
​

Tokens use different decimal places. An agent that confuses base units with display units can send far more, or far less, than intended. A per-transaction cap expressed in base units stops the over-send case regardless of what the model believed.
​

Many tokens share names and tickers, and the same token can exist on several chains. An agent may send a token the recipient's address cannot use, or send on a chain the recipient does not monitor. An allowlist of token contract addresses and chains stops this.
​

Retries are normal in software. If an agent's tool call times out but the transaction actually went through, the agent may try again. Idempotency keys, nonce checks or a ledger of sent payments that the agent checks before each send stop duplicates.
​

An agent that reads untrusted content, such as social posts, emails, token descriptions or websites, can be told to send funds somewhere. This is the hardest mistake to stop with prompts alone, and the easiest to stop with a destination allowlist enforced outside the model.
​

A swap decided at one price may execute at another. Without a minimum-received bound checked at execution, the agent gets whatever the market gives. Slippage limits and in-transaction checks stop this.
​

A pre-signing check is code that runs after the agent proposes a transaction and before the wallet signs it. It is the single most useful place to stop mistakes, because every transfer must pass through it. A practical checklist:

Each answer should come from configuration the agent cannot change. If the agent can edit its own allowlist or raise its own cap, the check is decoration.
​

The way an agent holds funds decides how much one mistake can cost. The main options:
​

These stack. A common pattern is a small dedicated wallet, a policy check before signing, and conditions in the transaction for anything that swaps or routes funds. For a deeper look at the wallet layer, see agent wallets.
​

Agent toolkits differ in how much safety they build in, so developers need to read what each tool does with the key. Solana Agent Kit's README says the toolkit "handles transaction generation, signing and sending, using provided wallets," and warns users to "never share your private keys" (Solana Agent Kit on GitHub). Its swap example takes a slippage parameter, and it offers both an interactive chat mode and an autonomous mode with configurable action intervals.
​

That design is common: the toolkit makes actions available and signs them with the wallet it is given. Limits on who gets paid and how much are the developer's responsibility. Interactive mode, where a person sees each action, is a reasonable default until those limits are in place.
​

Testing an agent on a testnet with test tokens catches most configuration mistakes before they cost anything. A short test plan:

Sauce supports this style of testing for programs: sauce simulate runs a program without a key or money, so a developer can see whether conditions pass before anything is signed. Simulations can go stale, since state may change before sending (Sauce docs).
​

Agent mistakes differ from human ones in speed and repetition. A person who pastes the wrong address usually does it once and notices. An agent with a flawed rule or a poisoned input can repeat the same mistake many times before anyone looks, especially if it runs on a schedule. That is why caps on totals per day or per week matter as much as caps per transaction, and why alerts on unusual activity should go to a person who can stop the agent quickly.
​

Agents also make mistakes a person would rarely make, such as trusting an instruction hidden in a token description. And they avoid some human ones, such as fatigue or typos in amounts they compute correctly. The control design should target the agent's actual failure modes, not the ones people are used to guarding against.
​

When an agent sends crypto by mistake, a clear record helps with recovery requests and with fixing the cause. Record the transaction hash, chain, token, amount, recipient, the time, the agent's proposed action as it appeared before signing, the inputs the agent read just before, and which checks ran and passed. That last item usually shows which control was missing.
​

Not by the sender. Only the recipient or, for some tokens, the issuer can act.
​

No. Limits must be enforced by the wallet, payment rail or transaction.
​

An attack where someone sends a tiny transfer from an address that looks like one you use, hoping you or your agent copies the wrong address later. Recipient allowlists stop it.
​

Only for a small, dedicated wallet, and ideally behind a signing policy or scoped onchain permissions rather than as a raw key in the agent's runtime.
​

Sometimes, if the funds landed in an account the exchange controls and its support team agrees to help. Contact them with the transaction hash. There is no guarantee.
​

Immediately. Pause the agent and revoke its approvals before investigating, so a repeating fault or an attacker cannot send more while you work out what happened.
​

Some stablecoin issuers have contract-level freeze powers and policies on when they use them. Whether they act in a given case is their decision; contact the issuer through its official support channel with the transaction hash, the chain and the recipient address, and keep a copy of what you sent.
​

Sources: documentation linked inline, accessed November 2026.
​