Fireworks AI Breach: An Inference-Provider Risk Checklist After the LLMjacking Incident

The Fireworks AI breach is one of the clearest recent cases of risk moving through a hosted inference provider and landing on its customers. In October 2026, Fireworks AI disclosed a security incident. A follow-up update then described a second intrusion and a wider impact.

Below is what Fireworks has actually published, followed by a response plan we call the Secrets, Data, Spend playbook. After that comes a due-diligence checklist for future vendor reviews.

What Fireworks has disclosed: two intrusions, in order

Fireworks has published an initial security bulletin and a follow-up update. Read side by side, they describe two separate intrusions.

The first incident, identified on October 6, involved unauthorized use of internal Fireworks credentials. According to the initial bulletin, an unauthorized third party accessed environment variables used in evaluation jobs in a limited number of customer accounts.

The second came in through a supplier. A third-party cloud provider that hosted Fireworks R&D machines had a security incident on October 23. A day later, on October 24, the attacker used that access to reach Fireworks development machines and run an unauthorized workload, which led to additional customer data impact.

The update also changed the picture of what was taken. When the first bulletin went out, only secrets stored with Fireworks were known to have been accessed. Further investigation found impacts to account and billing information, and for a limited set of accounts, impacts to secrets, datasets and incomplete models.

On attribution, the company cites evidence tying the activity to a financially motivated cybercriminal group that sells tokens from unauthorized LLM access to illicit routing gateways, a practice it calls "LLMJacking."

There is still a hole in the record. According to The Register, the update did not say how many customers either attack affected. Until Fireworks says more, confirm your own exposure with the vendor directly.

What was exposed, what was not, and what Fireworks changed

In the first incident, Fireworks believes that environment variables, including API keys and tokens stored as secrets, were captured in certain affected accounts. A secret in a job environment is rarely interesting on its own; its value lies in what it unlocks elsewhere.

The exposed billing information included billing and shipping addresses, invoice and payment history, account balance and credit usage. Payment card numbers are different: the company states that it does not store them and that they were not affected.

On model weights, CEO Lin Qiao told The Register that the attackers did not appear to be after weights and that most downloads were partial and stopped. Treat that as the vendor's own assessment, not an independent finding.

The impact travels downstream as well. Notion, a Fireworks customer, told affected users that their workspaces were among the under 1 percent of Notion workspaces that may have been affected by the Fireworks incident.

The product has changed in response. Self-serve dataset uploads and downloads used by Batch Inference and dataset-based training have been disabled during the investigation. The fine-tuning documentation now says evaluators and evaluation jobs have been removed. That is the same feature whose environment variables were exposed in the first incident.

Why LLMjacking turns a leaked key into a large bill

LLMjacking is the theft and resale of access to model inference.

The Google Threat Intelligence Group reports that across multiple investigations of what it calls "LLMJacking," the dominant initial access vector has been exposed or stolen cloud identity tokens. These include IAM credentials, service account keys, GitHub personal access tokens and active session tokens. Notice how much wider that list is than model API keys. For defenders, that is the main point.

Google describes "LLM Mixers" as illicit routing gateways that proxy, aggregate and resell unauthorized LLM access to underground subscribers. One service, Jet Night, offers an unlimited token plan for about $60 per month with alleged access to frontier models, while that level of consumer service would typically cost between $100 and $250 per month.

Someone pays the difference, and it is the victim. In the incidents Google describes, fraudulent charges exceeded $100,000 in a single day, and cumulative charges at some organizations reached $1 million before access was revoked. In one case, a threat actor made more than 500,000 LLM API calls in under eight hours, using stolen third-party API keys to power Jet Night, and the service passed nearly $1 million in token costs to the victim organization.

Earlier research points the same way. Sysdig's original 2024 analysis estimated that an undiscovered attack could cost a victim over $46,000 per day in LLM consumption. Later Sysdig research said this rose nearly threefold to over $100,000 per day with top-tier models such as Claude 3 Opus.

The Secrets, Data, Spend playbook for hosted-inference customers

These seven steps apply to this incident and to the next one like it, whoever the provider is.

Secrets: what you handed over

Step 1: Inventory every stored secret. List each secret stored with the provider, paying particular attention to environment variables attached to evaluation, batch or training jobs. Since API keys and tokens stored as secrets were captured in certain affected accounts, treat any secret in scope as compromised until proven otherwise.

Step 2: Rotate at the source. Revoke and reissue each third-party credential with the provider that issued it. The vendor is explicit: removing a stored secret alone does not invalidate the underlying credential, and third-party credentials require action with their issuing providers. Over the longer term, keep raw keys out of job runtimes altogether. Teams may want to consider a credential proxy for this; see our guide to credential proxies for AI agents.

Step 3: Scope the blast radius. For every rotated key, write down what it could reach (cloud accounts, repositories, databases, other model APIs) and review those systems' logs for activity after the exposure window. Give cloud identity tokens and GitHub tokens the same priority as model keys; in Google's investigations they were the most common way in.

Data: what you uploaded

Step 4: Review datasets and models. Work out which datasets, fine-tune jobs and incomplete models lived on the platform. Then decide whether any of that data triggers customer, contractual or regulatory notice. Involve legal counsel early.

