Can an AI agent spend your money, and how is it stopped from overspending?
An AI agent does not hold your money. What it holds is a budget and a key that opens exactly one settlement entrance, and inside our product the balance it draws down is One — an in-product credit and compute unit, not your bank card; moving real money out to an outside merchant is the line we deliberately stop at, and the agent wallet that would cross it is still in development. Overspending is prevented by the runtime rather than by an instruction in a prompt: before a step runs, its worst-case cost is checked against both the delegation budget and the balance, and after the step actual cost is reconciled immediately, so the delegation halts the moment it goes over instead of arriving as a bill at the end. Every step also carries an idempotency key and a fingerprint of its own content, so a dropped connection and a retry cannot charge twice, and a step with no valid approval or no executor is blocked rather than silently skipped.
Ask one question before any other, because the answer decides how much every other control is worth: which side of the platform boundary does the money leave from? A product that only decrements an in-product unit of credit and compute has not touched your payment instrument at all. A product that can call a payment channel you have linked to it can. The two are described in almost identical marketing language and are not the same order of risk, so what you are looking for is a plain sentence saying which one it is.
Inside our product the sequence is: a delegation is created with a budget written into its contract; each step is priced before it runs; the balance moves only through one settlement path; and the delegation stops itself the moment the arithmetic stops working. Before a step runs, the worst-case cost of that step is estimated and checked twice — once against the budget in the contract, once against the balance actually sitting in the account — so a run cannot burn compute and then discover at charge time that there was not enough. Neither check produces a warning. Both produce a stop.
After the step finishes, its actual cost is reconciled immediately and added to what the delegation has spent. If that pushes the total past the budget, the delegation moves to a waiting-for-authorisation state right there rather than at the end of the run. The difference between the two designs is the difference between finding out you are slightly over and finding out you were a lot over.
How do you know the money really moved? Not from the fact that a call came back successful. A downstream interface returning success means the request was accepted, not that settlement happened. What you want to read is an explicit settled or not-settled state on the transaction itself. A product that cannot show you that state has left you no way to reconcile it, which is a reason to discount its other claims too.
Retries are where duplicate charges actually come from, so they get their own machinery. Every step carries an idempotency key together with a fingerprint of its own content. On a re-entry — a dropped connection, a restarted process, a delegation resumed after being blocked — a key already present in the ledger returns the previous result instead of executing anything again. A key reused while the content behind it has changed is not a re-entry at all; it is rejected as a conflict, because quietly reusing the old result would disguise a different action as one already done.
An audit trail is easy to claim and hard to use. The version worth having is not a log line but an object you can check item by item, and it should answer six things about a single action: who or what performed it, under which permission and autonomy level, what input it was allowed to see, what it changed and how many items it changed, what it cost, and how to undo it. If the step required human approval, the receipt carries who approved it and when. A step whose receipt shows no undo entry is, by definition, not a reversible step — reversibility has to be a returned capability, not a label someone attached to it.
Two structural details decide whether the record is worth anything at all. First, actions taken by a person and actions taken on your behalf go into the same table; keeping two separate tables makes the one comparison you actually want to run impossible. Second, a record that only appears afterwards cannot protect you: when a high-risk step stops for approval, the receipt for it is written at that moment, before anything happens, which is what lets a blocked step be inspected rather than merely reported later.
Most of what circulates as best practice for agent permissions is an organisation chart with an agent drawn into it — approval hierarchies, role matrices, delegated sign-off. For one person with one assistant and one budget, the rules that decide whether any of the above holds are narrower than that, and each one is a question you can put to any product, including this one.
These are the tests that separate a real control from a screenshot of one. Run them against anything that offers to spend on your behalf.
Every gate above has a price, and a page that lists only benefits is not describing a system that exists.
Per-step approval is friction. Delegate something with several outward-facing steps and you will be interrupted several times, and there is no setting that turns it off — which is the point of not building the branch in the first place, because a switch that can be flipped is eventually flipped. The same goes for approval expiry: a task left alone long enough needs re-approval before it can continue, and that is inconvenient by design.
A closed set of executable actions is a limitation before it is a safeguard. The runtime can only carry out actions it actually has an executor for, which is exactly what makes blocking rather than skipping possible, but it also means a plan can contain a step we simply cannot perform, and you get told so instead of getting a result.
Pre-flight estimates are estimates. A worst-case number can stop a step that would in fact have been affordable, so the trade is a run that halts too early against a run that overspends quietly, and we chose the first. When a plan is drafted by the model, the number of items a non-read step will affect is also an estimate, and it is labelled as one rather than presented as a measurement — a computed number that looks like an observed one is its own kind of failure.
When your digital twin acts on your behalf in OneOneTalk, the thing it acts inside is a delegation, and a delegation is an object with a contract: a goal, a definition of done, a preview of what it will affect, an autonomy level, a budget, and the artefacts expected at the end. A missing field keeps it in draft and names the field, instead of starting and filling gaps along the way. While it runs, the gates described above apply — contract incomplete, a high-risk step with no valid approval on that step, over budget, no executor for the step — and each step leaves a receipt you can check item by item. Tiered approval on delegated execution is live, and the approval inbox is in production.
What is not shipped, stated plainly, because on a page about money the boundary matters more than the feature list. The agent wallet — programmable spending caps and allow-lists that would let a twin spend outside the platform — is in development and not available today; nothing above should be read as saying otherwise. One is an in-product credit and compute unit: not a wallet balance, not a cryptocurrency. We do not self-operate regulated payment, stablecoins, or custody of customer assets, and any capability that touches funds is conditional on a licensed partner and on regulators. Payments, legal commitments, deletion of important data and high-risk professional decisions do not enter an automated tier at all.
Two design choices are worth naming because their absence tends to be read as a gap. First, none of this is gated on age checks or age tiers: what an agent may do is decided by the authorisation sitting on the step and recorded in the receipt, not by an attribute of the person holding the account — identity attributes are a weak proxy for risk, and collecting them costs privacy for very little. Second, delegated execution runs inside our own product only. There is no posting on your behalf to outside platforms, and that is a boundary rather than a roadmap item: the artefact is produced here, and moving it somewhere else is a step you take yourself.
More on the product in the English overview.
The public primary material this page is built on. We do not restate their conclusions as our own evidence — they are listed so you can check for yourself.