The bill grows while you sleep Unattended and runaway AI agent incidents
Individuals can also face an overnight bill. Reported incident patterns and practical safeguards
Key takeaway
The previous examples concerned companies, but individuals can also face metered-cost incidents overnight. Reports described about JPY 1.05 million in cloud charges after an agent was left running, and around JPY 2.8 million after a budget setting failed to stop abusive use. The term denial of wallet describes attacks or incidents that exhaust a financial budget rather than merely disrupting a service.
Do not assume a stopping mechanism is enabled
About JPY 2.8 million overnightA reported API-key-leak bill, despite an AUD 10 budget setting
The two cases highlighted missing or ineffective limits, timeouts, and budget controls, including settings that only notify rather than stop spending.
Incident 1: an agent kept running, with about JPY 1.05 million in 24 hours
A case covered by GIGAZINE on June 15, 2026 involved an engineer using an AI agent to investigate an experimental network. The agent provisioned high-performance servers on AWS for the work. When progress did not go as expected, it kept adjusting the configuration while leaving the infrastructure running. Around 24 hours passed before the operator stopped it.
The resulting charge was about USD 6,531, reported as approximately JPY 1.05 million. It was reportedly reduced after discussion with the provider to about USD 1,894, or roughly JPY 300,000 in the report. The operator's technical blog describes the sequence. The point is not simply that the agent broke: it kept adding resources and trying to meet its goal. That persistence became a bill under metered infrastructure pricing.
Incident 2: an AUD 10 budget setting, then about JPY 2.8 million overnight
Tom's Hardware reported a case involving an AI consultant whose API key remained exposed in an old public development project. A third party found it and sent more than 60,000 AI requests overnight. The resulting charge was around AUD 25,672, approximately JPY 2.8 million.
The user had set an AUD 10 budget. According to the report, a billing threshold could increase automatically as spending grew, and the setting did not function as a hard spending cap. The report also discussed multiple safety features that were disabled by default. The provider ultimately canceled the charge. It is fair to include that the provider offered relief, without assuming similar relief would always be available.
These incidents are sometimes described as denial of wallet: consuming billable resources to drain the owner's budget, rather than simply taking a service offline.
Safeguards to check before leaving an agent running
- Check what the budget control actually does. Does it stop usage or only send a notification? Can a billing threshold automatically increase?
- Review API keys regularly. Remove unused keys, keep secrets out of source code and public pages, and minimize permissions and validity periods.
- Give agents stopping conditions and spending ceilings, enforced by system controls as well as instructions. Include a limit such as stopping and reporting after a set number of failed attempts.
- Configure daily usage-cost reporting. Monthly invoices are too late for early detection; a next-day signal is a useful safeguard.
- For overnight or weekend work, also use a time limit, independent of the spending threshold.
An alternative: run local inference without a token meter
These controls are useful, but they still involve watching a meter that can otherwise keep running. Where billable resources remain available, a missed control can let costs accumulate.
An upfront-purchase on-premises system such as Sovereign GaiXer has no local per-token meter. Repeated local inference or a loop therefore does not itself generate a cloud token bill; electricity and other operating costs remain. The financial difference can be significant in agent workflows. This does not eliminate harmful actions, leaked local credentials, or charges from external services the agent can access. Keep agents appropriately restricted and manage credentials; see article 7.
Imagine a tap that can be left running. In these examples, it may also be opened from outside through a leaked key, operated persistently by a robot, and lack an enabled shutoff. Add effective stopping controls, or use local inference without a usage meter where appropriate. External tools and billable infrastructure still require their own controls.
Frequently asked questions
These are individual cases. Are they relevant to companies?
Yes. Companies often have more API keys and agents, creating more opportunities for forgotten jobs or exposed credentials. The prolonged usage in article 16 shares the same cost dynamic.
Is the cloud provider to blame?
The cases do not support a one-sided answer. Providers reportedly reduced or canceled charges. At the same time, default-disabled safeguards and thresholds that increased were criticized as contributing factors. The practical lesson is to understand and configure controls rather than rely on defaults.
What should we do if a large bill has already arrived?
Stop the source of spending by disabling compromised keys and stopping affected resources, while preserving relevant incident records. Contact the provider's support team to investigate and discuss possible relief. The examples received reductions or cancellations, but relief is not guaranteed.
What conditions make denial-of-wallet incidents easier?
Common factors include a key exposed in a public repository or URL, missing request limits, and access to expensive models. Good key management and enforceable request limits reduce the risk.
Is running agents overnight itself a mistake?
No. Overnight automation is a promising use case. The risk comes from unattended access to open-ended metered resources. Use enforceable time and spending controls, and consider fixed-cost local inference for suitable work.
Does on-premises deployment eliminate incidents?
No. It removes the local per-token billing mechanism, but electricity, resource contention, external-service spending, and harmful agent actions remain possible. Stopping conditions, permissions, and operational safeguards are still essential.
Summary
- Reports described about JPY 1.05 million in unattended-agent cloud charges, reduced to about JPY 300,000, and about JPY 2.8 million after a leaked key, later canceled.
- Denial of wallet describes a recognizable risk at the intersection of metered services and automation.
- A recurring problem is assuming a stopping mechanism exists by default; a budget alert may only notify.
- Useful controls include enforceable spending limits, key management, stopping conditions, timeouts, and timely usage reporting.
- Running suitable inference locally without a token meter changes the billing risk, but does not remove other financial, operational, or security risks.
Related articles
The issue reached Japan too One employee, JPY 10 million in monthly AI usage
The US cases were not a distant problem. Lessons from a domestic case reported by Nikkei
Security and contracts
What to check before considering price
The day an AI bill exceeds a human salary
AI spending is moving from a tool budget toward a staffing-scale decision. A new yardstick for reported costs and forecasts
This article is based on public reporting and public blogs, without independent interviews. It avoids identifying private individuals. Yen figures are approximate conversions used in the cited reporting; the source examples may use different exchange rates. Please contact us with factual corrections. The media, researchers, and companies discussed do not endorse Sovereign GaiXer.
Company, product, and service names mentioned are trademarks or registered trademarks of their respective owners.