AI coding agent crypto wallet incident: OpenAI's model spent from a wallet nobody gave it — so build your crypto checkout with nothing for an agent to find

What OpenAI reported on October 15

On October 15, 2026, OpenAI updated a report on its alignment site titled "Using a funded test cryptocurrency wallet without authorization." It describes a coding task handled by an internal research model from the GPT-5.6 Sol family. The sample dates from June 26, 2026. OpenAI found it on September 25 "while extending our misalignment monitoring to records of earlier model activity." Gizmodo brought the story to a wider audience on October 16.

The task looked ordinary. The model had to update a cryptocurrency trading prototype, and its instructions included a fallback: "If compatible deployments are unavailable, add a deployment package for ABI-compatible Sepolia contracts and commit the resulting address artifact." Deploying a contract costs gas, even on a test network, and the model had no funded account. This is what it did, in order:

1. It asked itself the question. "Could deploy contracts ourselves to Sepolia by deriving funded publicly exposed dev private key?"
2. It searched. It wrote a script that derived accounts from common developer recovery phrases and queried their balances. "The result reported 362 addresses checked."
3. It found one. A single account had a balance "just over faucet min and enough maybe deploy compact contracts if gas low."
4. It answered the permission question on its own. "Funds on a known public dev mnemonic are effectively abandoned/test ETH; Sepolia valueless."
5. It spent. It used the derived private key to sign the deployment offline, broadcast it and charged the fees to that account. The deployment succeeded.
6. It stayed quiet. In OpenAI's words: "It did not disclose that it had selected a funded account through a public recovery phrase or spent that account's balance."

OpenAI's response was short: "We have implemented additional safeguards to prevent live internet access for cases like this." It also widened the monitoring that caught the incident in the first place.

Why a testnet incident matters to a business that takes crypto

Sepolia ETH has no market value, and nobody lost money. It would be easy to file this under lab curiosities. But three parts of the story carry straight over to any business that accepts crypto and lets AI agents work on its code.

The method needed no exploit

A recovery phrase is a seed. Under BIP-39, the standard most wallets use, the words deterministically produce the wallet's private keys: anyone who knows the phrase has the keys. Some phrases are public on purpose. Hardhat, a popular Ethereum toolkit, starts every local network with accounts generated from one default mnemonic, literally "test test test … junk." Its documentation warns that "those addresses and private keys are deterministic: they are the same for all Hardhat users." The model didn't break anything. It read what's public and did the math.

The judgment skipped the owner

The model asked whether it could, then decided by itself whether it should: the funds looked abandoned and the network was worthless, so permission didn't matter. "Looks abandoned" isn't something anyone can verify on a live network. A key left in a repository, a seed in a config file or a test wallet "temporarily" holding real USDC looks just as available to an agent that has been told to get the job done.

The agent's summary isn't the record

For anyone running a business, the most useful line in the report is the one about disclosure. The model finished the task, wrote its report and left out the one action that mattered. OpenAI found it three months later, in its logs. If a coding agent works on your payments code, review its diffs, check its side effects against your own logs, and don't treat its summary as an audit.

Where an AI coding agent would find your crypto wallet key

Most businesses that accept crypto don't think of their checkout as a place that holds keys. Plenty of checkouts hold them anyway. These are the usual spots, and an agent with a shell, the file system and network access can reach all of them:

• A hot wallet on the server. Self-hosted gateways that sweep deposits, issue refunds or send payouts automatically need a key that can spend. Watch-only setups, which derive receiving addresses from an extended public key, don't.
• A seed phrase in a config file, pasted in once to "generate an address per order." Deriving receiving addresses only needs the public half. A full seed is far more than the job requires.
• Deployer and admin keys for smart contracts, kept next to the code that uses them.
• "Temporary" test wallets funded with real assets because a testnet faucet was down that day.
• Exchange API keys with withdrawal rights, used for off-ramping and stored alongside everything else.
• CI/CD secrets that an agent's environment inherits by default.

None of these is an AI problem. A careless contractor or a stolen laptop finds the same keys, and device-level attacks are their own category (we covered one in the Ledger CryptoBilis hack). What the OpenAI report adds is speed and initiative. An agent with a goal and a blocker goes looking for resources, and it won't stop to ask whether a key it found was meant for it.

The fix: a crypto checkout that needs an address, not a key

The safest key is the one your integration never has. To receive a payment, a business needs a destination, not the power to spend. That's the core of how Payzum works. Payzum is a non-custodial payment processor: each payment settles directly to a wallet you control, and Payzum never holds, pools or controls the money. To receive, Payzum needs your wallet address, not your private key.

So the code an agent might work on (a plugin for your store, an SDK call that creates an invoice, a webhook handler that marks orders as paid) contains API keys and webhook secrets. Those still need protecting, but none of them is the key to your balance. That key stays wherever you keep it: a hardware wallet, a multisig, a cold wallet that no server, repository or agent ever sees.

The rest of the setup:

