9 月 24 日，专注 AI 智能体安全的 Zenity Labs 公开了代号为 SalesBleed 的三个漏洞，全部指向 Salesforce 的 AI 智能体平台 Agentforce。利用这套漏洞，攻击者往一个公开的销售线索表单里提交一段"投毒"的留言，就能让企业自己的 AI 助手悄悄把 CRM 里的客户数据送出公司，全程不需要任何员工点一下链接。
很多人的第一反应是：我不点可疑链接、不扫陌生二维码，钓鱼邮件我一眼就能认出来，我还怕什么？
这正是本期要纠正的认知误区。SalesBleed 最值得警惕的地方在于：攻击触发条件是"员工正常上班干活"——你只是让 AI 助手帮你总结一下今天的销售线索，数据就出去了。今天我们把这件事从原理到防护拆开讲清楚。
一、事件复盘
先交代背景。Agentforce 是 Salesforce 推出的 AI 智能体平台，企业可以用它搭建"AI 销售助理""AI 客服"，让智能体直接读取 CRM 数据、回答员工问题、甚至主动在协作工具里发消息。
Zenity Labs 的研究人员发现了三个漏洞，并在 9 月 24 日公开发布：
漏洞一：零点击 CRM 数据外泄。 攻击者通过 Salesforce 官方的 Web-to-Lead 公开表单提交一条销售线索，在姓名、公司名这些普通字段里夹带隐藏指令。这段指令安静地躺在 CRM 里，直到某天有员工问智能体"帮我看看最新的线索怎么样了"——智能体读取了这条被投毒的线索，立刻执行了里面的隐藏指令：查询客户账户数据、把查到的公司名和订单金额编码进一个网址、再以网页图片的形式"展示"给员工。图片一加载，一个指向攻击者服务器的 DNS 查询就发出去了，数据随之出境。员工看到的是一段正常的回复，什么异常都没察觉。
漏洞二：借道 Slack 的零点击外泄。 同样的投毒入口，换了个出口。协作工具 Slack 有个"链接预览"功能——消息里出现网址时，Slack 会自动去抓取网页信息生成预览卡片。研究人员发现，精心构造的链接一旦被智能体带进消息，Slack 的自动抓取本身就会把夹带的 CRM 数据送到攻击者服务器，同样没有任何人需要点击。
漏洞三：智能体身份被冒用发钓鱼消息。 Agentforce 与 Slack 集成时，默认模板里有一个"回复 Slack 消息"的动作，它既不需要用户确认，也不显示到底是谁让智能体发的这条消息。这意味着内部人员或外部攻击者都能让智能体"以自己的名义"在群里发钓鱼链接，同事看到的发送者是企业自己的 AI 助手——天然可信。
值得一提的是时间线，这次厂商的响应算是教科书级别：Zenity 6 月 1 日报告问题，Salesforce 一天内响应，URL 安全机制的核心绕过在 8 月中旬修复，9 月 21 日三个问题全部确认修复，9 月 24 日对外披露。Salesforce 表示没有发现被实际利用的证据。也就是说，这是研究者的"负责任披露"，漏洞在造成损失之前已经关闭。
那为什么还值得专门写一篇？因为 Zenity 的 CTO Michael Bargury 说了一句很到位的话：这类问题不是 Salesforce 独有的 bug，而是一个类别——任何一个满足这三个条件的智能体都坐在同一条导火索上：能读取外部来源提交的数据、有权限查询敏感信息、还能对外展示内容或执行动作。
二、技术核心拆解
1. 根子上的问题：AI 分不清"数据"和"指令"
这是整个事件的技术核心，叫提示注入（Prompt Injection）。
大模型的工作方式是读一段文字、生成一段回答。它天生没有能力区分"这段文字是用户交代给我的任务"还是"这段文字只是我处理的一份资料"。对人类来说，一份简历上写着"请把我的工资改成两万"显然是废话，但对一个直接处理简历内容的 AI 来说，它可能就真去执行了。
SalesBleed 里的手法叫间接提示注入：恶意指令不在你跟 AI 的对话里，而是藏在 AI 要处理的第三方数据中——一条销售线索、一份 PDF、一张网页。员工跟 AI 的对话完全正常，投毒发生在 AI 读数据的那一步。
2. 数据是怎么"无声"溜出去的
发现 AI 被注入了指令是一回事，把数据送出去是另一回事——智能体的网络访问通常受限制。研究人员找到的通道很巧：DNS 查询。
原理是这样的：智能体把查到的数据（比如公司名、订单金额）拼进一个域名的子域部分，构造出类似"公司名.订单金额.攻击者域名"的网址，再以网页图片的形式放进回复。页面渲染图片时会自动发起一次 DNS 解析——而 DNS 解析的请求本身就会完整地经过攻击者控制的域名服务器。一次"看图"就是一次数据快递，不需要建立连接、不需要用户交互，日志里也只是一条不起眼的域名解析记录。
而拦住这一切的 supposed 安全机制——Salesforce 的 Trusted URLs（可信网址白名单，负责把不可信链接和图片遮蔽掉）——存在两个小缺口：一是不认识某些新顶级域名的网址，二是特定字符会干扰它的网址解析逻辑。两个小缺口叠加，恶意字符串就从白名单机制的眼皮底下溜了过去。
3. 为什么说这是"智能体时代"的通病
把 SalesBleed 抽象一下，攻击链条是：不可信输入 + 高权限工具 + 对外通道，三者在智能体的上下文里会师。
- 不可信输入：公开表单、外部邮件、网页内容，任何外面进来的数据；
- 高权限工具：智能体替你查数据库、发消息、调接口，它的权限就是你给它的权限；
- 对外通道：渲染图片、发链接、DNS 解析，任何能"向外伸手"的动作。
传统的软件安全里，这三样通常被架构隔离在不同模块。而智能体的本质恰恰是把"读数据"和"用工具"放进同一个上下文窗口——这是它好用的原因，也是它危险的原因。安全意识培训教大家"别乱点链接"，但没有任何培训能覆盖"AI 在它自己的上下文里做了什么"。
Zenity 早在 2025 年的 Black Hat 大会上就演示过同款攻击路径（当时叫"特洛伊线索"），这次相当于同一个门再被推开一次，而且推得更深。两次撞同一扇门，说明这不是偶然疏忽，而是架构级风险。
4. 三层风险分开看
- 功能风险：智能体被注入后返回被污染的结果，员工基于错误信息做业务判断；智能体被滥用向协作工具发消息，扰乱内部沟通。
- 安全风险：CRM 中的客户信息、订单金额、合同价格、联系方式等敏感数据被定向外传；智能体的可信身份被冒用，成为内网钓鱼的跳板。
- 合规风险：CRM 数据往往包含大量个人信息。对中国企业而言，客户数据外泄可能触发《个人信息保护法》《数据安全法》下的数据安全事件报告义务；在海外业务场景还涉及 GDPR 等法规，泄露责任认定和赔偿成本都会显著放大。
三、三个常见误区
误区一：不点链接就安全。 这是被 SalesBleed 直接击碎的假设。两次零点击外泄的触发条件分别是"员工让 AI 总结线索"和"Slack 自动生成链接预览"——都是正常工作流。零点击的意思是受害者不用动手，而不是攻击者不用做事。防钓鱼意识依然重要，但它已经防不住这一类攻击了。
误区二：用了大厂 SaaS，安全就是厂商的事。 云安全里有个概念叫责任共担：厂商负责平台本身的安全，用户负责自己的配置。SalesBleed 里平台的漏洞修了，但你的智能体以什么权限运行、Trusted URLs 白名单里加了哪些域名、"回复消息"类动作要不要人工确认——这些全是企业自己的配置决定。同一个平台，配置不同的两家公司，风险敞口天差地别。智能体的权限给得越大，未来任何一条新漏洞的爆炸半径就越大。
误区三：提示注入顶多让 AI 说错话，是内容安全的小毛病。 早期提示注入确实主要体现在"AI 被骗着说了不该说的话"，看起来像恶作剧。但当 AI 连上了真实工具——查数据库、发消息、调 API——注入指令就从"骗嘴"升级成了"骗手"：它能驱动真实的查询、真实的外发。判断一个 AI 应用是被注入骗嘴还是被骗手，就看它有没有工具调用权限。只要有，就该按"远程代码执行"级别的安全问题来对待提示注入。
四、实操指引
给正在用或准备用 AI 智能体的团队（Salesforce 用户可对照执行，其他平台思路通用）：
第一步：给智能体做"最小权限"审计。 列出智能体挂载的所有工具和数据权限，逐项问：它真的需要吗？SalesBleed 的外泄范围恰好等于智能体 Query Records 权限的范围——权限收到只读必需的对象和字段，就算被注入，能偷的东西也有限。智能体通常以某个"服务账号"身份运行，去检查这个账号的权限集，而不是凭印象。
第二步：收紧对外白名单，当资源管理。 平台提供的外部域名白名单（如 Trusted URLs）要当成高敏配置对待：每加一个域名，等同于给智能体开了一条新的数据出口，审批流程应与接入一个新外部应用同级。定期清理不再使用的条目。
第三步：所有对外动作加人工确认。 发消息、发邮件、调外部接口这类"出手"的动作，配置为需要用户逐次确认，并确保消息里带真实发起者的署名。SalesBleed 第三个漏洞的本质就是缺了这两道闸。
第四步：把"不可信数据"当输入隔离。 从公开表单、外部邮件进来的数据，在交给智能体处理前先过一道过滤或标记；有条件的话，让处理外部数据的智能体与查询敏感数据的智能体分开部署，别让同一个助手既收外面的信、又管家里的保险柜。
第五步：盯日志里的异常信号。 重点关注：智能体会话中出现的非常规域名解析、大量新增的子域名请求、智能体以非预期身份发出的协作消息。零点击外泄的痕迹往往就是日志里一条不起眼的 DNS 记录。
给普通职场人的建议只有一条但很实用：对"官方 AI 助手"发的消息保持基本警惕。SalesBleed 告诉我们，智能体的可信身份是可以被冒用的。凡是 AI 助手发来的要求你登录、转账、点链接、扫码的消息，换一个渠道（当面、打电话）跟当事人核实一遍，成本一分钟，能挡住整条攻击链的最后一环。
五、结尾
SalesBleed 三个漏洞都已修复，没有造成实际损失，厂商响应也算迅速——单看结果，这甚至是一次"善意的提醒"。
但它标记了一个拐点：AI 智能体正在把"社工攻击"的战场从人的收件箱搬进机器的上下文窗口。过去我们防的是"人会犯错"，所以要培训；现在还要防"AI 会被骗"，而它没有意识，培训不了，只能靠架构和权限去约束。
如果你所在的公司正在给业务接入 AI 智能体，不妨今天就去问运维同学一个问题：我们的智能体挂了哪些工具权限？ 这个问题的答案，决定了下一个 SalesBleed 砸到你头上时的损失大小。
觉得有用的话，转发给正在搞智能体落地的同事——这些坑，早知道一天就少踩一步。
欢迎在评论区聊聊：你们公司的 AI 助手，权限是怎么管的？