Fireworks AI安全事件波及Notion客户

Notion 的 AI 供应商 Fireworks AI 发生安全事件，部分 Notion AI 对话可能被访问。按 Notion 公告，可能受影响的工作区占比为 <1%，相关所有者已收到通知。其他工作区数据不在此次披露的影响范围内。

这次事件值得程序员关注的，不只是受影响比例。对话没有用户和工作区标签，也没有工具调用结果，但聊天正文仍可能包含密码、API keys 或公司信息。接入第三方 AI 时，业务功能看似只做一次分类，背后也可能传出完整对话。

Notion 为什么会把对话交给 Fireworks

Fireworks AI 提供 AI 基础设施。公告称，它服务数万客户，有数十万开发者使用。这个规模介绍交代了供应商的业务背景，不能据此推断此次事件波及了多少其他客户。

Notion 过去主要在两个地方使用 Fireworks。

一是 Insights，通过分类任务帮助客户了解自己的 AI 使用情况。二是作为通用推理供应商，在产品内提供开放权重模型（open-weight models）。开放权重指模型权重可获取，不等于请求在用户设备或 Notion 自己的服务器上处理。

此次新确认的数据集，包含用于 Insights 的 Notion AI 对话记录。对用户来说，Insights 是一项使用情况分析功能；对实现它的系统来说，分类可能需要处理聊天内容。这提醒我们：判断数据是否出域，要追到具体请求和字段。

公告还单独提到 Learning and Early Access Program（LEAP）。参与客户自愿提供数据，帮助 Notion 测试 AI 技术；Notion 过去曾使用这些数据，在 Fireworks 上尝试训练特定任务模型。不过，公告没有说明 LEAP 训练数据是否包含在此次受影响数据集中，不能把两件事直接合并。

「无法归属」的对话，为什么仍需按泄露处理

Notion 使用了「unattributable」这个词，指聊天记录没有标注作者，也没有标注来自哪个工作区。记录里同样不包含工具调用结果，例如 Notion 页面内容，或 Notion AI 从外部拉取的数据。

这个边界很重要。按公告披露，此次涉及的是部分聊天记录，其他工作区数据未受影响，不能扩大成整个知识库被访问。

但它也不是内容安全的保证。

去掉身份标签，只能减少直接关联身份的线索，不能清除正文里的敏感信息。

用户可能在聊天里写出公司名称、内部项目、接口地址，也可能直接粘贴密码或 API keys。即使没有单独的用户 ID 字段，正文仍可能暴露身份或业务信息。后面这些是基于文本内容的风险判断，并不是公告确认已经发生的利用行为。

Notion 因此建议，把相关数据视为已经暴露；如果团队成员在相应时段粘贴过密码、API keys 或其他凭证，应立即轮换。这里的处理对象是具体凭证，单纯删除聊天记录无法让已暴露的密钥失效。

还要区分「可能受影响」与「已经确认被窃取」。原文多处保留了可能性措辞，没有给出攻击者最终获取、传播或利用数据的完整证据。<1% 也是工作区比例，不能换算成用户比例、对话比例，更不能拿来估计单个团队的损失。

断开供应商之后，怎样确认自己受了什么影响

公告给出的时间线分为三步：

• 截至 11 月 3 日，Notion 已断开与 Fireworks 的系统连接，删除 Fireworks 系统中的全部数据，停止向其发送数据和流量，并暂停所有训练运行。
• 11 月 6 日，Fireworks 通知 Notion，恶意行为者可能访问了客户数据，Notion 随即再次开展内部调查。
• 11 月 8 日，Fireworks 向 Notion 确认了这批新数据集；Notion 分析后发现其中包含 Insights 使用的聊天记录。

先断开连接，之后才确认新数据集，并不矛盾。前者用于阻止继续传输，后者用于厘清此前的暴露范围。目前 Insights 已停用，Notion 也不再通过 Fireworks 提供开放权重模型。

按公告，如果用户和工作区所有者都没有收到通知，该工作区不受影响，目前无需操作。受影响工作区的所有者，可以通过侧边栏 → ? → Security incident review 查看数据。该入口要求使用最新版 Notion 桌面应用或网页端，移动端无法访问。

所有者可以查看受影响数据的 CSV，以及补充了用户关联信息等元数据的标注版 CSV。新增字段分别以 __metadata 或 __analysis 标记。

标注版里补充的身份关联信息，不属于此次事件暴露的数据。

这点容易读错：Notion 为帮助客户调查而补上的字段，不能反过来证明攻击者也拿到了这些字段。公告还说明，相关资源仅对工作区有受管理成员的情况开放。所有者可分享专用链接，让成员下载仅包含自己受影响数据的 CSV。

我的判断

这份公告做得比较清楚的地方，是区分了聊天正文、工具调用结果和调查时补充的元数据，也给出了逐条审阅数据的入口。对于受影响团队，具体记录比一个总体比例更有助于决定哪些凭证要轮换、哪些内容需要进一步核查。

但它仍然是一份 Notion 的事件通报，不是独立审计报告，也没有提供不同防护方案的对照数据。原文未说明入侵根因、精确暴露时段、记录数量、供应商留存策略，以及此前有哪些访问控制。这些空白决定了我们无法仅凭公告判断防护是否充分。

如果将它与自建推理比较，也不能直接得出「自建一定安全」。自建会改变数据流向，同时把权限、日志、存储和运维责任交回团队。更有依据的取舍是：某项分类任务是否需要原始对话，能否只发送必要片段，以及处理完成后是否还需要留存。公告没有提供这些替代方案的效果或成本数据。

能拿来做什么

• 在前端或全栈产品接入 AI 时，把使用分析、分类、推理和训练分别列清楚，检查各自传给供应商的字段。尤其要核对 Insights 这类辅助功能是否也会接触聊天正文。
• 在 Node 服务端调用第三方 AI 前，先评估任务能否通过减少输入完成；不要把删除用户 ID 当成已经清除了敏感内容。
• 日常 AI 编程中，如果确认曾把凭证粘贴进受影响对话，应轮换对应凭证。对本次事件中的受影响 Notion 团队，先由所有者取得 CSV，再让成员核对自己的记录，避免扩大传播范围。
• 为自己的 AI 产品设计事件复核入口时，可以参考「管理员查看整体、成员只查看本人」的方式，并明确标识调查补充字段，避免用户把辅助分析数据误认成泄露内容。