> Upon analysis of the new data, we discovered that it included unattributable Notion AI chat transcripts used for the Insights feature. Chats weren't labeled with who wrote them or which workspace they came from, and the transcripts did not contain any tool call results. Beyond the words in the chat transcripts themselves, the data contained no information that could specifically identify the workspace, user, or company.
> As a precaution, we recommend that you treat this unattributable data as if it were exposed. If anyone on your team pasted sensitive information like passwords, API keys, or other credentials into Notion AI during this timeframe, we recommend rotating them right away.
Okay, so the actual impact is quite interesting: they did not notify you if they could not attribute the transcripts to you! You should really treat anything sensitive sent to Notion AI as compromised because they are not sure where these transcripts came from.
> treating API tokens as compromised the moment you pasted them into an AI chat seems a reasonable default in general.
Coding agents in my experience alert you to this, which is good. I pasted what was temporary token I made into Claude, just to test something, and after it had done the task it said something like, "you gave me a live token to work with in the chat, I'd advise you to treat that as exposed and rotate it."
It would be a good standard for all chat interfaces to have those "alerts" built in.
That’s like leaving your phone in the public square. You should expect that it could get stolen. But Mike’s friend can’t go “well to be fair...” when Mike steals it.
> So how come notion discovered that they actually stored the data?
Is there any legal consequence for stating you are ZDR but then internally you don't give a shit about it? I'm guessing that'd be between OpenRouter and the provider, not between the provider and the one triggering the inference, would that be correct? Does OpenRouter validate anything at all in regards to the providers, or it's a free-for-all "do whatever you want" kind of deal for OpenRouter and the providers?
Fireworks "datasets" are used for batch inference as well as training models. Notion mentioned that the leak was due to some feature they have to classify previous ai conversations. They probably uploaded these conversations as a 'dataset' to fireworks in order to take advantage of their large batch processing discount.
Even with that, you can't really prove or provide evidence they aren't silently slinging the data elsewhere during transport anyway. Unless you're doing Homomorphic encryption, it all seems to be for show.
There's also the nvidia enclave stuff. If you trust their hardware, then you can also trust its cryptographic proof that the data was not seen by the inference provider.
Ignoring whether or not there could be backdoors, security holes in the Trusted Execution Environment stuff are still being found on a regular cadence.
I'd guess it's good enough to avoid bulk surveillance (and therefore extraction of training data, which I guess is the attack that Notion was running when they screwed up and leaked the data), but that's about it.
Apple's stuff is a similar story. (And so are VM enclaves, which have been around longer.)
> “Unattributable” means the chats weren't labeled with who wrote them or which workspace they came from, and the transcripts did not contain tool call results. Beyond what’s in the chat transcript itself, there’s no information tying the chat back to a workspace, user, or company.
This is astonishing.
They’re saying “OTHER THAN THE ACTUAL CONTENTS OF YOUR CONVERSATION, NO INFORMATION WAS PRESENT”. That is not what unattributable really means and they’re trying to assert otherwise.
It’s trivial to identify the organisation or individuals involved in a conversation most of the time, but Notion are trying to make out that because the metadata wasn’t present, it’s no cause for concern.
That’s absolute bullshit and will give people a false sense of security. The contents of your conversation IS the critical information. Notion’s desktop app is very aggressive in prompting users to transcribe their calls and I imagine a large proportion do so by default. The potential for harm here is large.
I appreciate it’s Fireworks’ fault this happened, but Notion’s response destroys my confidence in them.
To give fair credit to Notion -- they have provided the raw data that was in scope (assuming you're on an Enterprise SKU). Along with the initial notification. This is quiet rare for these breaches. Fireworks definitely did not in their response.
So we've all got all the data to make our own determination on the data being 'unattributable' or not.
This is a delicious complement to the reassurances we are always given when metadata is tracked/stored/aggregated/breached that it's fine because it's just the metadata.
but good that they finally got around to posting something official ...
I asked the CISO if they can tell me if the data was accessed but they aren't answering and any communication is super slippy like "may have been accessed". I need to do some GDPR notations bc of them but I won't start running around just bc it "may have been" accessed
Does anyone actually use the AI features? $job switched off because they spent too much time on AI features we never used, and too little time making a text editor that wasn't painful to use
I run my coding agents on a PC at home, only reachable over Tailscale for this reason. It runs an opencode server with password. Currentlyt he blast radius from all 3rd party providers is so huge and scary.
the whole incident response post feels like a huge cop-out. “abundance of caution”, the vendor is one of the biggest, so ofc it’s not our fault for choosing them… etc.
> Notion AI conversations from 2 members of your workspace may have been affected. Their conversations stay private to them. They have not been proactively emailed. In order for them to access their affected data, you must share this page with them so they can download their own.
Yeah spending the morning figuring out which users are affected and what data is involved. Time well spent. Thanks, Notion.
Super poorly IMO. Fireworks' initial breach notification was on Oct 9 [1] and told us we were 'not impacted'. Only for us to find out we were impacted after some of our Anthropic API keys used in Fireworks were 'hijacked'. That in itself took days of investigation and response. I can only imagine Notion are in a similar boat.
To my knowledge we still haven't been formally notified as being included in the Fireworks breach. It makes me extremely skeptical of the " For a limited set of accounts, we also discovered impact to secrets, datasets, and incomplete models." that they detailed in their Nov 9 update [2].
This is a strong reminder that a company's security is only as strong as its third-party integrations. Even when customer data is handled by trusted platforms, external AI vendors can introduce additional risks. Businesses need to carefully evaluate vendor security, limit the data shared with external services, and maintain transparency when incidents happen. As AI adoption grows, third-party risk management should become a core part of every company's security strategy.
> Upon analysis of the new data, we discovered that it included unattributable Notion AI chat transcripts used for the Insights feature. Chats weren't labeled with who wrote them or which workspace they came from, and the transcripts did not contain any tool call results. Beyond the words in the chat transcripts themselves, the data contained no information that could specifically identify the workspace, user, or company.
> As a precaution, we recommend that you treat this unattributable data as if it were exposed. If anyone on your team pasted sensitive information like passwords, API keys, or other credentials into Notion AI during this timeframe, we recommend rotating them right away.
Okay, so the actual impact is quite interesting: they did not notify you if they could not attribute the transcripts to you! You should really treat anything sensitive sent to Notion AI as compromised because they are not sure where these transcripts came from.
In all fairness, treating API tokens as compromised the moment you pasted them into an AI chat seems a reasonable default in general.
> treating API tokens as compromised the moment you pasted them into an AI chat seems a reasonable default in general.
Coding agents in my experience alert you to this, which is good. I pasted what was temporary token I made into Claude, just to test something, and after it had done the task it said something like, "you gave me a live token to work with in the chat, I'd advise you to treat that as exposed and rotate it."
It would be a good standard for all chat interfaces to have those "alerts" built in.
Claude itself tends to store secrets plaintext on disk, discussed 2 days ago https://news.ycombinator.com/item?id=50407882
That’s like leaving your phone in the public square. You should expect that it could get stolen. But Mike’s friend can’t go “well to be fair...” when Mike steals it.
Yes, and they won't let admins see it either. It's insane.
> "unattributable Notion AI chat transcripts"
Who is using Notion for a chat about the weather? It's chats about your content and data.
my initial thought too; even if your chat is cursory or OT it still contains lots of PII adjacent information
sounds like someone just read the inference container logstream and didn't implement wide logs
On Openrouter the Fireworks AI is labeled as ZDR.
> Private: this provider does not train on prompts and does not retain prompt data.
So how come notion discovered that they actually stored the data?
> Upon analysis of the new data, we discovered that it included unattributable Notion AI chat transcripts
> So how come notion discovered that they actually stored the data?
Fireworks informed them.
The nature of the data here is inherently stored until used. You can read the fireworks incident report at https://fireworks.ai/security/bulletins/october-2026-securit... it's linked in the first sentence of the Notion report.
> So how come notion discovered that they actually stored the data?
Is there any legal consequence for stating you are ZDR but then internally you don't give a shit about it? I'm guessing that'd be between OpenRouter and the provider, not between the provider and the one triggering the inference, would that be correct? Does OpenRouter validate anything at all in regards to the providers, or it's a free-for-all "do whatever you want" kind of deal for OpenRouter and the providers?
So Fireworks is ZDR by default, yet Notion configured (asked) Fireworks to retain data? Otherwise, how is there anything to leak?
On the main fireworks breach page, they also say some customer weights of models and datasets to train them were leaked.
Fireworks "datasets" are used for batch inference as well as training models. Notion mentioned that the leak was due to some feature they have to classify previous ai conversations. They probably uploaded these conversations as a 'dataset' to fireworks in order to take advantage of their large batch processing discount.
https://docs.fireworks.ai/guides/batch-inference
Can you really trust an AI company to be actually ZDR though
Not unless you can verify it through secure hardware attestation like with Apple’s private cloud compute system
Even with that, you can't really prove or provide evidence they aren't silently slinging the data elsewhere during transport anyway. Unless you're doing Homomorphic encryption, it all seems to be for show.
There's also the nvidia enclave stuff. If you trust their hardware, then you can also trust its cryptographic proof that the data was not seen by the inference provider.
Ignoring whether or not there could be backdoors, security holes in the Trusted Execution Environment stuff are still being found on a regular cadence.
I'd guess it's good enough to avoid bulk surveillance (and therefore extraction of training data, which I guess is the attack that Notion was running when they screwed up and leaked the data), but that's about it.
Apple's stuff is a similar story. (And so are VM enclaves, which have been around longer.)
you can stop after the word "Not"
November is going to be the month with the most breaches on record (most will be from October given 30 day notification timelines).
That is for now, I am sure there will be worse months ahead of us.
Good. Trial by fire. This is desirable if you want to improve something, it needs to break first.
The official announcements (original & update):
https://fireworks.ai/security/bulletins/october-2026-securit...
https://fireworks.ai/security/bulletins/october-2026-securit...
> “Unattributable” means the chats weren't labeled with who wrote them or which workspace they came from, and the transcripts did not contain tool call results. Beyond what’s in the chat transcript itself, there’s no information tying the chat back to a workspace, user, or company.
This is astonishing.
They’re saying “OTHER THAN THE ACTUAL CONTENTS OF YOUR CONVERSATION, NO INFORMATION WAS PRESENT”. That is not what unattributable really means and they’re trying to assert otherwise.
It’s trivial to identify the organisation or individuals involved in a conversation most of the time, but Notion are trying to make out that because the metadata wasn’t present, it’s no cause for concern.
That’s absolute bullshit and will give people a false sense of security. The contents of your conversation IS the critical information. Notion’s desktop app is very aggressive in prompting users to transcribe their calls and I imagine a large proportion do so by default. The potential for harm here is large.
I appreciate it’s Fireworks’ fault this happened, but Notion’s response destroys my confidence in them.
To give fair credit to Notion -- they have provided the raw data that was in scope (assuming you're on an Enterprise SKU). Along with the initial notification. This is quiet rare for these breaches. Fireworks definitely did not in their response.
So we've all got all the data to make our own determination on the data being 'unattributable' or not.
This is a delicious complement to the reassurances we are always given when metadata is tracked/stored/aggregated/breached that it's fine because it's just the metadata.
"We kill people based on metadata," Michael Hayden, former head of NSA 2014.
Tread with caution and stay up to date with news like this.
Posted about it earlier today: https://news.ycombinator.com/item?id=50436636
but good that they finally got around to posting something official ...
I asked the CISO if they can tell me if the data was accessed but they aren't answering and any communication is super slippy like "may have been accessed". I need to do some GDPR notations bc of them but I won't start running around just bc it "may have been" accessed
Does anyone actually use the AI features? $job switched off because they spent too much time on AI features we never used, and too little time making a text editor that wasn't painful to use
I run my coding agents on a PC at home, only reachable over Tailscale for this reason. It runs an opencode server with password. Currentlyt he blast radius from all 3rd party providers is so huge and scary.
What's a blast radius? Can AI actually cause explosions?
/s
the whole incident response post feels like a huge cop-out. “abundance of caution”, the vendor is one of the biggest, so ofc it’s not our fault for choosing them… etc.
I used Notion as a form of social CRM and it really helped me out with that task. Now, all their contacts are out. Nice stuff Notion.
Forcing us to the Enterprise plan to see which members are affected huh? Classy move Notion.
I was able to download the list of potentially affected people and I'm not on enterprised. They made this page available https://app.notion.com/ai/transcript-data
> Notion AI conversations from 2 members of your workspace may have been affected. Their conversations stay private to them. They have not been proactively emailed. In order for them to access their affected data, you must share this page with them so they can download their own.
Yeah spending the morning figuring out which users are affected and what data is involved. Time well spent. Thanks, Notion.
We also have 2 members affected in our org. I wonder if this is a coincidence or just a fixed template.
It's a coincidence, we got the e-mail stating 1 user affected
Does this reflect on Fireworks’ culture?
Super poorly IMO. Fireworks' initial breach notification was on Oct 9 [1] and told us we were 'not impacted'. Only for us to find out we were impacted after some of our Anthropic API keys used in Fireworks were 'hijacked'. That in itself took days of investigation and response. I can only imagine Notion are in a similar boat.
To my knowledge we still haven't been formally notified as being included in the Fireworks breach. It makes me extremely skeptical of the " For a limited set of accounts, we also discovered impact to secrets, datasets, and incomplete models." that they detailed in their Nov 9 update [2].
[1]: https://fireworks.ai/security/bulletins/october-2026-securit...
[2]: https://fireworks.ai/security/bulletins/october-2026-securit...
Yes. $1.505bn at a $17.5bn valuation and can't even make a reliable usage page that does not constantly bug out displaying token usage.
They don't care. The same as Openrouter: $7bn valuation, that service feels to me like about 10 devs total.
They don't care, because it's not about providing a product. Fireworks is about inference as much as a mob nightclub is about drinks.
If you’re looking for a Notion alternative you can self-host, I’m building Docmost. We launched on HN 2 years ago.
Website: https://docmost.com
GitHub: https://github.com/docmost/docmost
This is a strong reminder that a company's security is only as strong as its third-party integrations. Even when customer data is handled by trusted platforms, external AI vendors can introduce additional risks. Businesses need to carefully evaluate vendor security, limit the data shared with external services, and maintain transparency when incidents happen. As AI adoption grows, third-party risk management should become a core part of every company's security strategy.