An AI agent burned $6,531 in 24 hours. The defaults were simple: no spending limit and broad access to the systems around it.
People describe incidents like this as surprises. They should not be. An agent with an unrestricted key is not a clever assistant waiting to become useful. It is a program with permission to spend money, call services, and keep trying after the person who started it has gone to bed.
The key is the decision
Teams often talk about the prompt as if it were the important part. They spend time tuning the instructions, choosing the model, and adding a few guardrails to the system message. Those things matter. The API key matters more.
The key decides what the agent can reach. The billing account decides how much damage it can do. If both are unlimited, the agent does not need malicious intent to create a large bill. A retry loop is enough. So is a tool that returns an error and gets called again. So is a task that quietly expands because every new step looks reasonable in isolation.
This is the uncomfortable part of autonomous software: the failure can be perfectly ordinary. No one has to jailbreak the system. No one has to steal the credential. The agent can follow its instructions, encounter a confusing result, and continue doing exactly what it was asked to do.
Why unlimited feels normal
Unlimited access is convenient during a prototype. It removes friction. You do not have to stop and configure quotas while you are still figuring out whether the idea works.
Then the prototype becomes a tool. The tool gets a wider prompt, a production credential, or a scheduled job. The temporary permission becomes permanent because nobody owns the cleanup. By the time finance notices the bill, the original experiment has turned into infrastructure without the controls infrastructure normally requires.
There is also a social reason this keeps happening. Nobody wants to be the person who slows down an exciting project by asking for a spending cap. Nobody wants to explain why a coding agent needs a separate account, a narrow role, and an approval step when the demo worked perfectly yesterday.
But a cap is not an insult to the agent. It is a way of stating what the experiment is allowed to cost.
Make the blast radius boring
Give every agent its own credential. Limit the services it can call. Set a budget that produces an alert before it becomes a postmortem. Put expiration dates on experimental access. If the task needs a human decision, make the agent stop and ask for one.
These are not exotic controls. They are the ordinary habits of operating software that can affect money or production systems. The strange thing is how quickly teams abandon them when the software is described as an assistant.
The word assistant does useful social work. It makes a process with credentials feel like a colleague. Colleagues do not usually come with a spending limit in the configuration file, so the limit gets left out. The configuration file does not care what we called the process.
If an agent can spend, deploy, delete, or create more work, treat its key like a loaded weapon with a billing account attached. Give it the smallest permission that lets the experiment run. Give it a budget. Give it a shutdown path that does not depend on someone noticing the problem in time.
An unlimited agent key is a naked call: a bet with no protection around it. Sometimes the bet pays off. That is not a reason to pretend the downside is theoretical.