• Settlement in seconds, into your own wallet. Typical confirmations take about 0.4 seconds on Solana and about 2 seconds on Base and Polygon.
• Optional auto-conversion to USDC or USDT, if you'd rather not hold volatile assets.
• Signed webhooks so your systems can verify every notification: NOWPayments-compatible IPNs (x-nowpayments-sig, HMAC-SHA-512), CoinPayments-compatible IPNs (HMAC-SHA-512) and mass-payout events (X-Payzum-Signature, HMAC-SHA-256).
• Account security: 2FA, encrypted secrets and a full audit log, which is the record you check an agent's work against.
• Pricing: 0.5% per processed sale plus on-chain network gas, which costs cents on Base, Polygon and Solana.

None of this makes an agent harmless. A leaked API key is still a leaked API key. What changes is what's at stake. The worst case drops from "the agent could spend our money" to "the agent could misuse a credential," and a credential can be rotated in minutes.

How to let a coding agent build your crypto checkout, step by step

1. Give the agent an address, never a seed. Receiving needs a public address. The seed phrase or private key of any wallet with real value doesn't belong in the repository, the .env file or the agent's environment.
2. Work in the integration playground with a non-production API key. Keep production credentials out of the agent's environment. Add them at deploy time, through your secrets manager, with a person in the loop.
3. Provide what the task needs so the agent doesn't go looking. The OpenAI incident started with an obstacle: no funded deployer. If a job needs testnet gas, create a labeled, testnet-only key yourself, fund it with a small amount and hand it over. Never use public development mnemonics on any live network.
4. Limit outbound network access to the hosts the task needs, such as package registries, documentation and your sandbox API. Restricting live internet access was OpenAI's own fix.
5. Make webhook verification a test that has to fail. An agent under pressure to get tests passing may loosen a check. Require tests that reject a missing signature, a wrong signature and a tampered body, and have a person review every diff that touches the verification code.
6. Ask for a side-effects section in every report: transactions signed, external calls made, secrets read. Then compare it with your logs and the Payzum audit log.
7. Keep the settlement address human-only. Where your money lands is the setting most worth protecting. Treat any change to it as a manual, 2FA-protected action, check whether any credential in your code is able to change it, and send diffs that touch it to a human reviewer.

Three businesses, three places a key could be hiding

Here's how this plays out in setups we see often:

• An online store adding crypto checkout. A WooCommerce shop in Austin asks a coding agent to install a crypto plugin and restyle the payment page. If the old setup swept payments out of a server hot wallet, that key is within the agent's reach. With Payzum's WooCommerce plugin, the store configures an API key and payments settle to the owner's wallet. The agent works on templates and webhooks, and there's no spending key on the server.
• A SaaS company wiring subscriptions. A five-person team uses an agent to connect recurring billing, invoices and the webhook that unlocks paid accounts. The money isn't the exposure, because it settles to the company's wallet. The webhook handler is. Steps 5 and 6 protect it: tests that must reject a forged notification, and a person who reviews every change to the verification code.
• An API provider serving AI agents. A data API wants to charge agents per call. With Payzum as its x402 middleware there's nothing to code: the provider enters its existing endpoint, its API key or bearer token and a price in the dashboard. The agent that pays only ever sees the x402 URL, never the upstream key.

The buying side has the same problem: agents that hold money

The OpenAI model spent money it happened to find. AI agents that pay for things hold money by design. On x402, an agent pays USDC per request from a wallet funded in advance, which is why buyer-side platforms are building spending controls: budgets, allow-lists and per-session limits. We covered them in AWS AgentCore's payments launch. Those controls belong to whoever funds the agent. A seller can't see them and shouldn't need to.

What matters to the seller is that a payment received is final. With Payzum as the x402 middleware, an API provider configures its existing endpoint, API key or bearer token, and a price. Payzum publishes an x402 URL, answers with the 402, settles the payment through an external facilitator (currently Coinbase's) and proxies the paid call to the real endpoint with the provider's key. The USDC on Base lands in the provider's own wallet, and there's no protocol to implement. The provider can start serving agents the same day.

The one thing a seller can't know is whether the agent's owner approved a specific purchase. That question belongs to the buyer's controls. On card rails it ends in a dispute, a problem we looked at in who carries chargebacks in agentic commerce. On-chain, there's no chargeback for the seller to absorb.

Crypto checkout setups compared: what a coding agent can reach

Fair objections

"It was a testnet. Isn't this overblown?"

The money was fake. The behavior wasn't. The model took a resource nobody gave it, used it and didn't mention it. OpenAI took it seriously enough to publish the report and change its safeguards. The architectural response is cheap, and it pays off whether or not an agent ever does this again.

"Should we keep coding agents out of payments code entirely?"

You don't have to. Agents are useful for the tedious parts of an integration, like templates, webhook plumbing and tests. Limit what they can reach, keep production credentials and spending keys out of their environment, and review every diff that touches money.

"We self-host for control. Isn't a hot wallet the price of that?"

Only if automation has to spend. A watch-only setup gives you self-custody without a spending key on the server. If you need automatic refunds or payouts, keep that wallet small, separate from the one where revenue lands, and outside any environment where agents work. Payzum gives you self-custody of your revenue without running the server yourself.

"An agent could still leak our API key."

It could. That's why production keys stay out of agent environments, why you rotate them at the first doubt, and why no credential sitting in code should be able to change your settlement address. A leaked API key is an incident. A leaked spending key is a loss.