I read the reassurance sentence on a vendor security page more carefully than the incident description, because it tells you which system the vendor thinks you were worried about. Fireworks AI’s bulletins over the last month are a clean example of why. The company cleared its zero data retention products by name. The data that walked out the door was the data sitting in the part of the platform that exists specifically to keep things.
Not really a contradiction. It is a category error that a lot of teams are making, because “we are ZDR” is the sentence everyone wanted to hear.
🔍 What the two bulletins actually say
Fireworks published its first bulletin on October 9, 2026, describing an incident it identified on October 6. An unauthorized party had used internal Fireworks credentials to reach environment variables in evaluation jobs for a limited number of customer accounts, and API keys and tokens stored there as secrets were captured. At that point the company said it had no evidence of access to models, datasets, training data, inference traffic, or personal data.
The update published this week changes that. Fireworks says it found impact to account and billing information, and, for a limited set of accounts, impact to secrets, datasets, and incomplete models.
The chain behind the second wave is the part worth reading twice. On October 23, a third-party cloud provider that hosted Fireworks R&D machines had a security incident. On October 24, the unauthorized party used that access to reach Fireworks development machines and run an unauthorized workload, which led to additional customer data impact. Fireworks detected it the same day and says that as of October 25 it has not seen further successful unauthorized access.
Fireworks attributes the activity to a financially motivated cybercriminal group reselling tokens through illicit routing gateways, which is the pattern Google Threat Intelligence Group and Mandiant described as LLMJacking: stolen model access proxied and sold, sometimes running to six figures of fraudulent charges in a single day. Fireworks brought in Palo Alto Networks Unit 42 and notified law enforcement.
Bloomberg reported on November 9 that Fireworks began notifying customers that day, and that the breach involved “tens of thousands of files” containing customer data according to a person familiar with the matter. That file count is a single-source detail that Fireworks has not confirmed, and the number of affected accounts is still undisclosed. Fireworks lists more than 10,000 customers. Its spokesperson told Bloomberg the company is working with Notion, Cursor, and others.
🧾 Read the two lists together
Here is the sentence. “We have not detected any impact to Inference, Training SDK and Nexus, which are all zero data retention (ZDR) by default.”
Here is the list of what was accessed: resource metadata, billing and shipping addresses, invoice and payment history, account balance, and credit usage. For a limited set of accounts, secrets, datasets, and incomplete model weights.
Both statements can be true, and together they describe the actual architecture. There are two planes in a platform like this. The data plane is inference: prompts go in, tokens come out, nothing is written down. That plane is ZDR by default because keeping prompts is expensive and nobody wants the liability. The account plane is everything you asked the platform to store for you: the dataset you uploaded for batch inference, the fine-tune weights you are midway through, the secret you saved for an evaluation job, the invoice history. That plane cannot be ZDR. Storing things is its entire job.
The first bulletin’s reassurance covered the plane that was designed not to keep anything. The second bulletin’s impact list is the plane that exists to keep things. If you are a customer reading “ZDR by default” as a statement about your risk, you were reading a statement about one plane and applying it to the other.
The words “by default” do a lot of work too. A default is a setting, which means it stops being true the moment a product surface needs to remember something to function.
🏷️ Notion’s transcripts were there because a feature needed them
Notion’s own advisory is the clearest illustration. Notion used Fireworks for two things: classification jobs behind Insights, a feature that helps customers understand their own AI usage, and general inference for open-weight models inside the product. Under its Learning and Early Access Program, customers volunteered data that Notion used to experiment with training task-specific models on Fireworks.
The exposed material was Notion AI chat transcripts from that classification work, which Notion describes as unattributable: not labeled with a user or workspace, and without tool call results, meaning no page content and no external data pulled in. Notion puts the exposure at under 1% of workspaces and says it has contacted the owners of those workspaces. It disabled Insights, stopped serving open-weight models through Fireworks, and is telling customers to treat the data as exposed and rotate anything sensitive that was pasted into Notion AI, including passwords and API keys.
None of that is negligence on Notion’s part. It is what building the feature required. But it is exactly the mechanism I am describing: the retention was not Fireworks’ default, and it was not a leak in Fireworks’ ZDR guarantee either. It was a workload that needed stored data, on a platform that stores data when asked.
One detail on Notion’s page matters operationally. Affected users cannot go look this up themselves in most cases. Workspace owners get an in-app review path, an Enterprise owner gets CSV exports, and on other plans the owner has to take a link and share it with each affected member so that member can download their own data. If you are a member of an affected workspace and your owner does not forward that link, you will never see your own exposed transcripts.
🕳️ Your vendor’s vendor
The intrusion path from October 23 deserves its own section, because it is the part that no amount of vendor review would have caught.
Fireworks did not get breached at its front door. A cloud provider hosting its R&D machines got breached, and the attacker walked from there into development machines and ran a workload. Development machines are the worst possible place to land: they hold the broadest credentials, the least restrictive network rules, and the shortest log retention, because they are built for people who need to move fast and break things.
Notice also what the actor did with the access: it ran an unauthorized workload. Not read, not just copy. It executed compute, which is what you do when the goal is turning someone else’s credentials into resale capacity.
Every Fireworks customer had exactly one path to knowing whether their datasets were in that workload: wait for the forensics. There is no customer-side control that substitutes for it, because the data was not in the customer’s account. It was in a copy the customer gave to a vendor, which gave it to a platform, which ran it on machines hosted by someone else. Your data residency story ends at a boundary you have probably never drawn on a diagram.
🛠️ What I would change
The useful outcome here is not a vendor blacklist. It is a different inventory question.
Ask your inference and training vendors which of their product surfaces are not ZDR, and what the retention window is on each. “Are you ZDR” gets you a yes, because nobody says no. “Which endpoints keep data, for how long, and can you enumerate the datasets and models my account has stored” gets you an actual answer, and any vendor with a mature security program can produce it.
Then write down your own list: every dataset, fine-tune, and secret your organization has stored on somebody else’s inference platform, with the date it went in. That list is your blast radius. If you cannot produce it in an hour, you cannot tell whether this incident touched you, and you will be relying on a notification that may name your workspace owner rather than you.
Treat model weights like source code, because that is what they are. “Incomplete models” in Fireworks’ impact list means partial training artifacts. If you were fine-tuning on proprietary data, the adapter is a compressed summary of that data, and losing it is an IP event, not only a privacy one.
Rotate at the issuer. Fireworks made this point in its October 9 bulletin and it is the most practical sentence in either document: removing a stored secret does not invalidate the underlying credential. Deleting the entry in a vendor console feels like remediation and is not.
And assume the vendor’s vendor is in scope. Ask who hosts the R&D and training infrastructure, not just the production inference fleet: that provider has the same blast radius as your vendor’s production environment, with a fraction of the audit pressure.
🧠 Final Thoughts
The headline people want is that a vendor with zero data retention got breached and lost customer data. The honest version is narrower and more useful: the retention guarantee covered a code path, and the data that leaked was on the path that has to retain by design.
So the question is not whether your AI vendor keeps your data. Some of it, they must, or the feature you bought does not work. The question is which features you turned on that made them keep it, whether you can name them, and whether your vendor can tell you that your copy was in the blast radius before Bloomberg does.
Thanks for reading.