Notion’s Fireworks Incident: How to Review Your Workspace’s Exposure

Notion’s November 9 security advisory says the Fireworks AI incident affected fewer than 1% of Notion workspaces. The identified customer data included Notion AI chat transcripts used for Insights. Affected customers have been contacted and can review their impacted data inside their workspace using emailed instructions. Notion recommends treating that data as exposed and rotating credentials pasted into Notion AI during the incident timeframe. Customers without a notification currently need no action, although the investigation continues. These are Notion’s reported findings, rather than an independent forensic assessment.

For a workspace administrator, the useful first question is specific: What does the affected data contain that someone could use, disclose or act on? That question produces a more useful response than treating every workspace or every AI conversation as equally affected.

What changed since the October disclosure

The earlier October coverage focused on evaluation-job secrets and API-key actions. Fireworks’ November 9 update expands its reported impact to account and billing information, plus secrets, datasets and incomplete models for a limited set of accounts.

Fireworks also describes further activity: a cloud provider hosting its R&D machines experienced an incident on October 23, followed by unauthorized access to Fireworks development machines on October 24. The company says it detected that activity the same day. Its updated bulletin reports no further detected successful access to its customer platform since October 25, while emphasizing that the investigation remains open.

Fireworks says payment-card numbers were not affected because it does not store them. It reports no detected impact to Inference, Training SDK or Nexus. It has disabled self-service dataset uploads and downloads for Batch Inference and dataset-based training during the investigation. Direct Fireworks customers should use their own incident notification to establish their account’s scope.

Notion says it disconnected from Fireworks by November 3 after an initial synthetic-data notice. It received a potential customer-data notification on November 6 and confirmation of the new dataset on November 8. Insights is disabled. For most affected workspaces, transcripts lacked user or workspace labels and tool-call results, but their text may still identify people or organizations.

Start with a controlled review

My recommended workflow is to assign one administrator to coordinate the review with the security or IT owner. Open Notion through your usual route, confirm which workspace the notification concerns, and use the official instructions. If the affected-data view is unavailable, ask Notion support to clarify access rather than circulating screenshots of the notification and guessing at scope.

Keep a short response record: the workspace, the notice date, the person reviewing it, the data categories found, and the owner of each follow-up. Limit access to the underlying transcripts. Copying them into a general team channel or another AI assistant would create another disclosure surface during an already sensitive review.

Separate credentials from other confidential material. A live API key calls for an access-control response. A customer proposal, employee detail or unreleased roadmap needs a different assessment of who is affected and what obligations apply. Ask your security, privacy or legal owner to evaluate those questions using the actual content. A public incident headline cannot determine your organization’s notification duties.

The public advisory does not give a universal transcript date range. Use your workspace’s notification and affected records, and ask for clarification where dates are missing. Avoid substituting the attacker activity dates for the dates of conversations included in a dataset.

Make credential remediation verifiable

For an exposed credential, identify the issuing service, the permissions it grants and the applications that depend on it. Revoke or replace it at that service, update the dependent applications, and verify both that the replacement works and the old credential is invalid. Deleting the chat containing a key does not invalidate the key.

OWASP’s secrets-management guidance recommends revocation for potentially compromised secrets, controlled rotation, auditing and minimum necessary permissions. It also distinguishes compromised user credentials from routine scheduled password changes. Those principles support targeted remediation rather than an unsupported instruction to reset every account in a company.

Record credential identifiers and completion times without pasting secret values into the response ticket. Have the service owner review available activity logs for unexpected use and document the period examined. When evidence is incomplete, say so. “No suspicious activity found in the logs reviewed” is a more defensible conclusion than “nothing happened.”

Ask how each AI feature handles data

For future vendor reviews, ask separately about interactive inference, usage analytics, evaluation datasets and training. Request the purpose of each data flow, its retention period, its subprocessors and the controls available to administrators. A product-wide assurance can leave important questions about a particular feature unanswered.

This incident makes that inventory worth checking. The immediate decision remains narrower: establish your workspace’s identified exposure, assign the right owner to each data category, and retain a clear record of what was checked and resolved.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help enterprise technical teams turn complex product decisions into clear articles and founder-led stories people can understand.

Book a 30-minute call.