Money is propose-only by construction
Declaring an execute tool on refunds, payments or stock throws when the tool map is built. The store does not start, so the mistake never reaches production.
The assistant sees orders, customers, stock and reviews, because they are tables in one database rather than four products. What it may do with them is a separate question, and the answer is set in code.
Most assistants are given a credential and a prompt telling them to be careful. A prompt is not a boundary. The first time one is talked into a refund it should never have made, the instruction that was supposed to stop it is the thing that failed.
Refund order #4821 in full — the customer says it arrived broken.
A card appeared in the admin. Nothing moved until someone clicked it.held for approval
The default. Tools that answer questions run inside the loop and return data.
A tool that would change something writes a proposal and a signed approval token instead.
Only ever reached by an operator approving the card. The model has no path to it.
Declaring an execute tool on refunds, payments or stock throws when the tool map is built. The store does not start, so the mistake never reaches production.
Approval runs the canonical action directly. There is no token the model can mint for itself and no second prompt it can satisfy on its own.
The run ledger keeps what was suggested and refused, not only what was approved — so a review shows what the assistant has been trying to do.
The same tool kit is reachable over MCP with a scoped key, so an outside assistant gets exactly the surface the admin has — including the part where a change only ever becomes a card. Turn the provider off and the AI screens hide rather than half-work.
Read tools answer. Everything else waits for a human.