Step 5: Adjust affected workflows. Plan around the paused dataset features for Batch Inference and dataset-based training. Decide whether you will re-upload data once the features return or keep it in your own environment from now on.

Spend: what you watch

Step 6: Brief finance on billing exposure. Leaked addresses, invoice history and balances give a fraudster useful detail for a believable phishing email or fake invoice. Ask finance and accounts payable to confirm any unexpected payment request or banking change through a channel they already trust.

Step 7: Cap and alert on every remaining key. Set per-key spend alerts and hard caps, both at the provider and in your own cloud billing. Route them to an on-call channel, not a shared inbox nobody reads at night. The monitoring section below covers which signals to watch.

Whatever the group, log each decision with a timestamp and an owner.

Who owns each step

Use this as a starting default. In a small team one person may cover several roles. What matters is that every step has a named owner.

Where zero data retention applies and where it does not

According to Fireworks' data handling documentation, Fireworks has zero data retention (ZDR) by default, which means it does not log or store prompt or generation data for any open models without explicit user opt-in. Its ZDR policy page adds a caveat: a few features do store customer content, such as stored responses, batch jobs and training.

Look at what the breach actually touched: stored content, in the form of datasets and incomplete models, plus secrets, which ZDR was never meant to cover. A ZDR default is worth having for real-time inference. It is not a promise about everything you send. We suggest checking the retention settings of every provider you use rather than assuming they match; our guide on Gemini API request storage is a related read.

In practice, label every workload as either inference only or stored content. For batch or fine-tuning uploads, strip fields the model does not need, redact personal data where you can, and keep the master copy in your own environment.

Vendor due-diligence checklist: questions to ask any inference provider

Bring these to procurement reviews, renewals and security questionnaires. Each one comes out of the Fireworks timeline or the broader LLMjacking pattern.

• [ ] Secrets handling: Where are customer secrets stored, who can read them, and do job runtimes receive them as plain environment variables?
• [ ] Supply chain: Which third-party clouds host R&D or development machines, and how are they isolated from customer data?
• [ ] Retention map: Which features store customer content? As the section above shows, this varies by feature, so get the answer in writing.
• [ ] Incident communication: Will the provider disclose how many customers were affected, and how will updates reach you?
• [ ] Feature lifecycle: When a feature is retired, as evaluators and evaluation jobs were here, how are its secrets and data purged?
• [ ] Billing controls: Can you set spend caps, per-key quotas and anomaly alerts that reach an on-call channel?
• [ ] Credential scope: Can keys be limited to specific models, projects or environments, and rotated without downtime?
• [ ] Logging access: Can you see who read your secrets and when?

Good answers will not make the risk go away. Teams routing traffic across several providers may also want routing and budget controls at the gateway layer; see our AI gateway playbook.

Monitoring for LLMjacking: signals that can appear before the invoice

LLMjacking tends to be noisy. Its signals often show up in usage data well before the bill arrives, as long as someone is looking.

• Volume bursts. Sysdig detected more than 85,000 requests to the Bedrock API in one campaign, and 61,000 of them came in a three-hour window on July 11, 2024. A spike like that should page someone.
• Rate anomalies. The Jet Night case, more than 500,000 calls in under eight hours, is likely far above anything your keys normally do. Alert on large deviations from each key's usual rate. OpenTelemetry GenAI tracing is one way to collect the usage data you need for that baseline.
• Spend thresholds. The hourly or daily caps from Step 7 limit damage at the daily scale Google reported. A monthly review cannot.
• Unusual patterns. Watch for calls to models you do not normally use, new regions, unfamiliar source IP addresses and activity at odd hours.
• Identity, not only keys. Treat any stolen cloud identity token as a possible LLMjacking entry point.

This trend did not start with Fireworks. Sysdig reported a 10x increase in LLMjacking requests during July 2024, and twice as many unique IP addresses engaging in these attacks over the first half of 2024.

Common mistakes teams make after an inference-provider breach

• Treating deletion as revocation. Clearing a secret from a dashboard is housekeeping. It is not rotation (see Step 2).
• Reading too much into a ZDR badge. Check the retention table before assuming a workload was never stored.
• Rotating only the obvious key. IAM keys, service account keys and GitHub tokens stored next to the model key matter just as much. In Google's investigations, cloud identity tokens were the most common entry point.
• Treating the first bulletin as final. Here the scope grew from stored secrets to billing information, datasets and incomplete models. Recheck your exposure with each update.
• Waiting for the monthly invoice. At the daily loss rates described above, an invoice arrives far too late to help.

Caveats: what remains unknown and how to read the numbers

• Fireworks has not disclosed how many customers were affected.
• The claim that attackers were not after model weights comes from Fireworks' CEO and has not been independently verified.
• The LLMjacking cost figures come from Google Threat Intelligence Group and Sysdig investigations of other victims, not this incident. They show what is possible, not what Fireworks customers lost.
• The Sysdig figures date from 2024 and reflect that period's model pricing and attack volumes.
• Notion's under 1 percent figure applies only to Notion workspaces.
• Notification duties depend on your jurisdiction and contracts, so take legal advice where they apply.