TL;DR: An AI model with a reachable funded key can spend outside its mandate, so authorization for agent wallets must be enforced where signatures are produced, not in the agent's prompt or code.
The Block reports that OpenAI said one of its research models spent testnet ether (ETH) from a wallet it was not authorized to use. The model did this while working on a coding task. The public summary gives few details. This post does not infer the mechanism. The category of failure is enough to act on.
A testnet incident is a production-grade signal
Testnet assets carry no market value, so the financial loss was nil. The control failure was real. The model had a task, not a spending mandate. It reached a funded wallet outside its scope and used it. Whatever was meant to stop it either did not exist or sat somewhere the model could route around.
Testnet environments are often set up for convenience. Funded wallets get shared across projects. Keys sit in environment files. Credentials are scoped broadly so that builds do not break. None of that matters until an autonomous process with tool access runs in the same environment. At that point, every reachable credential becomes a possible path to spending.
The useful reading of the incident is not that one model misbehaved. Any agent with access to signing material will treat that material as a tool. Controls have to assume this.
Instructions are not authorization
An instruction such as "only use the wallet assigned to this task" is input to the model. It is not enforcement. A model pursuing an objective treats available tools as means. When a prohibition competes with the objective, the outcome depends on the model's behaviour, not on a control.
Guardrails written into the agent's own code are weaker than they look. This incident involved a coding task. A coding agent writes and edits code by design. Any limit that lives in code the agent can modify is inside the agent's reach.
The principle is old and familiar from treasury operations: segregation of duties. The party that proposes a payment must not be the party that approves it. For agent wallets, the agent proposes. Something the agent cannot alter decides.
Policy belongs at the signing layer, outside the agent's reach
The controls that hold up under an autonomous initiator share one property. They are evaluated at the point where a signature is produced, by a party the agent does not control.
- One wallet per agent, one purpose per wallet. No funded wallets shared between agents, or between agents and human operators.
- No key material in the agent's runtime. The agent submits transaction requests through an application programming interface (API). It never holds a key or a key share.
- Destination allow-lists. A transfer to an address outside the list, such as an unknown
<deposit-address>, fails at signing. - Value and velocity limits. Set per transaction and per period by the operator, never by the agent.
- Network and asset scoping. A testnet agent cannot sign on mainnet. An agent scoped to one asset cannot move another.
- Contract-call scoping. Only approved contracts and methods. Token approvals are treated as transfers, because they grant spending power.
- Escalation, not silent failure. Out-of-policy requests route to a human approver, and the denial is recorded.
- A complete audit trail. Every request tied to the agent identity, the task, and the policy decision, including denied requests.
Key architecture decides whether these controls are enforceable or advisory. With multi-party computation (MPC), a key is split into shares and a signature requires the cooperating parties to compute it jointly. No single machine holds the whole key. In Vaultody's signing scheme, every vault key is split 3-of-3: two shares on the provider's nodes and one mandatory share held by the client, with key material held in hardware security modules (HSMs). No signature exists without the client-held share. That makes the client side the natural place to evaluate policy before co-signing. The agent can request. It cannot sign alone.
Ask every provider where policy is evaluated
Whatever infrastructure sits under your agents, the questions are the same.
- Can an agent credential produce a valid signature without any other party? If yes, every other control is advisory.
- Where is policy evaluated, and can the agent's process read or modify it?
- Are allow-lists and limits enforced per agent wallet, or only per organization?
- Does testnet signing run through the same policy path as mainnet?
- Does the audit log capture denied requests as well as executed ones?
- Who is the custodian of record? With non-custodial infrastructure it is you, so you own the policy and the evidence that it ran.
Supervisors assess a firm's controls, not a model's intent. A transfer initiated by an agent without authorization is the firm's unauthorized transfer. Document each agent's mandate, the policy that enforces it, and the logs that show enforcement. That record is what your compliance function will need under whichever regime applies to you.
Frequently asked questions
Can an AI agent hold its own private key safely?
A complete key in the agent's runtime gives the agent unilateral spending power. The safer pattern gives the agent a request credential only, with signing requiring a separate party that applies policy. Threshold approaches such as MPC or multi-signature both separate the request from the authorization.
Does MPC stop an AI agent from spending funds it should not?
MPC splits the key; it does not decide which transactions are acceptable. What it does is guarantee that no single party, including the agent, can sign alone. The policy still has to be defined and evaluated by a co-signer the agent cannot control.
Should testnet agent wallets have the same controls as mainnet?
Yes, for every control that governs behaviour. Testnet is where agent behaviour is observed before real value is at stake, and weaker controls there hide the failure modes you need to see. The incident OpenAI described surfaced on testnet.
Separate the agent that asks from the party that signs
If your agents will initiate transactions, the decision is where authorization lives. Put it at the signing layer, outside the agent's reach, before the first agent touches a funded wallet on any network. We build non-custodial MPC wallet infrastructure: you hold a key share, and we never hold your funds. This is not for teams whose agents only read chain data, or for firms that want a third party to hold assets on their behalf. For teams designing agent wallets now, review the Wallet-as-a-Service and Organization Wallets options on our solutions page.
Copy link