安全研究员 Frank Chu 发现，tl;dv（一款接入 Zoom 和 Teams 的 AI 会议记录服务）泄露了 181,874 份私人会议转录文本，原因是缺少了一条 Firebase 安全规则，导致任何登录用户都能读取整个记录集。此次泄露波及了 35,003 个域中的 84,312 名用户，这提醒人们，微小的配置失误也可能暴露最机密的商业对话。

泄露是如何发生的

tl;dv 将笔记存储在 Google Firebase 的 Firestore 数据库中。在 Firestore 中，开发者编写安全规则来决定谁可以读取或写入每个文档。tl;dv 的大部分集合（collections）都已正确锁定，但 meetings 集合缺少一条检查请求者身份的规则。结果很简单：一旦用户登录应用，API 就会返回该服务存储的所有会议文档列表。

这并非复杂的漏洞利用，没有恶意负载，也没有对底层 AI 模型的入侵。该漏洞是一个典型的访问控制疏忽——缺少了一行本应说明“只有所有者或受邀参与者才能查看此会议”的代码。由于规则缺失，任何经过身份验证的用户都可以枚举并下载每一份转录文本，无论其是否收到邀请。

为何这很重要

会议转录文本通常包含董事会讨论、产品路线图、法律建议和销售谈判等内容。当这些信息变得可以被公开读取时，竞争对手可能会获取战略洞察，律师可能需要重新审视保密义务，而员工也会对他们依赖的工具失去信任。数十万条记录使得这成为一次系统性失败，可能会影响任何在未仔细审查其权限模型的情况下采用 tl;dv 的组织。

响应滞后

Chu 在 1 月份向 tl;dv 团队报告了该规则缺失的问题。修复措施（添加适当的读取限制并重新部署规则集）直到 8 月才实施。对于一个允许无限制读取敏感数据的漏洞来说，从发现到修复之间长达六个月的时间窗口异常漫长。这种延迟凸显了该公司在漏洞管理流程（从分级处理到补丁部署）中的缺陷。

对 AI 驱动智能体（Agents）的更广泛启示

这一事件常被归类为“AI 风险”，但其根本原因是传统的访问控制错误。AI 智能体——无论是转录会议、起草邮件还是总结文档——都是以服务账号（service-account）权限运行的，这使得它们可以接触到与人类用户相同的数据。当这些权限过于宽泛时，AI 就会像其他任何后端服务一样，轻易地成为数据泄露的渠道。

组织机构目前可以采取的措施

  • 审计授权逻辑 – 验证 AI 工具使用的每个数据库集合、API 端点或云存储桶是否都执行了最小权限检查。寻找像 tl;dv 中出现的这类缺失或权限过大的规则。
  • 限制录制范围 – 配置笔记智能体，使其仅捕获您明确授权的会议。默认开启录制设置会扩大攻击面；而“选择加入”（opt-in）模式则能缩小暴露范围。
  • 将 AI 智能体视为服务账号 – 登记每一个第三方 AI 集成，为其分配专用身份，并仅授予其执行功能所需的权限。定期审查并撤销未使用的账号。
  • 对安全规则进行压力测试 – 运行自动化测试，尝试在没有适当凭据的情况下从集合中读取数据。将这些检查纳入 CI/CD 流水线，以便在部署前发现缺失的规则。
  • 加速事件响应 – 为确认、分级处理和修复报告的漏洞建立明确的时间表。如本例所示，长达六个月的修复期属于流程失效，会放大简单漏洞的影响。

下一步值得关注的方向

依赖 AI 助手进行会议记录、通话总结或实时转录的企业，应当预见到其他云原生服务中可能出现类似的配置错误。随着 AI 智能体日益融入日常工作流，“AI 风险”与“传统安全风险”之间的界限正变得模糊。请密切关注权限审查，要求供应商提供透明的安全规则审计，并推动快速的补丁更新周期，以防止下一个“缺少一条规则”的事件再次导致大量机密对话泄露。

核心结论： AI 工具的安全性完全取决于保护其所触及数据的访问控制措施。一个被遗漏的 Firestore 规则，就让一个实用的笔记助手变成了一场大规模的数据泄露；定期测试权限是唯一可靠的防御手段。