Fireworks AI Was Breached Through Its Cloud Provider

Fireworks AI sells inference. Developers send prompts, get completions, and, in some products, store datasets and model weights so a job can run again. In October 2026 attackers got into that estate twice, the second time by compromising a cloud provider that hosted Fireworks research machines and then walking onto Fireworks development systems. Notion, a customer, later said chat transcripts from its Notion AI Insights feature were among the data taken, for fewer than one percent of workspaces.

The breach is the example to keep when a pitch deck says the model vendor is "just an API." The API is a company, the company has a cloud account, and the cloud account's neighbor can be the path in. What a malicious package can do to the agent that installed it is a related problem, covered in the coding-agent supply chain. This note is the provider that was supposed to run the model and ended up storing more than the request.

Two incidents, one October

Fireworks' update on the October 2026 security incident is the primary account. The first bulletin, on October 9, knew about stored secrets used in evaluation jobs. The update that followed, after Unit 42 of Palo Alto Networks and law enforcement were involved, widened the impact. Account and billing information was affected. For a limited set of accounts, so were secrets, datasets, and incomplete models.

Fireworks attributes the activity to a financially motivated criminal group whose business is selling stolen access to language models, a practice Google's threat intelligence group and Mandiant described on November 2 as LLMJacking. The motive matters because it predicts what they steal. A group that wants to resell tokens wants credentials that call models. A group that is already on a development machine will also take whatever data is mounted there. The bulletin describes both: secrets first, then a broader pull once they were on the machines.

The second entry was not a phishing mail to a Fireworks employee that Fireworks has described. It was the host. A third-party cloud provider running Fireworks R&D machines had its own security incident on October 23. On October 24 the attacker used that access to reach Fireworks development machines and run an unauthorized workload. Fireworks says it detected the activity the same day, cut off the path, and closed the vulnerabilities it then knew about. As of October 25 it had not seen further successful access on the platform customers use. Detection on the same day is a better outcome than a month of silence. It does not rewind the copy that already left.

The data categories in that later access are listed plainly. Resource metadata: identifiers, display names, descriptions, creation times. Billing: addresses, invoice and payment history, balances, credit usage. Card numbers were not part of it, because Fireworks says it does not store them. Model weights and datasets: for some customers, a subset of incomplete weights and datasets. Inference, the Training SDK, and Nexus are called out as not detected in the impact, and as zero data retention by default. The investigation is ongoing. "Not detected" and "by default" are the words to keep. A customer who turned retention on, or who used a product that stores by design, is not covered by the default.

What Notion found in its slice

Notion's advisory is the customer view, and it is more useful than a vendor bulletin if you are trying to see how a transcript becomes "affected." The dates are specific.

On the evening of November 2, Fireworks told Notion a small set of data had been accessed. Notion's first look said it was synthetic testing data, not customer data. On the morning of November 3, Notion disconnected from Fireworks anyway. On November 4 it deleted the data it had stored in Fireworks. On November 6, Fireworks said customer data might be involved. On November 8, Fireworks confirmed the dataset. On November 9, Notion wrote to the customers in that set.

The dataset that mattered was Notion AI chat transcripts used for Insights, the feature that classified how people used AI in the product. Notion says that for the vast majority of affected workspaces those transcripts were unattributable: not labeled with the person or the workspace, and without tool-call results. The content of the chat itself can still name a person, a customer, or a secret. "Unattributable" means Notion could not always say which workspace a transcript came from. It does not mean the transcript was empty. Fewer than one percent of workspaces were in scope. Notion says it contacted those workspaces, and that silence means you were not identified. The investigation can still move. If it does, they said they will write.

Notion used Fireworks for two jobs: the classification behind Insights, and as an inference provider for open-weight models. Insights is disabled while they investigate. Open-weight models are no longer served through Fireworks. That is the right pair of decisions for a customer that cannot yet bound the blast. Disconnect, delete, stop the feature that required the store, and tell the people whose text was in the store. Affected customers can pull the impacted data inside the workspace and were told to treat it as exposed. If they pasted a password or an API key into Notion AI, rotate it.

TechCrunch's report added the scale Fireworks claims for itself: tens of thousands of customers, with Harvey and Cursor among the names on the site. A logo on a vendor's homepage is not a statement that those companies lost data. It is a statement that the vendor is in the path of products you may use without ever signing a Fireworks contract. Your exposure can be your vendor's vendor. Notion's users did not choose Fireworks. Notion did.

Zero retention is a product setting, not a moral quality

"ZDR" is doing a lot of work in the bulletin. Inference, Training SDK, and Nexus default to not keeping the request. Evaluation jobs, the first thing Fireworks knew had been exposed, exist to keep inputs and score them. Datasets exist to be stored. Incomplete model weights exist to be stored. A company can run a zero-retention inference API and a retention-heavy training product under the same brand, on machines that share a cloud account. The attacker who lands on the research side does not honor the inference default.

Ask the question per path, in writing, for every provider that sees user text. Does this endpoint store the prompt. For how long. In which account. Who else in that account can mount the bucket. Is the store in the same project as production inference. A questionnaire that accepts "we don't train on customer data" has not asked those questions. Training is one use of stored text. A breach is another. A debugger that logs prompts to a bucket "for the week" is a third, and it is usually the one a generated app turned on because an error was hard to reproduce.

If you send customer content to a provider, your privacy notice and your retention story have to match the path that actually stores. A toggle in the provider console that the agent enabled, or that a default SDK enabled, is your policy now. Read the toggle. The GDPR-shaped version of "we did not know the processor kept it" is in what an AI-built app owes its users about data. The Fireworks incident is the processor failing. Your inventory is what tells you whether you are in the notification set.

