把用户的浏览器变成内鬼，是这次 Databricks Genie Code 事件里最狠的一手。PromptArmor 披露的攻击链中，没有零日漏洞，没有提权，也没有硬闯防火墙——一段恶意 Skill 把抓到的数据塞进聊天窗口将要渲染的 HTML，剩下的活交给受害者自己的浏览器：发起出站请求，把数据带走，再弹出一个看不出破绽的登录框，等你亲手交出凭据。
这套玩法的可怕之处不在技术含量。它绕过的那些东西——出站白名单、代码审核、权限隔离——恰好是企业安全团队花钱最多、写文档最多、开会最勤的部分。
攻击链不长，每一环却都踩在信任上
从头到尾，这套攻击没做过任何越界的动作。它做的每一件事，都在产品的设计预期之内。
供应商交出来的是代码，真正干活的是渲染引擎
Skill 看上去人畜无害。它可能只是个"把季度销售数据整理成周报"的模板，逻辑清晰，注释规范，评审时挑不出毛病。恶意不藏在你能读懂的那部分代码里。PromptArmor 发现的手法更取巧：Skill 诱导 Genie Code 生成一段 HTML，而这段 HTML 里嵌着从工作区取回的真实数据。
关键动作发生在之后。聊天界面把 HTML 渲染出来。渲染意味着解析，意味着加载资源——图片、字体、样式表，任何指向外部域名的引用，浏览器都会照单去取。数据藏在 URL 参数里，或者干脆塞进子域名，就这样出了门。
出站请求的发起者，是用户本人的浏览器
这是整条链路上最要命的一点。请求的源 IP 是员工家里的宽带、咖啡馆的 Wi-Fi、公司 VPN 分给笔记本的那个地址。它还带着已经通过验证的会话，带着浏览器指纹，带着一个合法用户的所有特征。
工作区里配置的受信出口？不在这条路径上。企业防火墙的域名白名单？拦不住一个各方面都正常的 HTTPS 请求。SIEM 的告警规则？这种事每天发生几百万次。
钓鱼界面就弹在你刚刚还在用的对话框里
同一段恶意 HTML 完全可以渲染出一套以假乱真的登录界面——熟悉的 Logo、熟悉的配色、语气妥帖的提示文案，位置就在对话窗口内部。用户此刻的心理状态是"我正在用公司认可的工具干活"，警惕性处在全天最低点。
凭据一旦输入，丢的往往不只是一个人的账号。以 Databricks 在数据栈里的位置，那通常意味着整个数据平台的入口。
四道防线，失效的原因其实高度重复
PromptArmor 那篇报告的标题直译过来有点扎眼——《Databricks Genie 四道拦不住恶意 Skill 的管控》。四道防线，四次失效，但往里看，逻辑惊人地相似。
出口白名单保护的是服务器，不是人
Databricks 允许工作区配置受信任的出站访问，不少企业也确实这么做了：计算资源只能访问指定的存储桶和 API 端点。思路没问题，只是它守的是服务器发起的那条路径。这一次，请求根本不从服务器走。
门锁好了，窗也关了，攻击者是从客厅那扇你从来没想过要关的窗户出去的。这种"管控确实生效、但对本次攻击无效"的落差，会成为未来两年 AI Agent 安全领域最常见的误判来源。
人工审核看不见证生出来的那一面
第二类是流程。Skills 作为可复用资产，通常有提交、评审、上架几个环节，安全团队可以像审代码一样审它。问题在于被审的是静态文本。恶意逻辑并非写死在 Skill 里，而是运行时由模型结合上下文生成、再由前端渲染才成形。
你审的那份代码干净得像一份简历。真正动手的是它进门之后的那一瞬间。
权限收得再紧，数据本来就是要给它看的
第三类是权限边界。划定 Genie Code 能读哪些表、哪些目录，这是标准动作。可这次攻击成立的前提恰恰是：Agent 老老实实读到了它有权读的数据。没有越权，没有失控，数据只是被放错了地方——从一张结果表，变成了一段 HTML。
DLP 在这里同样难受。它的规则针对文件外发、邮件、数据库导出这些场景，一个嵌在网页里的图片地址很难触发任何一条既有策略。数据的形态变了，"敏感数据"的判定标准却没跟着变。
真正出问题的，是"渲染"这个动作
把责任推给某一家厂商很容易，也没什么用。这套攻击之所以成立，是因为整个行业对一件事还没形成共识：模型输出到底算不算可信内容？
聊天窗口早就不只是聊天窗口
从 Copilot 和各种 AI 助手进入日常工作流开始，对话界面就悄悄变成了一个富文本运行时。它渲染 Markdown、表格、图表、带交互的卡片。这些能力换来了体验，也带来一个被长期忽略的事实：模型生成的任何内容，最终都要经过一个能够发起网络请求的渲染器。
Genie 只是把这个事实摆到了台面上。数据平台的对话窗口里跑着 SQL 结果、可视化和自定义组件，它比普通聊天框更有理由渲染复杂内容，也就更有机会被拿去做别的事。
Agent 的输出，正在变成新的攻击面
过去两年关于提示注入的讨论，大多停在"模型会不会被说服去做坏事"。真正棘手的是另外半句：即便模型完全照章办事，它的输出仍然会被下游系统当作可信内容处理。
信任是这样传递的——用户信任 Databricks，Databricks 信任自己生成的 HTML，前端信任后端返回的数据。每一环单独看都合理，串起来就是一条能被任意第三方 Skill 借用的提权通道。
把浏览器沙箱当成保险箱，是个误会
有人会说，渲染 HTML 而已，浏览器沙箱不是吃素的。这话对了一半。浏览器确实拦住了跨站脚本，拦住了本地文件读取，但它从不打算阻止一个页面主动把数据发往别处——那是网页存在的意义。
靠域名白名单限制外链？你得维护一份覆盖图片、字体、CDN、监控埋点的清单，还得接受它永远追不上业务变化。上 CSP？方向对了，前提是有人意识到这里需要配。
现在能做的，和不该指望的
没有一键修复。但有几件事的优先级，比大多数人想象中高。
把渲染层默认当成不可信边界
最直接的收敛是别让模型输出直接进渲染器。代理渲染、剥离外部资源引用、把可请求的域名压到一个固定集合，或者对生成内容做静态扫描——单层挡不住全部，叠起来能挡掉大部分。实在做不到，退回到只渲染纯文本。体验会打折，但账算得过来。
出口管控得往终端挪一挪
企业浏览器、安全网关、DNS 层过滤，这些看起来有点"上一代"的工具，突然又有了用武之地。原因很简单：这次的泄漏点不在数据中心，在员工的笔记本上。同理，工作区里那些针对服务器出口的策略，也该有人问一句——浏览器那条路，谁在管？
最后一道闸，是凭据本身
钓鱼页面做得再像，也拿不走一个它拿不到的东西。硬件安全密钥、passkey、绑定设备的条件访问，这些投入的真正价值在这一刻才体现出来：即便数据已经出去了，攻击者手里握着的也只是一张没用的截图。
这句话听着像安慰，但它决定了事件最终是"一次数据外泄"，还是"一次完整沦陷"。
