Fireworks AI breach and what it means for Notion customers
On 9 November 2026, Notion published a security notice about an incident at Fireworks AI, the vendor that powers parts of Notion AI. The notice confirmed that some chat transcripts linked to Notion AI's Insights feature were exposed, and that the affected transcripts were unattributable — they could not be tied back to a specific workspace or user. Notion stated that fewer than 1% of workspaces were affected and that no other core workspace data was compromised. The breach itself originated in a cloud provider incident on 23 October 2026, according to the Fireworks AI bulletin referenced by Notion.
The scope sounds small, and in one sense it is. In another sense it is a sharp illustration of a problem that most organisations have not yet internalised: when you call an external model through an API, you are not making a stateless function call. You are entering a data-processing relationship, and the security of that relationship is governed by contracts, logging, and credential scoping that you probably have not audited as carefully as your own infrastructure. This post works through what happened, what it exposes about AI supply chains, and what to do about it.
What actually happened
The facts as published are worth separating carefully, because the temptation in a breach story is to round up.
Notion's notice states that chat transcripts associated with the Insights feature were exposed, that those transcripts were unattributable (no workspace or user identifiers attached), and that fewer than 1% of workspaces were affected. It also states that no other core workspace data — documents, pages, databases — was compromised. The exposure window traces back to a cloud provider incident on 23 October 2026, per the Fireworks AI bulletin.
The Fireworks AI bulletin, as referenced by Notion and discussed in the Hacker News thread linked below, describes the upstream cloud provider incident and notes that metadata, billing information, and (in some cases) incomplete model weights and datasets were exposed. Fireworks confirmed that zero-data-retention arrangements applied to Nexus and Inference workloads.
Two things follow. First, the exposure is of content, not of identity: the transcripts cannot be directly attributed to a user, but the content itself may be sensitive. Second, the timeline — 23 October incident, 9 November public notice — leaves a gap during which affected customers had no way to know their data was in question. Notion's advice, which is the right call, is to treat the exposed data as if it were fully exposed rather than relying on the unattributable label as a comfort.
The unattributable label is not a guarantee
It is tempting to read "unattributable" as "harmless." That reading is wrong, and it is worth being explicit about why.
Transcripts contain the questions people ask and the answers they receive. Even without a user ID, content is often self-identifying: a transcript about a specific contract, a named customer, an internal codebase, or a medical question can be re-identified by anyone who recognises the context. The absence of metadata in the exposed records means the vendor cannot easily tell you which of your data was involved, which is precisely why Notion's guidance is to assume the worst for anything sensitive that passed through the Insights feature during the window.
This is a general property of AI systems, not a quirk of this incident. Prompts and responses are data, and they carry information that is often more revealing than structured records. Treating them as low-sensitivity because they are "just chat" is a category error that this breach makes concrete.
An API call is a data-processing relationship
The most useful reframe this incident offers is organisational rather than technical. When an engineering team integrates an external LLM via an API, the integration is usually reviewed as a feature: does it work, is it fast, is it cheap. It is rarely reviewed as a data-processing relationship, even though that is what it is.
Every prompt and every response becomes data that the vendor receives, stores (or claims not to store), logs (or claims not to log), and may be compelled to disclose or accidentally expose. The vendor's security posture, retention policy, subcontractors, and incident-notification timeline all become part of your own security posture. You do not get to treat them as someone else's problem, because your users and your regulators will not.
This is not a novel observation — it is how cloud and SaaS procurement has worked for years. What is new is the speed at which AI features get integrated. A feature that would have triggered a full vendor security review three years ago now ships in a sprint, and the review, if it happens at all, happens after the fact. The Fireworks incident is what that looks like when it goes wrong.
What to demand from AI vendors
The breach points at a set of contractual and technical requirements that should be standard for any AI vendor, and that are currently treated as optional.
Zero data retention as a default, not an option. Fireworks confirmed zero-data-retention for Nexus and Inference workloads. That is good, but it should not be a feature that you have to ask about and verify. For inference workloads in particular, ZDR should be the contractual default, with any deviation requiring explicit written agreement. If a vendor cannot or will not commit to ZDR for your workload, that is a data-retention decision you are making by omission.
Attribution logging that survives an incident. The "unattributable" nature of the exposed transcripts is a symptom of logging that was designed for analytics rather than forensics. Vendors should be contractually required to log and retain request attribution — workspace, user, timestamp, endpoint — for every request, independent of whether they use it internally. That log is what turns "we think you were affected" into "here is exactly what was exposed, and here is how to check."
Notification timelines with teeth. The gap between 23 October and 9 November is not unusual for supply-chain incidents, but it is too long for a customer who needs to rotate credentials or assess exposure. Contracts should specify notification windows measured in days, not "without undue delay," and should require notification of the incident itself rather than only of confirmed impact.
Liability clarity across the chain. When the incident originates with an upstream cloud provider and lands on a downstream customer, the contractual allocation of liability between vendor and provider is what determines whether you have any recourse. Most AI vendor contracts are vague here. That vagueness is a risk you are carrying.
Credential scoping: the control that actually works
The Hacker News discussion of this incident converged on a piece of advice that is more useful than anything in the vendor contracts: treat any credential that has passed through an AI chat as compromised, and scope AI credentials so that compromise is cheap.
The principle of least privilege, applied to AI integration, means that a key issued for a classification or summarisation task should authorise exactly that. It should not be able to upload datasets, trigger training jobs, access billing, or read other workspaces' data. The Fireworks remediation — disabling self-serve dataset uploads — is an implicit admission that the upload path was a higher-risk surface than the inference path, and that the two were not adequately separated.
Concretely: provision separate credentials per feature, per environment, and per data sensitivity. Rotate them on a schedule, not only after incidents. Store them in a secrets manager, never in source. And when an incident occurs, the first action should be rotation of every credential that touched the affected path, before the scope is fully understood. Rotation is cheap; forensic certainty is not.
What to do now if you use Notion AI
If your workspace uses Notion AI, the practical steps follow from Notion's own guidance, applied with the reframe above.
First, access the affected-data link in the Notion notice and review what was transmitted through the Insights feature during the exposure window. Assume that anything sensitive that passed through it was exposed, and treat it accordingly — rotate credentials, notify anyone whose data may be involved, and update any downstream systems that relied on the confidentiality of that content.
Second, audit what else in your stack uses external AI vendors, and apply the same questions: what data is in the prompt, what is retained, what is logged, and what is the notification timeline. The Fireworks incident is a convenient forcing function for an audit that most organisations should have done already.
Third, implement internal logging that records what data was sent to which AI endpoint, independent of the vendor's own logs. That log is your chain of custody when the vendor's records are incomplete or delayed, and it is the only way to answer "were we affected?" in hours rather than weeks.
Conclusion: the longer-term fix
The incident is small in scope but large in implication. AI supply chains are being assembled faster than the security practices around them, and the gap is visible in incidents like this one.
The sustainable fix is not a single control. It is a standing practice: maintain an audited inventory of every AI vendor and the data each one receives; put zero-data-retention, attribution logging, and notification timelines into contracts as defaults; scope credentials so that a vendor compromise is a contained event rather than a cascade; and review the inventory on a schedule, not only after a breach. None of this is exotic. It is the same discipline that platform teams already apply to databases, queues, and third-party APIs. The only thing that has changed is that AI endpoints have been treated as exceptions, and they should not be.
Sources
- Notion security notice: https://www.notion.com/help/security-incident-involving-a-third-party-ai-vendor
- Fireworks AI security bulletin (October 2026 incident update): https://fireworks.ai/security/bulletins/october-2026-security-incident-update
- Hacker News discussion: https://news.ycombinator.com/item?id=50437106