Fireworks AI, the inference and fine-tuning platform used by companies including Notion and Cursor, now says attackers reached customer billing records and, for some accounts, uploaded datasets and incomplete model weights. A month earlier it said it had seen no such access. The gap between those two statements runs straight through the limits of "zero data retention."
On November 9, Fireworks published an update to its October security bulletin that substantially widened the incident's scope. Its first bulletin, published October 9, said an unauthorized party had used internal Fireworks credentials to read environment variables in evaluation jobs for "a limited number of customer accounts," and that the company had "not detected evidence of unauthorized access to customer models, datasets, training data, inference traffic (including prompts and outputs), or personal information." The update reverses part of that: account and billing information was affected, and "for a limited set of accounts," so were secrets, datasets and incomplete models.
The update matters beyond Fireworks' own customers. It shows which parts of an AI platform a privacy promise actually covers, and how criminals are now turning access to AI infrastructure into money.
What Fireworks has disclosed, in order
The company's two bulletins give this sequence. All of it is Fireworks' own account; no independent forensic report has been published.
- October 6: Fireworks identified unauthorized use of internal credentials and began containment the same day, according to its original bulletin. The intruder accessed evaluation-job environment variables, which Fireworks said likely included API keys and tokens customers had stored as secrets.
- October 9 and 10: Fireworks rotated employee API keys, notified affected customers, published the bulletin, and revoked further user keys and service-account tokens.
- October 23: A third-party cloud provider that hosted Fireworks research and development machines had its own security incident.
- October 24: In Fireworks' words, "the unauthorized third party used it to reach Fireworks development machines and then run an unauthorized workload that led to additional customer data impact." Fireworks says it detected this the same day.
- October 25 onward: Fireworks says it has not detected further successful unauthorized access to the platform customers use.
- November 9: The update disclosed the wider data impact and said the evidence links the activity to a financially motivated group selling stolen access to large language models.
The update says the affected internal application gave access to resource metadata such as identifiers and display names; billing details including billing and shipping addresses, invoice and payment history, account balance and credit usage; and, for certain customers, "a subset of incomplete model weights and datasets." Fireworks says it does not store payment card numbers. It has brought in Palo Alto Networks' Unit 42 for forensics, notified law enforcement, and disabled self-serve dataset uploads and downloads for batch inference and dataset-based training while the investigation continues. It says the investigation is ongoing and "may reveal additional information."
Bloomberg reported that a Fireworks spokesperson said the company was working with customers "including Notion, Cursor and others" to manage the incident, and noted that Fireworks' website claims more than 10,000 customers. Forbes reported (as summarized by Techmeme) that two customers said they had already moved a substantial share of their business off the platform, one of them criticizing the company's communication.
What "zero data retention" covered, and what it didn't
Both bulletins lean on zero data retention, or ZDR, the practice of never writing prompts and model outputs to persistent storage. The October bulletin said Fireworks "does not store prompts or outputs by default, as our platform is ZDR." The November update says no impact has been detected to its Inference, Training SDK and Nexus products, "which are all zero data retention (ZDR) by default."
Those statements can be accurate and still leave a lot exposed, because ZDR on Fireworks describes inference by default, not the whole platform. The company's own documentation makes the boundary explicit.
Its secure training guide says that with Managed Training, customer datasets are "uploaded to Fireworks-managed storage (GCS)," and that Fireworks retains the dataset, checkpoints and traces. Intermediate checkpoints and request metadata are kept for 30 days unless the customer asks for earlier deletion. Evaluation jobs, the part of the platform hit first, run with whatever secrets customers give them.
Fireworks does offer an account-wide Zero Data Retention policy that would block those features. But its documentation lists it as an Enterprise feature that is "off by default." When switched on, it rejects dataset uploads, supervised and reinforcement fine-tuning jobs, batch inference, and "evaluators and evaluation jobs." In other words, most of the customer content the attackers reached, from evaluation secrets to uploaded datasets and training artifacts, lives in features that the stricter policy blocks. The documentation also notes that turning the policy on "doesn't delete anything already stored on the account."
That is the central point for anyone choosing an AI provider. "ZDR by default" tells you what happens to a chat completion. It tells you nothing about the training set you uploaded, the checkpoints a fine-tuning job left behind, or the third-party API keys you placed in an evaluation job. Those assets sit at rest, and assets at rest can be stolen.
Fireworks has not said what "incomplete models" means. Its documentation describes intermediate checkpoints, retained so jobs can be restarted, which would fit the description, but the company has not confirmed that, and it has not said whether any customer's complete fine-tuned model was taken. Bloomberg reported that the breach involved tens of thousands of files; Fireworks has not given a number of affected customers.
Why attackers want AI platforms: LLMjacking
Fireworks says the evidence points to a group whose aim is "selling tokens from unauthorized access to Large Language Models (LLMs) to illicit routing gateways," a practice known as LLMjacking. It cited a November 2 report from Google Threat Intelligence Group and Mandiant, which describes the business model in detail. Fireworks has not said which specific group was involved, and Google's report does not mention Fireworks.
According to that report, attackers obtain cloud identity tokens or LLM API keys, then either run expensive model workloads on the victim's account or pool the stolen access behind resale services Google calls "LLM Mixers." Mandiant said it saw fraudulent charges above $100,000 in a single day in individual incidents, with cumulative charges at some organizations reaching $1 million before access was cut off. In one case, an actor made more than 500,000 API calls in under eight hours to power a token-reselling service that passed nearly $1 million in costs to the victim. Google said the service offered an "unlimited" plan for about $60 a month, and that it believes the service relies on stolen keys to operate profitably.
That explains why evaluation-job secrets were the first target. An evaluation job often needs credentials for other services, such as a model provider to act as a judge, a vector database, or a storage bucket. As an incident analysis by Rafter pointed out after the first bulletin, Fireworks can revoke its own keys, but not keys issued by another provider. The October bulletin said the same: "Removing a stored secret alone does not invalidate the underlying credential." A stolen OpenAI or AWS key keeps working, and keeps billing its owner, until that owner rotates it with the issuer.
Google's report also explains the second route in. It found that stolen cloud identity tokens, not LLM keys, were the dominant way into victims' environments. Fireworks has not said how its hosting provider was breached, but an intrusion that moves from one company's infrastructure into another's development machines is consistent with the broader pattern Google describes.
The supply-chain problem for AI customers
Companies use platforms like Fireworks so they don't have to run their own GPU clusters for open-weight models and fine-tuning. That convenience means handing over the most valuable things an AI product team has: proprietary training data, the tuned weights built from it, and the keys to adjacent services. The Fireworks incident shows that those assets inherit the security of every company in the provider's chain, including a hosting provider most customers would never have heard of.
It also shows how slowly the full picture can emerge. Fireworks' first public statement ruled out access to datasets and models "based on our investigation at this time." A month later, that was no longer true. Early incident statements are often provisional, and this one said so, but customers making decisions in October were working from an incomplete account.
What Fireworks customers, and anyone using an AI platform, should check
For Fireworks customers, the company says it is notifying affected accounts with specific details. Its earlier guidance still applies: replace revoked Fireworks keys, rotate any third-party credentials named in a notice with the provider that issued them, review those providers' logs for unauthorized reads or changes, and report unfamiliar API keys, users, evaluators, training jobs or datasets.
For teams using any hosted AI platform, Fireworks' own documentation and Google's report point to the same controls:
- Know what is stored at rest. Ask which features keep datasets, checkpoints, logs or secrets, and for how long. "Zero retention" for inference is not the same promise.
- Keep data in your own storage where possible. Fireworks supports "bring your own bucket," which reads training data in place, and a Training API that never stores a dataset file. Customer-managed encryption keys can be revoked to cut off decryption of what the provider does hold.
- Treat secrets in eval and training jobs as exposed by design. Use narrowly scoped, short-lived keys and set spending caps and usage alerts with each issuing provider.
- Delete what you no longer need. Turning on a stricter retention policy later does not remove data already uploaded.
What to watch
The open questions are concrete. How many customers had datasets or weights accessed, and were any complete fine-tuned models among them? Which hosting provider was breached on October 23, and are its other customers affected? And will Fireworks publish Unit 42's findings or a fuller root-cause analysis?
The broader lesson does not depend on those answers. As fine-tuning and agent evaluation move onto hosted platforms, the sensitive part of an AI deployment is no longer only the prompt. It is the data, the weights and the keys that sit on someone else's servers, and a "zero data retention" label does not cover them unless the contract and the settings say it does.