Thirteen hours. That is how long it took for one stolen enterprise AI key to make about 1.7 million calls to Amazon Bedrock, more than a million of them successful, before someone shut it off. A second stolen key made roughly 800,000 calls over thirty hours. Wiz, which traced both keys back to a breach at an AI developer platform, estimates that the two cases alone likely ran up more than $100,000 in usage at list price. The company that owned the keys paid for every one of those calls, and none of them did any work for that company.
Security researchers call this LLMjacking: stealing the credentials that grant access to AI models and then reselling or consuming that access on someone else’s bill. It used to be a niche threat. In October 2026 it became a pattern, and it changes how finance and security leaders should think about an AI key. A key is no longer just a credential to protect. It is a line of credit, and anyone who holds it can spend from it.
What happened in “Black October”
In a report published October 30, Wiz listed at least nine AI developer platforms that disclosed security incidents during the month, starting with Fireworks AI on October 6 and ending with Northflank on October 30. Wiz found no single vulnerability or dependency linking the incidents, and the root causes vary from credential access to a third-party vendor dependency. What the public reports share is the target. According to Wiz, they all describe attackers “explicitly hunting stored environment variables, with a focus on those granting AI access.” Three of the platforms reported indications of an “agent swarm” attack, and two attributed their incidents to attempts at distillation, which means training another model on a stronger model’s answers.
Railway’s preliminary report is one of the more detailed first-hand accounts. It says the attack ran from October 20 at 13:58 UTC to October 22 at 03:32 UTC, and that early investigation pointed to an attempt “to obtain AI provider API keys to perform distillation attacks.” Railway reported that logs from the attacker’s payloads showed the specific API key names they were searching for, and it recommended that every customer who signed up before October 21 rotate the keys stored on the platform.
How a stolen key turns into a bill
The most useful part of the Wiz report for a finance or AI leader is the timeline of what happened after the theft. In both cases Wiz traced, the first unauthorized use came within 30 minutes of the reported credential access at the vendor: a single model call from a residential IP address, part of a one-minute sweep that tested stolen keys across several organizations. For days afterward, each key saw only a trickle of traffic, between 14 and 120 calls a day, which Wiz reads as a job checking that the keys still worked. Then the volume arrived.
In the first case, four days after that initial test, the attacker probed which models were available, enumerated quotas, and started bulk traffic. The key’s policy allowed global cross-region inference, so the load spread across regions and only about 6% of the roughly 800,000 calls were throttled. About three quarters of the successful calls went to Anthropic’s Opus models, the most expensive tier. In the second case, the key was restricted to US regional inference profiles. The reseller pool first failed thousands of times because it requested global profiles, then found working model IDs and opened the flood. Nearly all of the calls that did not succeed were throttled by the account’s regional quotas.
Wiz describes the usage pattern as resembling resold coding-agent traffic, with many different end users behind a reseller, and it links the keys to two overt LLM resale operations offering discounted access to frontier models. The victims were quietly subsidizing someone else’s AI program.
Why this is a spend problem, not only a security problem
Most organizations still treat AI keys the way they treat any other secret: store it, rotate it on a schedule, and hand it to the security team when something leaks. Black October shows why that is incomplete. A stolen AI key exposes the budget, and the damage compounds by the hour. In our post on Deloitte’s AI cost findings, we noted that only 7% of surveyed CFOs said their organizations respond to failed AI cost controls automatically or in near real time. Put that next to a key that can generate a million successful calls in thirteen hours, and the gap between detection and response becomes the cost of the incident.
This is also why a total AI bill is the wrong unit to watch. A spike on an invoice tells you that something happened weeks after it happened. What you need to know is which key, which project and which owner the spend belongs to, and whether that pattern matches anything the business actually does. This is the signal Olakai was built for. As a vendor-neutral Enterprise AI Intelligence Platform, Olakai attributes AI spend by developer, provider and project, and its Projects feature groups shared service keys into named cost centers with owners and monthly limits. Spend that cannot be tied to a specific person still counts toward program and provider totals but drops out of the person-level views, so a key that suddenly spends on behalf of nobody you can name stands out instead of disappearing into an aggregate.
What actually contained the damage
The most practical lesson in the Wiz report is about what slowed the attackers down, and it was not a dashboard. In the second case, the key’s policy only allowed US regional inference, and the account’s regional quotas throttled nearly all of the calls that did not succeed. In the first case, the key allowed global routing, and only about 6% of calls were throttled. Key scope and provider quotas acted as the hard stop. Both were set up long before the attack.
That points to a split worth making explicit. Provider-side controls, such as key scope, regional restrictions, spend caps and quotas, are what stop a flood in progress. A measurement layer is what tells you which keys exist, who owns them, what normal looks like and when the trajectory is wrong. Olakai budgets are evaluated once a day, right after the cost-import job pulls fresh provider spend, and they fire threshold alerts at 50%, 80% and 100% along with a forecast alert when the run-rate projects past the limit by month end. Those budgets cover per-token, cost-bearing providers such as Anthropic, Cursor and OpenAI. A daily alert will not stop a thirteen-hour flood. It will make sure the morning after is a phone call instead of an invoice three weeks later, and it shows which project and owner the key belongs to so the right person can act. We wrote about the same gap in Uber’s AI budget blowout, where the guardrail arrived only after the money was gone.
What leaders should do this week
If your teams build on any of the nine platforms Wiz lists, the first step is the one every affected vendor has already recommended: rotate every AI provider key stored there and treat the old ones as exposed. Beyond that, a short list covers most of the exposure:
- Inventory every AI provider key in use, including service keys stored on third-party build, hosting and agent platforms, and give each one a named owner.
- Scope each key to the models and regions it actually needs, and set provider-side quotas or caps so a stolen key hits a ceiling.
- Attach every shared service key to a project or cost center so its spend has a baseline and an accountable person.
- Review spend per key at least daily, and decide in advance who is authorized to revoke a key without waiting for a meeting.
- Ask each AI platform vendor how it stores your keys, and how quickly it will tell you when they may be exposed.
For a CISO, this belongs in the same AI risk program that already covers shadow AI and data exposure, because an unknown key is a form of shadow AI with a direct cost attached. For a CFO, it belongs in the monthly AI review, alongside the unit-cost metrics that show whether AI spend is creating value at all. Olakai brings those two views together. The same AI system of record that tells finance what each project returns also tells security which keys exist, who owns them and what they spent yesterday.
Where to start
Pick your three highest-spending AI provider accounts and answer four questions for each one: how many keys are active, who owns each key, what each key is allowed to call, and how long it would take to revoke one at 2 a.m. If any answer requires a search through environment variables on platforms you do not control, Black October is a preview of your exposure. Organizations that can see every key, every owner and every day’s spend in one place will treat the next breach as an incident. Those that cannot will meet it on an invoice.
Talk to an expert about attributing AI spend to every key, project and owner, and setting budgets that alert before a bad month gets worse. Olakai gives finance, security and AI leaders one view of what AI costs, who is using it and what it returns, with AI governance that extends to the keys and vendors your AI depends on.