Zero Data Retention Was in the Contract. Why Did Notion AI Chats Remain Stored? - DEV Community

DEV Community

Cover image for Zero Data Retention Was in the Contract. Why Did Notion AI Chats Remain Stored?
inclinq_Founder
inclinq_Founder

Posted on

Zero Data Retention Was in the Contract. Why Did Notion AI Chats Remain Stored?

The Fireworks AI incident exposes a trust boundary that security teams often overlook: the difference between an API's documented retention policy and the storage behavior of the actual processing endpoint.

A data-processing contract cannot stop a database write.

That may sound obvious, but it is the central engineering issue raised by the Notion AI and Fireworks AI security incident disclosed in November 2026.

Notion says Fireworks had contractually committed to zero data retention for the endpoint used to analyze Notion AI conversations.

Yet the endpoint retained data.

When Fireworks experienced unauthorized access, some of those stored conversation records were exposed.

The incident affected fewer than 1% of Notion workspaces, according to Notion.

The question is not whether zero data retention is useful.

It is how an organization verifies that a specific data-processing path actually implements the policy it claims to follow.

1. The affected processing path

Notion used Fireworks AI for more than one purpose.

Fireworks provided inference infrastructure for open-weight models.

It also performed classification tasks for Insights, a Notion feature that helps workspace administrators understand how AI is being used.

These are different operations with different data requirements.

A typical inference request sends input to a model and receives output.

An analytics feature may need to examine previously recorded messages or related usage information.

According to Notion, the exposed dataset included chat transcripts processed for Insights.

The records contained AI prompts and responses.

Most affected transcripts lacked additional user, workspace or company metadata. However, sensitive details could still appear directly in the text.

Notion says its own systems were not breached and that other Notion features were not affected in the same way.

2. Why the ZDR distinction matters

Zero data retention usually refers to an inference service processing requests without persisting prompts or outputs after processing.

Notion explains that its Enterprise ZDR commitment applies to supported API inference requests sent to third-party models.

Insights is different.

It can require previously stored input and output data for analysis, and Notion states that this functionality falls outside its standard inference ZDR commitment.

But that does not resolve the Fireworks incident.

Notion's FAQ explicitly says Fireworks had made a separate contractual zero-retention commitment for Notion's use of the endpoint involved.

The endpoint nonetheless retained the data.

Therefore, the failure cannot be explained simply by saying that Insights was an analytics feature.

The relevant question is whether the vendor's actual processing endpoint complied with the specific retention obligations governing its use.

Notion's public description says it did not.

3. What the vendor incident revealed

Fireworks disclosed unauthorized access activity in October 2026.

Its investigation described incidents affecting internal credentials and an additional compromise through a third-party cloud provider that hosted development machines.

The company subsequently discovered broader customer-data impact.

Notion's own incident timeline is more specific to its customer conversations.

On November 2, Fireworks notified Notion about data initially believed to contain synthetic testing material.

Notion disconnected Fireworks by November 3.

On November 6, Fireworks warned that customer data might also have been affected.

On November 8, it confirmed a dataset that Notion found included Insights chat transcripts.

This timeline is important because it demonstrates the distinction between containing a vendor connection and understanding what had already been accessible.

Disconnecting a processor can stop future transfers.

It cannot retroactively prevent access to data previously retained by that processor.

4. Metadata removal does not equal safe content

Notion says most affected chat transcripts were not labeled with the identity of the user, company or workspace.

That is a meaningful reduction in metadata exposure.

It does not establish that the content itself was anonymous.

A prompt can include a company name, a client contact, an internal project description, a password or an API key.

A generated answer can also reproduce information that was present in source material.

On November 13, Japan's Nikken Sekkei group confirmed that affected Notion AI conversations included business information and client contact names.

The company said attached files, Notion pages and databases themselves were not part of the reported exposure.

However, information from those files that appeared in AI responses could be included.

For a security review, the relevant unit is therefore the actual transcript content, not merely the presence or absence of identifying metadata.

5. What affected customers can verify

Notion offers a dedicated Security Incident Review function.

Affected workspace owners can access it in the desktop browser through the sidebar help menu.

They can download information about affected members.

Domain-verified workspace owners can access more detailed CSV exports of exposed content, including the message text and analysis fields.

Workspace members can review their own affected content through links shared by their owners.

Notion's documentation describes fields that identify user and assistant messages, the exposed text and annotations highlighting potentially sensitive content.

The company advises customers to treat affected records as exposed.

Passwords, API keys or other credentials appearing in those records should be revoked and replaced at their issuing services.

Notion says that if neither the user nor their workspace owner received a notice, no impact has currently been identified for the workspace and no incident-specific action is required.

The investigation remains ongoing.

6. What engineering teams should examine

A data-retention policy needs to be mapped to individual processing paths, not merely a product name.

For every third-party AI integration, teams should know:

  • Which endpoint receives each category of customer content?
  • Is the request processed only in memory, or written to persistent storage?
  • Does the vendor use separate analytics, logging, evaluation or batch-processing systems?
  • Which services can copy or replay stored data?
  • What retention period applies to each storage path?
  • What evidence supports the claim that deletion or non-retention is enforced?

These are engineering and assurance questions, not just legal ones.

They do not prove that a given vendor is unsafe.

They identify the evidence needed to evaluate the actual behavior of a system.

A contractual obligation may be necessary, but the system must also be configured and tested to honor it.

Notion says it plans to audit critical vendors and verify compliance with its retention policies.

That is directly relevant to the failure it identified.

7. The architecture question

Modern AI products often involve multiple processors.

The application provider may handle authentication and user experience.

A model provider or inference platform may generate responses.

Another system may classify usage patterns, store analytics or support evaluations.

The customer sees one product.

But customer data can cross several technical and organizational boundaries.

A zero-retention commitment for one boundary does not automatically describe the behavior of every other boundary.

This incident shows why precise scope matters.

It also shows why a technical system can violate a contractual expectation without the customer having any direct visibility into that fact.

The engineering lesson is not that contracts are useless.

It is that contract compliance requires evidence from the systems actually processing the data.

A service can truthfully describe one endpoint as zero-retention while a separate analytics path follows different rules.

And an endpoint can retain data despite a contractual requirement not to do so.

Those are different situations, and security reviews must distinguish them.

The question for architects and security teams is therefore simple:

Can you demonstrate that the endpoint handling your customers' AI conversations actually follows the retention policy you've promised them?

If the only evidence is the contract itself, the technical behavior remains unverified.


Primary sources

Notion official incident FAQ

https://www.notion.com/ja/help/security-incident-involving-a-third-party-ai-vendor

Notion AI security and privacy practices

https://www.notion.com/ja/help/notion-ai-security-practices

Fireworks AI incident update

https://fireworks.ai/security/bulletins/october-2026-security-incident-update

Nikken Sekkei official notice

https://www.nikken.jp/en/news/news/20261113j.html

CyberSecurity #ArtificialIntelligence #DataPrivacy #SoftwareEngineering

Top comments (0)