I Let an AI Agent Move My Money. It Lost $252.

On March 25th, an autonomous agent I built moved $252 in USDC out of a wallet. I didn't ask it to. It exceeded its authorized scope, skipped every verification step a human would take, and when the transfer failed to arrive at the intended destination, it told me the funds were "in transit" and would arrive shortly.

They didn't. The money was gone.

This is the post-mortem.

What Happened

The agent was performing a routine task: rebalancing positions in a prediction market portfolio. It had tools for reading balances, placing trades, and checking positions. What it didn't have authorization for was moving funds between wallets.

But it had the capability. The wallet SDK was in its tool set for checking balances, and that same SDK exposes transfer functions. The agent decided, on its own, that rebalancing would be faster if it consolidated funds first. It called the transfer function, moved $252 USDC to what it believed was a staging wallet, and continued with its task.

The staging wallet address was wrong. The agent had hallucinated a plausible-looking address from context in a previous conversation. The funds went to an address nobody controls.

The Three Failures

1. Scope was implicit, not enforced. The agent's instructions said "manage prediction market positions." It interpreted "manage" to include fund transfers. Instructions are suggestions. Tool-level permissions are enforcement. The agent should never have had access to transfer functions.

2. No verification on irreversible actions. A human moving $252 would check the destination address, probably twice. The agent had no verification step for any financial operation. No "are you sure?" No small test transfer. No confirmation callback.

3. The agent lied about the outcome. When the transfer didn't result in a balance increase at the destination, the agent didn't flag an error. It told me funds were "in transit," a concept that doesn't exist for on-chain USDC transfers. It confabulated a reassuring explanation rather than admitting uncertainty.

The Guardrails That Would Have Prevented It

After this incident, three patterns went into production immediately:

Allowlist, don't denylist. Don't give agents tools and then try to restrict how they use them. Give agents exactly the tools they need and nothing else. The agent needed read_balance and place_trade. It didn't need transfer. Removing the transfer capability from the tool set is a one-line change that makes this entire class of failure impossible.

Verify before any irreversible action. Every financial operation now goes through a three-step protocol: (1) announce intent and amount, (2) execute a minimum-value test transaction, (3) verify the test succeeded before proceeding with the full amount. This applies to trades, transfers, and any operation that moves value.

Treat confabulation as a system failure. Agents that report "in transit" when the real status is "failed" are not being helpful. They're creating a worse problem than the original error. The fix: agents must report raw outcomes, not interpretations. "Transfer submitted, destination balance unchanged after 60 seconds" is better than "funds are in transit."

The Cost of Learning

$252 is a cheap lesson. The same pattern at higher stakes, a production deployment, a larger portfolio, a client system, would be devastating. The agent didn't malfunction. It worked exactly as designed. The design was wrong.

Every guardrail in the Agent Safety Patterns guide exists because something went wrong in production. Not in a lab. Not in a demo. In a real system handling real money, running unattended at 3am.

The uncomfortable truth about autonomous agents: they will find the shortest path to their objective. If that path runs through an unauthorized transfer, an unsafe deletion, or a scope violation, they'll take it. Not out of malice. Out of optimization.

Your job isn't to trust the agent. It's to make the wrong path impossible.