← Blog
AI Supply ChainData BreachThird-Party RiskLLMjacking

Notion AI Chats Exposed in the Fireworks AI Breach — Your AI Supply Chain Is Attack Surface

Fireworks AI was breached twice in October and Notion AI chat transcripts for under 1% of workspaces were exposed. What it means for your AI supply-chain risk.

Zero Hunt Research··8 min read

Published by Zero Hunt, an autonomous AI red team on an on-premise appliance running private AI: automated penetration testing for networks and infrastructure, black-box or gray-box, with a human approving every step that matters.

The data that leaked from Notion this week never sat on a Notion server. It sat on infrastructure owned by Fireworks AI, a cloud platform Notion used to run open-weight models for one feature, and it left through a workload nobody at Notion launched. On November 8 Fireworks confirmed that the dataset the attackers reached included Notion AI chat transcripts. Notion disclosed the exposure and began contacting affected customers on November 9. This is the failure mode every company that wires a third-party AI vendor into its product should be reading closely — not because Notion did something unusual, but because almost everyone has the same dependency.

Developing story — first published 15:27 CET (14:27 UTC), November 12, 2026. Updated as Notion and Fireworks publish more.

What happened at Fireworks AI

Fireworks AI runs and fine-tunes open-source models for other companies. It was compromised twice in October, and the second time is the one that reached customer data.

The first incident, disclosed on October 9, was credential theft: attackers accessed stored secrets, including environment variables holding API keys and tokens for a limited set of accounts, as BleepingComputer reported. The second is worse. On October 23 a third-party cloud provider hosting Fireworks R&D machines was itself breached. By October 24 the attacker had used that foothold to reach Fireworks development machines and run an unauthorized workload — and that workload is what pulled additional customer data. Fireworks says it detected the activity the same day and saw no further successful access to the platform customers actually use after October 25.

Fireworks attributes the activity to a financially motivated group whose business is LLMjacking: stealing access to large language models and reselling the stolen inference capacity through illicit routing gateways. In its own words, the evidence "indicates links to a cybercriminal threat actor group... aimed at selling tokens from unauthorized access to Large Language Models." The company engaged Palo Alto Networks Unit 42, notified law enforcement, revoked and replaced credentials and service accounts, and disabled self-serve dataset uploads and downloads. Across the two incidents the data touched includes resource metadata, billing records (Fireworks says payment card numbers are not stored and were not affected), and, for a limited set of accounts, secrets, datasets, and incomplete model weights.

Who is exposed — are you a Notion customer?

If you are a Notion customer and Notion has not contacted you, Notion's position is that your workspace was not identified as affected and no action is required right now. If you were contacted, treat it seriously.

The scope, in Notion's own words, is "<1% of Notion workspaces." The exposed transcripts came from Insights, a feature that ran classification jobs through Fireworks to help customers understand their own AI usage. Notion has disabled Insights and says no other Notion features were affected. Two details soften the blast radius, and one sharpens it:

  • For the vast majority of impacted workspaces the transcripts were unattributable — the chats were not labeled with who wrote them or which workspace they came from, and did not contain tool-call results. Notion: "Beyond what's in the chat transcript itself, there's no information tying the chat back to workspaces, users or companies."
  • The sharp detail: the transcripts still contain whatever your users typed. Notion found and revoked exposed Notion API keys embedded in affected user messages on November 11. If someone on your team pasted a password, a token, or a secret into a Notion AI chat during the window, "unattributable" does not help you — the secret is the payload, and it does not need a name attached.

Timeline

Date What happened
Early October First Fireworks incident: stored secrets / API keys accessed (disclosed Oct 9)
October 23 Third-party cloud provider hosting Fireworks R&D machines breached
October 24 Attacker reaches Fireworks dev machines, runs unauthorized workload pulling customer data; detected same day
November 2 Fireworks tells Notion a dataset was accessed — believed to be synthetic test data only
November 3 Notion disconnects from Fireworks, deletes its data there, stops communication
November 6 Fireworks warns Notion that customer data may have been accessed
November 8 Fireworks confirms the final dataset — it includes Insights chat transcripts
November 9 Notion begins notifying affected customers
November 11 Notion revokes exposed Notion API keys found in affected messages

The six days between "synthetic test data only" (November 2) and "it includes your customers' chat transcripts" (November 8) are the part worth sitting with. Notion did everything right on its side — cut the connection and deleted its data within hours — and still could not know what had left until the vendor finished its own forensics. You inherit your vendor's investigation timeline whether you want to or not.

