Notion reports exposed API keys after Fireworks AI breach puts chat privacy at risk

Notion has reported exposed third-party API keys found in affected AI chat messages to the companies that issued them, adding a new response step to a breach involving its former supplier Fireworks AI. The update, dated November 13, says those notifications happened on November 12. Notion also says it revoked exposed Notion API keys on November 11.

The incident affects fewer than 1% of Notion workspaces, according to the company. The compromised material includes Notion AI chat transcripts used for Insights, a feature that helps administrators understand how their teams use AI. Affected customers should review the specific content identified by Notion and replace any exposed credentials rather than assume removing names made the conversations harmless.

SecurityWeek reported the customer-data exposure on November 12. The latest credential notifications add a practical development to an incident that began in October; they do not mean a new attack occurred this week.

What Notion says was exposed

In its security advisory, Notion says the affected dataset contained AI chat transcripts used for Insights. For the vast majority of affected workspaces, the transcripts were “unattributable”: Notion had not attached labels identifying the user, workspace or company. The advisory also says the transcripts did not contain tool-call results, meaning the results returned by tools invoked by the AI.

That qualification matters, but it is not a guarantee of anonymity. Names, internal project details or credentials written directly into a conversation can identify a person or organization without any separate account label. Notion explicitly recommends treating the affected content as exposed.

The company’s help page says a transcript includes model input or output written to the chat. It also explains that AI Meeting Notes audio, transcripts and summaries were not affected unless they had been used as input in a Notion AI chat. This is not a disclosure that every document, meeting recording or workspace was compromised.

An API key is a credential that software uses to access another service. An exposed key can remain useful to an attacker until it is revoked or replaced, depending on its permissions. Notion’s notice that it reported third-party keys to their issuers does not establish that every external key has been disabled. Affected customers still need to check their own services.

The October incident and November notifications are different dates

Fireworks’ November 9 incident update says a third-party cloud provider hosting its research-and-development machines suffered a security incident on October 23. An unauthorized party used that access on October 24 to reach Fireworks development machines and run a workload that caused additional customer-data exposure. Fireworks says it detected the activity that day.

Notion’s own timeline shows that the assessment of its exposure changed. On November 2, Fireworks initially notified Notion about accessed data that Notion determined was synthetic testing material, not customer data. By the morning of November 3, Notion says it had disconnected from Fireworks, deleted its data there and stopped communication between the systems.

On November 6, Fireworks warned that potential customer data might have been accessed. Notion says Fireworks confirmed the final affected dataset on November 8, and Notion contacted impacted customers on November 9.

The subsequent key revocations and issuer notifications are the latest disclosed response measures. Neither company’s statement gives a complete public count of affected people or exposed credentials. The less-than-1% figure refers to workspaces, not a measured percentage of users or chat messages.

Why the zero-data-retention explanation matters

Notion’s customer guidance also addresses zero data retention, or ZDR: arrangements under which a provider does not retain request and response data after processing it.

The company distinguishes API requests sent to generate AI responses from features such as chat history and Insights, which require stored conversations. It says its enterprise ZDR commitments are not intended to cover those feature-related storage use cases.

However, Notion says Fireworks separately gave it a contractual zero-retention commitment for its use of that platform. During the investigation, Notion says it learned that data had nevertheless been retained by the Fireworks endpoints it used. It plans to audit critical vendors’ data-minimization practices, including ZDR policies.

Fireworks, meanwhile, says it has not detected an impact to its Inference, Training SDK and Nexus services, which it describes as ZDR by default. These are the companies’ stated findings and product-scope distinctions, not a public independent determination that resolves every retention question.

For customers, the important distinction is between an AI provider’s general retention policy and the handling of a particular product feature. A zero-retention label should not be read as proof that an application’s entire chat history never exists elsewhere.

What affected Notion users should do now

Notion says customers it has identified as affected have been contacted. If neither a user nor their workspace owner has heard from it, the company says no action is currently required; its investigation remains ongoing.

Affected workspace owners can open the workspace sidebar, choose the question-mark menu and select Security incident review. Notion says the review requires an up-to-date desktop browser and is not available on mobile. Owners can identify affected members; content-download options depend on the owner’s permissions and whether the workspace has a verified domain. In most workspaces, affected members can review their own content.

Review the exposed text for passwords, API keys and other secrets, then replace those credentials at the service that issued them. Where available, check account or API activity for unexpected use. Notion’s annotated downloads include extra investigative context that it says was not itself exposed, so those added identifiers should not automatically be counted as stolen data.

A VPN would not have prevented this supplier-side exposure. It can protect network traffic on the path to an online service, but it cannot stop that service or its processors from retaining readable chat content or suffering a breach. Here, the immediate privacy task is reviewing what left the chat and disabling any credentials that should no longer be trusted.