How to Stop an AI Agent From Spending Your Money
Write the rule into the agent's standing contract file, not into chat: every expense, any amount, needs your explicit approval first. The agent never buys. It proposes the purchase to a mailbox file with a reason, then keeps working on something else while it waits for your yes.
That is the whole fix, and it is deliberately boring. Most people reach for a dollar cap instead ("you may spend up to $20 a month"), which feels safer and is actually weaker. A cap still hands the agent a wallet. The version that works takes the wallet away entirely and replaces it with an outbox. Below is exactly where that rule lives, why chat is the wrong place for it, and what the agent does with a spending idea when buying is off the table.
A spending guardrail is a written rule in the agent's contract that turns every purchase into a request for a human, so the agent can want to spend money but cannot actually do it alone. The want is fine and even useful. The doing is what you keep for yourself.
Where do you write the rules so they survive?
You write them in the agent's standing contract file, the one it reads at the start of every session, not in a chat message. In Claude Code that file is CLAUDE.md; other tools have an equivalent. A rule typed into chat lasts exactly as long as the conversation. A rule in the contract file is re-read on every startup, so it survives the thing that makes agents dangerous in the first place: they forget.
This is the point people miss. An AI agent has no memory between sessions. Whatever safety you established by talking to it yesterday is gone today unless it was written to a file the agent reloads. A spending limit that exists only in a past conversation is not a limit at all. It is a limit the agent has already forgotten. The contract file is the only place a rule outlives the session that created it.
Our own rule, copied almost verbatim from the contract we run: spending money in any form (domains, ads, subscriptions, API credits) requires the owner's approval; ask through the mailbox and work on something else meanwhile. No amount is too small to skip the step. A five-dollar charge goes through the same gate as a five-hundred-dollar one, because the discipline is about where the line is, not where the pain is.
What does the agent do instead of buying?
Instead of buying, the agent runs three moves: propose, park, proceed. It writes the request to an inbox file we call FOR_HUMAN.md, marks the blocked task as waiting, and immediately picks up the next unblocked task. Nothing stalls and nothing gets bought.
- Propose. The agent writes to the mailbox what it wants, why, how urgent, and its recommendation. A real entry looks like: "Need: domain for the site, roughly $12/year. Why: cleaner brand than the free subdomain. Urgency: low. Nothing else is blocked meanwhile."
- Park. The blocked task waits in the backlog with a marker. It is not abandoned and not forgotten; it is holding for one word from you.
- Proceed. The agent takes the next task that is not blocked. A purchase it cannot make is never a reason to sit idle.
Your side takes seconds: read the proposal, reply "yes," "no," or "yes, but keep it under X," and that answer gets recorded so the same category of request does not come back. The mailbox turns a scary open-ended risk ("what might it buy?") into a short, reviewable queue you clear on your own schedule.
Why we rejected a standing spending limit on purpose
Early on we considered giving the agent a pre-approved monthly budget so small purchases could flow without interruption. We rejected it, on purpose, and wrote the decision down. A standing limit optimizes for the agent's convenience at the cost of the one thing that matters here: a human seeing each real-world commitment before it happens.
The math also does not favor it. Reviewing a spend proposal costs you under a minute, and small purchases are rare in a well-run operation, so the "friction" a budget removes is almost nothing. What a budget adds is a standing pool of your money the agent can draw on while you are asleep, based on judgment that no current model should be trusted to exercise unsupervised. We kept the pool at zero. Every expense knocks, every time. This sits inside a broader guardrail system where reversibility, not dollar amounts, decides what needs a signature.
FAQ
Aren't spending limits in the prompt enough?
No, because agents have no memory between sessions. A limit you type into chat is forgotten the moment that conversation ends, so tomorrow's session runs with no rule at all. Safety has to live in the file the agent reloads at every startup, the contract file, not in a message. A rule the agent forgets is not a rule.
What about free trials that auto-charge later?
Treat starting a trial as spending money, because it is a future charge you have already agreed to. The same rule applies: the agent proposes the signup through the mailbox and waits, rather than starting the trial on its own. Auto-renewing trials are the most common way a free action quietly becomes a bill, so they belong firmly on the ask-first side of the line.
How does the agent actually propose an expense?
It appends an entry to the mailbox file with four things: what it wants to buy, why, how urgent it is, and its recommendation. It then marks the task as blocked, picks up other work, and does nothing about the purchase until you answer. You reply in the same file with yes, no, or a condition, and that decision gets logged so the next similar request is faster to clear.
Can the agent still do useful work while it waits?
Yes, and that is the point of the park-and-proceed step. A blocked purchase never idles the agent; it moves to the next unblocked task in the backlog. In practice most spend proposals sit in the mailbox for hours or days while the agent keeps shipping everything that does not require your money, so the guardrail costs you almost no throughput.