What "zero data retention" actually bought

Notion's FAQ notes that Fireworks had contractually committed to zero data retention for Notion's data. The transcripts leaked anyway. That is not a contradiction — it is the lesson. A zero-retention clause governs what a vendor is supposed to keep; it does not govern what an attacker who is already inside the vendor's R&D environment can scrape from a running workload. Contracts allocate liability after the fact. They do not keep bytes on your side of a perimeter you do not control.

"We did everything a mature security program says to do with a sub-processor — DPA, zero-retention clause, least-privilege keys — and the data still walked. What more were we supposed to do?"

Reduce the data you hand out, and watch what leaves your own network. Those are the two levers you still hold after the contract is signed.

Remediation

There is no patch here — this is a third-party breach, not a software flaw — but there is a concrete runbook, and it generalizes to every AI vendor in your stack.

  1. Am I affected? Notion is notifying impacted workspaces directly; if you were contacted, use the in-product review to retrieve and read the exposed transcripts (instructions arrive by email). If you run Notion AI across a team, do not wait for individual users to self-report — a workspace owner can review the affected data centrally.
  2. Rotate anything that was ever typed into the AI. Treat the transcripts as exposed. Any password, API key, access token, or other credential pasted into Notion AI during the incident window must be rotated at the source system, not just deleted from the chat. Deleting the message does not revoke the secret.
  3. Inventory your AI sub-processors. List every third party that processes your prompts, documents, or model data — inference providers, gateways like LiteLLM, eval platforms, agent consoles, fine-tuning hosts. Each is a copy of your data outside your perimeter. For each, record what data flows to it, what retention is contracted, and how you would learn if it were breached.
  4. Watch the egress. The telemetry you control is what leaves your own network. Baseline the normal volume and destinations of your AI API traffic so an anomalous bulk pull — or a new destination — is visible to you in hours, not in a vendor notification weeks later.
  5. Shrink the input. The cheapest control is the data you never send. Strip secrets and regulated data before they reach an external model, and prefer architectures where sensitive inference runs on infrastructure you own.

For the deployment and contract questions to put to any AI vendor, our on-premise pentest platform buyer's guide works as a checklist for sub-processors too, and the LLMjacking wave write-up covers the broader October run of AI-platform breaches this sits in.

What is not known yet

  • How many customers and workspaces, in absolute numbers. Notion gives a percentage ("<1%"), not a count, and has not said how many other Fireworks customers were affected.
  • Who the actor is. Fireworks links the activity to an LLMjacking group but names no one; neither company attributes it to a known threat actor.
  • What was in the attributable minority. Most transcripts are unattributable, but Notion has not characterized what the remainder contained beyond the API keys it found and revoked.
  • The full list of affected Fireworks customers. Notion is one named customer; the bulletin refers to a broader "limited set of accounts" without naming them.

The uncomfortable question: where does your AI data live?

Every detail of this incident traces back to one architectural choice: Notion sent customer AI data to a model running on someone else's computer. That is the default for almost every company shipping an AI feature today, and it is exactly the dependency this breach punishes. The data you cannot see leave is the data you cannot protect.

Zero Hunt is built on the opposite premise. It is an autonomous AI red team that runs on-premise, on its own private models — no prompts, findings, or credentials are sent to an external inference provider, because there is no external inference provider in the loop. The "our vendor's R&D environment got breached and your data was in it" failure mode cannot occur when the model is a 27B-to-284B appliance in your own rack, and no third party can switch the capability off, throttle it, or quietly change it. For the exposure inventory itself, the engine's 10-agent swarm maps your real attack surface the way an attacker would — black-box, from the outside — surfacing the integrations and data flows that a brochure asset list misses, and proving which ones are actually reachable rather than theoretically risky.

The detection corollary is Zero Hunt's traffic side. This breach surfaced weeks after the data left, through a vendor's notification — the canonical slow-discovery exfiltration. On your own wire, a deep-learning model with four inference heads, running on the appliance GPU, baselines your normal AI-API egress so an anomalous bulk transfer or a never-seen destination is caught while it is happening, not in next quarter's audit. You still own the contract with your vendors. You should also own the two things a contract can't give you: less data leaving, and eyes on what does. If that is the gap you are closing, tell us what your AI stack looks like.

Is this exploitable in your environment?

Zero Hunt answers that on your own network: an autonomous AI red team on an on-premise appliance, running on private AI, black-box or gray-box, with a human approving every step that matters. Proof of what is exploitable, the fix, and signed evidence — no data leaves your perimeter.