Databricks Genie 的聊天渲染功能，被一个恶意 Skill 变成了数据外泄通道。2026 年 10 月 5 日，安全公司 PromptArmor 发布披露报告：Databricks 的智能体助手 Genie Code 执行恶意 Skill 后，会在用户打开分析结果时弹出钓鱼窗口，并借用户自己的浏览器把租户数据发往攻击者服务器，企业指望兜底的四类控制一类都没有拦住。先把性质说清：这是研究人员按负责任披露流程公布的攻击演示与分析，不是已经确认发生的真实泄露事件。
攻击是怎么一步步走完的
Genie Code 是 Databricks 面向企业数据团队的智能体助手，用户用自然语言就能操作租户里的数据，Databricks 近年的扩张势头很猛，新模型发布当天 Databricks 就让 12000 名员工开测。PromptArmor 演示的攻击链只有四步：
- 用户让 Genie 用一个上传的 Skill 分析数据。Skill 常在各类在线市场上流通，这个生态早已被恶意 Skill 污染；而 Genie 加载的是用户个人工作区里的 Skill，不是组织统一治理的目录。
- Genie 执行 Skill 里的代码。执行前有一个护栏智能体负责审查命令，会标记"向第三方发送数据"这类动作，但这一次它放行了，没看出代码里藏着的恶意能力。
- Genie 提示用户打开完整的分析结果。
- 结果一渲染，攻击同时发生：Skill 代码事先把从租户里收集的数据集等敏感信息嵌进 HTML 展示页，页面里的脚本让用户的浏览器向攻击者服务器发请求，把数据带出去；与此同时，页面上还叠出一个攻击者网站的钓鱼层，向用户骗取凭据。整个过程不需要任何人工审批介入。
四类控制为什么都没拦住
- 组织级 Skill 治理：Databricks 有目录治理体系，但 Genie 实际从个人工作区加载 Skill，治理管不到这一层。
- 护栏智能体：Databricks 的说法是，自动放行（auto-allow）不是安全边界，只是防止不可信输入自动运行的控制手段，而且它还是文档中的默认与推荐模式。指望它做安全审查，本身就指望错了对象。
- 编程环境的网络出口控制：编程环境确实不许联系不可信的外部地址，这条规则没有被突破。问题在于真正发出请求的是用户的浏览器，出口根本不在编程环境里。
- 聊天展示的沙箱规则：规则要求展示页不能去租户里查询数据，这条也被"遵守"了——展示页没有查询任何东西，它只是把 Skill 代码预先塞进来的数据渲染出来，再顺手发走。
PromptArmor 的判断是：两条被"技术上遵守"的保证，设立目的本来就是防止数据外泄，结果外泄照样发生了，这说明 Databricks 的威胁模型里存在缺口。
Databricks 的回应，和没有回应的那一条
时间线摆得很清楚：PromptArmor 于 2026 年 8 月 16 日向 Databricks 报告，双方协调到 9 月 15 日，9 月 16 日 PromptArmor 告知将公开发布。Databricks 的核心回应是："最终要由用户负责，确保上传的 Skill 不含恶意内容。"对个人工作区加载、绕开组织治理目录这一点，Databricks 没有给出说法。
正在用 Genie 的团队，先做这四件事
第一，把个人工作区里的 Skill 当成代码来管：来源不明的 Skill 不装，装之前先审。第二，生产数据环境里关掉或收紧自动放行，命令审批宁可多打断一次。第三，把浏览器侧的出口纳入监控——这次的教训是，数据不一定从服务器出去，也可能从员工的浏览器出去。第四，盘点一遍已经装上的 Skill 和插件市场来源。这套风险也不是 Databricks 独有：凡是允许智能体在聊天里渲染 HTML、又允许第三方 Skill 接触业务数据的产品，都该按同样的攻击链自查一遍。
