Notion and Fireworks AI Incident: Trace Data, Keys and Response Duties

For an affected Notion workspace, the immediate task is to review the notified dataset and identify what authority its contents could expose. The Notion and Fireworks statements describe different layers of the incident. Keep their scopes and update dates attached to the claims instead of treating either statement as a complete description of every customer’s exposure.

What the two vendors currently say

Notion’s advisory, updated November 10 with a November 11 update, says fewer than 1% of workspaces are affected and that identified customers were contacted. It describes Notion AI chat transcripts used for Insights; for the vast majority of impacted workspaces the transcripts were unattributable and did not contain tool-call results. The investigation remains ongoing.

Notion’s November 11 update says it revoked exposed Notion API keys found in affected messages. Its recommendation for affected customers still includes reviewing the provided data and rotating sensitive credentials pasted into the relevant conversations. Revocation of identified Notion keys should not be interpreted as closure for every other credential or data type a transcript may contain.

Fireworks’ November 9 bulletin describes broader account, billing and selected dataset/model impacts in its own investigation. It says it has not detected impact to Inference, Training SDK and Nexus, which it describes as zero data retention by default. Those product-specific findings and Notion’s identified Insights transcript impact should be reported separately; a general ZDR statement does not override the notified application-specific dataset.

Product-specific findings do not replace a workspace notification

Use your workspace notification as the assessment boundary

Follow Notion’s secure in-workspace instructions for the affected data. Do not upload those transcripts to an unrelated analysis service or search for leaked copies. If no notification was received, Notion currently says it has not identified the workspace as affected and no action is needed right now; continue to follow its official updates rather than claiming a confirmed workspace breach.

For an affected dataset, classify contents locally with an authorized owner. “Unattributable” means the transcript lacks particular identifying labels; its text can still contain information that matters to the organization. Review actual contents and context instead of equating missing workspace metadata with absence of sensitivity.

Content class	Decision to make	Evidence for closure
Notion API key	Was it in the notified dataset and included in the vendor’s revocation action?	Credential owner confirms invalidation and replacement consumers.
Other service credential	Which issuer can revoke it, and which workloads use it?	Issuer-side revocation, consumer reconfiguration and misuse review.
Internal business material	Who owns the data and what response process applies?	Scoped data classification, affected workflow and accountable decision.
Personal or regulated data	Which internal privacy or legal process should assess the facts?	Protected review record; avoid declaring duties from a generic blog.
No sensitive contents identified	What dataset and window were actually reviewed?	Documented scope and remaining uncertainty.

Separate containment from downstream validation

A replacement secret in a dashboard does not establish that every consumer uses it or that the old one is invalid. For each affected credential, maintain a protected reference, issuing service, privileges, revocation time, dependent workloads and validation outcome. Verify through the issuer and an approved synthetic operation; do not replay someone else’s credential from an exposed transcript.

Review relevant service logs for the exposure period using the organization’s incident process. State account, Region, retention and collection limitations where they apply. An absence of suspicious events is a conclusion about the reviewed telemetry, not proof that no use occurred anywhere.

Classify the actual contents before declaring response complete

Turn the incident into a better AI vendor assessment

Ask a vendor to map each processing purpose to its actual data path: live inference, evaluation, analytics, support and training. Request the retention and deletion contract for each path, the identities that can access it and the evidence available during an incident. A single marketing label should not stand in for this route-specific inventory.

Use a synthetic acceptance exercise before expanding a supplier relationship. Put a distinctive non-sensitive marker through the intended workflow, agree where it may appear, then inspect the available records and deletion evidence with the vendor. That exercise tests the documented process within its visibility limits; it does not independently prove that no undisclosed copy exists.

Processing purpose → service / dataset
Data classes allowed → prohibited classes
Identity and access boundary
Retention and deletion contract
Incident notification and customer evidence route
Synthetic validation → observed result / limitations
Owner and recheck trigger

For an application or agent security engagement, include these data routes in scope alongside authorization tests. Keep supplier response, credential closure and your own application controls as distinct deliverables so one completed action cannot silently close the others.

An application assessment addresses different questions from the vendor incident investigation. If evaluating 펜리전트, scope the owned integration and its permissions separately from review of notified transcript data.

The official Penligent 3.0 video below demonstrates the general product workflow. It illustrates product use; the article’s assessment proposals and source findings are evaluated separately.

Method: AI-assisted review of the linked primary sources, checked November 12, 2026, with an original assessment framework. No exploit, production target or customer environment was tested for this article.