They spend your money until you notice, and there is no chargeback. Here is what the numbers actually look like and the twenty-minute setting that caps the damage.
The Hook
Between 4:07 and 5:21 in the morning, UTC, on October 21, 2026, somebody sat inside a hosting company's production database running queries that looked for one specific thing.
Not customer records. Not credit cards. Not source code, though they had already taken that.
They were looking for environment variable names that matched the pattern of AI provider keys.
The estimated bill from what they found: about $740,000 in unauthorized AI spending, belonging to customers who had never heard of the attack and would not for another day.
Here is the direct answer to the question. If someone steals your AI API key, they will resell access to it or burn it on their own workloads, and the charges land on your account at a rate no human spending pattern can match. There is no chargeback mechanism. Whether you get your money back depends entirely on which provider issued the key, and the terms range from automatic fraud coverage to a case-by-case review to a flat no-refund policy. The only control that actually limits the damage is a hard monthly spend cap plus a usage alert, because this attack arrives as a bill rather than an outage, and a bill does not interrupt your day until the statement does.
That setting takes about twenty minutes to configure across every provider you use. Most business owners have never opened the page.
Key Takeaways
- Railway disclosed that stolen customer AI keys produced an estimated $740,000 in unauthorized usage charges, with variables decrypted for at most 1.85% of workspaces, which it rounds to about 100,000 as an upper limit rather than a confirmed count.
- Refund outcomes differ wildly by provider, from automatic fraud coverage at AWS Bedrock and Google Gemini, to case-by-case review at OpenAI, to a standing no-refund policy at OpenRouter.
- Google Threat Intelligence and Mandiant call this LLMjacking and report single incidents exceeding $100,000 in a day, with cumulative charges reaching $1 million at some organizations before access was revoked.
- Wiz, writing on October 30 2026, counted breaches disclosed by at least nine AI developer platforms that month, with further disclosures appended since, and reports that every public account described attackers hunting stored environment variables with a focus on those granting AI access.
- Verizon's 2026 breach impact study, produced with CyberAcuView, puts the median impact for the small business segment, defined as under $25 million in revenue, at approximately $38,000 across 15,431 claims, which is the realistic scale of a small business incident.
The Problem
You have an AI key in at least three places you cannot name right now.
I am not guessing. Here is the usual inventory, and you will recognize most of it. One in your automation platform. One a developer put in a project months ago. One in a plugin you installed and forgot. One in a document you sent a contractor in 2025. One in a screenshot. Possibly one in a settings file sitting in a folder on your laptop.
Every one of those is a payment instrument. Not a password. A payment instrument, with your card behind it and no spending limit on it.
The reason this feels abstract is that every security conversation you have ever had was about data. Somebody takes your customer list, your files, your email. You know what that disaster looks like. You have insurance language for it.
This is a different shape entirely. Nobody takes anything you would miss. Your business keeps running perfectly. The website is up, the orders come in, nothing is encrypted, nobody emails you a ransom note.
And then the statement arrives.
Candidly, I spent two years telling people to scope their AI credentials and never once said the word "cap." I was solving the permissions problem, which is real, while the actual loss mechanism sat in a billing settings page I had not opened.
But what if the thing you are protecting is not your data at all? What if it is your card?
The Evidence
Five hard numbers, each from a named source, and they stack into a picture.
One. The Railway incident, because it is documented in unusual detail.
Railway is a platform that builds and runs applications for customers and stores their secrets, API keys and database credentials, as environment variables. Its full incident report, covered on November 11, 2026, lays out the chain.
At 07:28 UTC on October 20, an attacker exploited a previously unknown flaw to partly escape the filesystem isolation around a build and read files on the host machine. That produced a credential meant only for build work. Railway's internal workflow system accepted it as a trusted client anyway, which let the attacker read stored build histories and pull a cached copy of the company's internal monorepo. With the code in hand, the attacker found a misconfigured identity binding in a cloud environment, used it at 03:26 UTC the next day to obtain a cloud credential, took two more from there, and reached a machine holding the credential that decrypts customer variables.
Between 04:07 and 05:21 UTC they pulled encrypted variables, searching for AI provider key names. They decrypted some between 04:42 and 05:14, and again between 06:36 and 07:15. They were fully removed at 09:24 UTC.
Twenty-six hours from first exploit to removal. Estimated damage: about $740,000.
Three caveats Railway states itself and most coverage dropped. The roughly 100,000 workspace figure is an upper limit, because Railway's logs show which environments were exposed but not which variables. The $740,000 is Railway's estimate, and the report does not say how it was calculated or what period it covers. And linked-account tokens for 1,852 users were exposed, including GitHub tokens and agent keys, all of which were reset with no unauthorized logins found.
Two. Who pays, which is the part that should change your behavior.
Railway's published refund terms are the single most useful document a small business owner could read this month, because they are a map of your exposure by vendor. AWS Bedrock and Google Gemini cover fraud under existing policy and started refunds. OpenAI reviews case by case. OpenRouter maintains its no-refund policy in its terms of service. Anthropic was still in discussion when the report published, with Railway covering the cost in the meantime.
Railway's initial position on October 26 was that it "is unable to refund customers for spend performed with compromised API keys," and it later committed to covering what providers decline. Give them credit for the reversal. Then notice that you do not have a Railway. Nobody is going to absorb your bill on principle.
Three. This has a name and a market.
On November 2, 2026, Google Threat Intelligence Group and Mandiant published research on what they call LLMjacking. Their framing: "Unlike the gradual resource consumption associated with cryptojacking, LLMJacking can generate large spikes in fraudulent cloud charges in a matter of hours." They observed fraudulent charges exceeding $100,000 in a single day, with cumulative charges at some organizations reaching $1 million before access was revoked.
There is a resale layer. Google describes operators they call LLM Mixers, which proxy, aggregate and resell unauthorized access through underground storefronts, and names one offering an unlimited token plan with alleged frontier-model access for roughly $60 a month. Somebody is selling access to your quota for sixty dollars.
Four. It is a pattern, not an incident.
Wiz researchers, writing on October 30, 2026, listed Railway's breach among incidents disclosed that month by at least nine AI developer platforms, a stretch they call Black October. Nine is a floor rather than a total, and Wiz has appended further disclosures since. Their finding is the one to remember: every public report describes attackers hunting for stored environment variables, especially ones that grant AI access, and no single flaw or shared software dependency links the attacks.
That means this is not a bug waiting to be patched. It is a target class.
Five. And the leak does not require a breach at all.
On November 5, 2026, the security firm Apiiro reported that when a developer selects "Yes, and don't ask again" in Claude Code, the tool can save that exact approved command, secret included, into a project settings file in plain text. Apiiro found 104,185 copies of that file across 103,617 public GitHub repositories, with 1,122 of those files, spread across 1,105 repositories, holding at least one secret. Be careful with the next two numbers, because most coverage merged them. Those current files alone hold 1,379 distinct secrets, and the breakdown belongs to that figure: more than a third open a database directly, including 379 database passwords, plus 122 Supabase service-role keys, 43 SSH logins, 42 source control tokens and 23 AWS keys. Widen the scope to older file versions, the shared settings file and saved agent chat logs, and the total reaches 2,539 secrets across 1,994 repositories. As of that Monday every file with a secret was still on its repository's default branch, and in half of those repositories it had been there for at least 217 days.
Apiiro did not test whether the secrets still worked, though one company it notified confirmed its key was live.
Two hundred and seventeen days. That is seven months of a key sitting in public, in a file nobody thought of as a file.
The Solution
Here is how this works together, because the answer is three controls and most people only have one.
Permission controls limit what an agent can do. This is the advice everyone gives, and you should follow it: a separate key per tool, the narrowest scope that lets it work, so revoking one does not take your whole business offline. It is good advice and it is not sufficient, because a key scoped perfectly to "generate text" can still generate $740,000 worth of text.
Spend controls limit what a key can cost. This is the one nobody mentions and the only one that caps the damage from a theft you have not noticed yet. A hard monthly limit on the account and an alert threshold beneath it. The alert tells you something is wrong. The limit decides how wrong it gets.
Visibility controls tell you what normal looks like. A spike is only visible against a flat line, and almost nobody has looked at their flat line. Two minutes a week reading one number per provider is the entire practice.
Three controls, and they stop different disasters. Permissions stop an agent doing something stupid on your behalf. Spend caps stop a stranger spending your money. Visibility is what turns a monthly surprise into a same-week catch.
Here is what I found when I ran this on my own setup, and it is mildly embarrassing for somebody who teaches this. We had the permissions work done properly: separate keys, narrow scopes, documented. We had no spend cap on two of four providers. And I could not have told you, within a factor of three, what we spend on AI in a normal week, because I read the invoice as a total and never the detail.
Twenty minutes fixed the caps. The baseline took another ten. The thing I cannot get back is the eighteen months where a stolen key would have run until the statement came.
Practical Steps
1. Set a hard monthly cap and a usage alert on every provider, today. This is the twenty-minute job and it is the whole point of the article. Pick a number using your actual data: your normal monthly spend, your busiest month ever, and the amount that would genuinely hurt. Set the cap above the busiest month and below the painful number. Set the alert at your normal spend plus about half. Where a provider offers no cap, write that down, because it changes how much you should run through them.
2. Go look at today's usage so you know what normal is. Open each dashboard and write the number down with the date. This is your baseline. Without it, every future number is meaningless and you will either panic at a normal Tuesday or shrug at a theft.
3. Inventory every key you have ever created, including the ones you are unsure about. Use this:
[The Job]
Help me inventory every AI API key and credential my business has created.
This is for: me, finding out what I am actually exposed to.
It matters because: I cannot revoke a key I have forgotten exists.
[The Background]
Here is what you need to know: the AI providers I pay are [LIST THEM]. The tools and automations connected to them are [LIST EVERYTHING: AUTOMATION PLATFORMS, PLUGINS, SCRIPTS, HOSTING, CONTRACTORS]. Who else has access is [LIST PEOPLE]. Where I think keys are stored is [DESCRIBE].
Do not use: generic security advice. Build the inventory from my list.
[The Deliverable]
Return: a table of each key, where it lives, what it can spend, and who can reach it.
Must include: a row for "I am not sure," because that is the most dangerous category.
Optimize for: accuracy.
[The Questions]
Ask me any questions you have.
4. Rotate anything that has ever been pasted into a document, a chat, or a screenshot. Rotate first and clean up second, which is the order Apiiro's researchers recommend, because deleting a file does not undo a leak that is already in a history or a copy. Rotate the ones that reach money or customer data first.
5. Read your providers' refund terms before you need them. Not after. The Railway disclosure proves these differ enormously and that nobody reads them in advance. For each provider, find out what their terms say about fraudulent or unauthorized use, and if you cannot find it, email their support and ask for the answer in writing. Rank your providers by exposure and notice which one you run the most money through.
6. Write the six-step incident plan while nothing is wrong. Revoke, rotate, report to the provider, open a claim, notify anyone affected, and reconcile. Decide the order now, including what breaks when you revoke each key, because that decision made calmly on a Tuesday is worth ten times the same decision made in a panic.
7. Put a two-minute spend check in your week, in a slot that already exists. One number per provider, compared to your baseline. If it is outside the range, you investigate. That is it. Attach it to something you already do without fail, because a practice with its own calendar entry dies in February.
Frequently Asked Questions
Is this really a risk for a small business, or only for platforms?
Both, and in different ways. The platform breach is where the keys get stolen in bulk, which is out of your control. But your own exposure is entirely in your control, and the realistic scale of a small business incident is well documented: Verizon's 2026 breach impact study, produced with CyberAcuView from roughly 70,000 US cyber insurance claims, puts the median impact for the small business segment, under $25 million in revenue, at approximately $38,000 across 15,431 claims. These are insured losses only, which the authors describe as floors rather than ceilings. That is not $740,000. It is also not nothing.
Will my credit card company reverse fraudulent AI charges?
Do not plan on it. These are legitimate charges from a vendor you have a real account with, incurred by a credential you issued. That is why the provider's own fraud policy is the thing that matters, and why those policies differ so much from one provider to the next. Find out which kind yours is before you need to know.
Does setting a spend cap risk breaking my business mid-month?
It can, which is why the number matters. Set it above your busiest month ever, not above your average. And set the alert well beneath the cap so you get a warning rather than a wall. A cap that trips once a year and costs you an afternoon is cheaper than one theft.
What is the single most likely place my key is leaking right now?
Based on this week's research, a settings or configuration file you do not think of as a document. Apiiro found 1,122 public copies of one AI tool's local settings file containing live-format credentials, and in half of the affected repositories the file had been sitting there for at least 217 days. After that, a message to a contractor and a screenshot.
Should I stop using AI tools over this?
No, and that would be the wrong lesson. The lesson is that AI spend behaves like a payment method rather than a software subscription, so it needs the controls you already apply to a company card: a limit, an alert, and somebody looking at the statement. You would not hand out a card with no limit. This is the same decision.
The Close
Twenty-six hours. About $740,000. Keys found by searching a database for names that looked like AI providers.
Here is the thing that keeps me up about this one, and it is not the number.
For most of the threats you have ever been warned about, you find out because something stops working. The site goes down. The files are locked. Somebody calls you. The disaster announces itself and you start responding.
This one does not announce itself. Your business runs perfectly while it happens. Orders come in, the phone rings, the team works, and somewhere a stranger is renting your quota to other strangers for sixty dollars a month. You find out on a statement, which means you find out in the worst possible condition: weeks late, with no ability to reconstruct what happened, and with a vendor who reviews these case by case.
Every security habit you have was built for a disaster that interrupts you. This one does not interrupt you. It bills you.
So go open the billing settings page on every AI provider you pay. Set a number you could survive. Set an alert at a number that would make you look. Then write down today's usage so that future you knows what a normal Tuesday looks like.
Twenty minutes. There is no chargeback, so the limit is the only thing standing between a theft and your bank account.
About the author
Jonathan Mast is the founder and CEO of White Beard Strategies, where he teaches non-technical entrepreneurs how to use AI to amplify the skill and experience they already have. He runs a community of more than 500,000 entrepreneurs, created the Perfect Prompt Framework 2.0, and speaks regularly on practical AI adoption for small business. He has been through bankruptcy once, which is a very thorough education in reading a statement before it reads you.
Sources
- Railway says stolen customer AI keys led to $740,000 in estimated unauthorized usage charges, The Hacker News, Nov 11 2026
- Railway incident report, October security incident
- Railway breach leads to $740,000 in fraudulent AI charges, BleepingComputer
- Black October for AI developer platforms, Wiz
- Google warns LLMjacking attacks are costing some enterprises up to $1 million in cloud charges, The Hacker News, Nov 3 2026
- LLMjacking: monetizing compromised cloud models, Google Cloud Threat Intelligence and Mandiant
- Claude Code's "don't ask again" file exposes passwords and keys in 1,122 public copies on GitHub, The Hacker News, Nov 7 2026, covering Apiiro research published Nov 5
- Coding agents leaking secrets on GitHub, Apiiro research
- 2026 Breach Impact Study, Verizon with CyberAcuView
- United Airlines bans AI agents from booking flights on behalf of travelers, CBS News, Nov 11 2026