Keys in the prompt are the avoidable loss. People paste tokens into chat because the chat is where the work is. Notion's advice to affected workspaces is the general rule: if a secret was in the transcript, rotate it, because the transcript left. Do not wait to learn whether your workspace was in the one percent if you know you pasted a production key into a product that used Fireworks. Rotation is cheap compared with arguing about attribution. If you do not know whether you pasted one, that is the inventory you do this week, not the inventory you do after the next bulletin.

What to ask a model host before the next feature ships

Where does the request go, and what else is in that account. Fireworks' R&D machines were on a third-party cloud provider. You will not get that provider's name in a marketing page. You can ask whether production inference and research workloads share a boundary, and you can treat a vague answer as a no. A vendor that can describe the isolation is a vendor that has it. A vendor that answers with the compliance badge has answered a different question.

Whether you are a direct customer or a customer's customer. If you call Fireworks yourself, you are in their notification process and you should have heard if your account was in the limited set. If you call Notion, or another app that calls Fireworks, you wait on that app's advisory, and you should know which of your features depend on it. A generated app that added "Notion AI" as a tool has this dependency even when the founder has never heard of Fireworks.

What you will do on the day the email arrives. Disconnect is a product decision. Notion took a morning. An app with the provider hardcoded in a dozen routes will take longer unless the provider is behind one client. Put it behind one client. Feature-flag the call. Practice disabling it. Deleting your objects on their side, which Notion did on November 4, only works if you know the objects. A bucket you cannot name is a bucket you cannot delete.

What the contract calls a breach. Billing addresses and resource names are personal data and customer metadata even when no prompt was taken. Incomplete weights can be the model you paid to train. Secrets in eval jobs can be the key that calls a different vendor. The bulletin is a menu. Your response depends on which line you are on. "We use the inference API with retention off" is a good line if it is true and if you have checked the other products in the same account.

Watch the follow-ups. Fireworks said the investigation can still surface more. Notion said the same. A postmortem that widens the set is normal. The mistake is to close the ticket on the first email and miss the second. Assign a person to the vendor's security page for the next month. A status inbox nobody reads is how the November 6 update arrives and waits.

Keys are the object LLMJacking is for. A stolen inference key is a bill, and it is also a key that can call whatever that key was allowed to call, including a fine-tune or a dataset read if the scope was wide. Rotate Fireworks keys you issued, even if the bulletin did not name your account, if those keys lived in an eval job or in a shared secret store the research machines could see. Narrow the replacement. A key that can only call one model, with a spend cap, is a smaller theft than a key that can read every dataset in the project. Spend caps do not stop data theft. They stop the resale of your quota from running all weekend before anyone looks at the invoice.

Customer text in a dataset is the object a weight-theft motive does not even need. If you uploaded examples to debug a prompt, those examples are the product. Delete the set when the debug is over. Name the set in the inventory so the next bulletin's line "datasets for some accounts" is a question you can answer with a list, not with a search through the console. Incomplete weights are the same list. A checkpoint from a training run that failed is still your data, and it was in the category Fireworks said was accessed for some customers. If you cannot find the checkpoint, you cannot tell whether it was yours.

The cloud provider under a model host will not be on your architecture diagram unless you put it there. Ask once, write the answer down, and date it. "Production inference runs in a separate account from research, and our data is not in the research account" is a sentence a security review can test. "We trust the vendor" is not. When the sentence is false, you still want it written, because the gap is the remediation: move the dataset, or accept the shared blast radius with your eyes open. Notion's disconnect on November 3 is what a customer can do when the client is one integration. A dozen copied SDK snippets is what a customer has to do when it is not. Count the snippets before you need to.

What to do if customer text might have passed through

1. List every provider and every feature that sends user text out of your network. Include eval harnesses, logging proxies, and "temporary" debug sinks.
2. For each, write store or not, from the provider's current setting, not from memory of the sales call. Zero retention on inference does not describe datasets.
3. If you are a Fireworks customer, read the bulletin against your account mail. If they named secrets, datasets, or weights, rotate and treat the objects as exposed.
4. If your users' text went through a product that used Fireworks, read that product's advisory. Notion's was under one percent of workspaces, with a contact to those workspaces. Do not invent a notification they did not send. Do rotate secrets you know were pasted into the chat.
5. Turn off retention you do not need. A dataset left from a fine-tune experiment is a dataset in the next incident.
6. Put the provider behind one client you can disable. If you cannot name the client, you cannot disconnect in a morning the way Notion did.
7. If you cannot say whether customer prompts are stored, you are not ready to answer the next bulletin. The list is the work.

The host is part of the system. A breach there is a breach of the text you sent, on the paths that kept it.

How Techtribe traces where prompts and keys went

We list the providers a product actually calls, and we separate the paths that store text from the paths that claim not to. You get that inventory in writing, with the keys to rotate if a transcript or an eval job may have held them. We do not read a zero-retention sentence on one API and close the others.

A one-time inventory fits when the product has a handful of model calls and you need the list before the next vendor email. A Dedicated Team fits when the product is live on vendors nobody has written down and new tools keep getting a key. The scope call is 30 minutes with a founder, and it is where we say which you are in.

Bring the provider list and whether customer text is stored for evals, fine-tunes, or logs. If a key may have been in a transcript, say that first.

The fixed scope for taking a generated app to production is a page per tool: Lovable, Bolt, v0, and Replit.