SalesBleed：一条销售线索怎样带走 CRM 数据

1 存进 CRM 的文字，仍然来自填表人

Salesforce 的 Web-to-Lead 可以把网站表单转成销售线索。它解决的是收集与分配问题。表单里的公司介绍、需求描述等文字由来访者填写，进入 CRM 以后仍保留这个来源。默认启用的 reCAPTCHA 有助于减少垃圾提交，无法替业务系统判断一段需求描述是否正在指挥助手。

间接提示词注入就发生在这里。员工给出正常任务，代理随后读取一份包含外部文字的材料；材料中有一部分内容被代理当成了接下来应执行的指令。攻击者不需要成为正在聊天的那名员工，也不需要先拿到员工的账号。在这次研究中，员工处理线索的正常请求，把存放在线索里的文字带进了代理当前的上下文。

下一步为什么能查到别的资料？Agentforce 的标准动作 QueryRecords 接受自然语言查询条件，可以查询支持的标准对象与自定义对象。它既可能用于找 Lead，也可能用于另一次 Account 查询。Zenity 的数据外发报告说明，其测试使用的 General CRM 子代理具备完成这两次读取的查询能力。代理只要偏离当前任务，使用运行身份已经具有的读取能力，就可能接触这次工作不需要的数据。

这些读取仍受运行身份的权限约束。官方动作权限说明区分了执行场景：员工在 Lightning、移动端和 Slack 使用代理时，数据访问受最终用户上下文约束；客户服务代理的身份与访问方式另有规则。因此，排查时要找到实际运行身份、可用动作和对象权限。外部填表人的身份，与后来处理记录的员工身份，需要分别记录。

2 回复显示出来之前，地址已经有了用途

查到的数据还留在系统内部时，外部填表人未必能看见。SalesBleed 的下一步，是让回复中的地址携带这些数据。地址可以出现在图片引用里，也可以作为 Slack 会自动展开的链接。前一种由显示图片的客户端处理，后一种由 Slack 的预览服务处理；二者都可能在读者额外点击之前发起网络活动。

Salesforce 已有一项输出保护：不在允许范围内的 URL 会被替换成 URL_Redacted。Zenity 发现，旧识别器只认固定的一组顶级域，未列入的合法后缀会被漏掉，例如研究中的 .fun。花括号、方括号等字符又让检查器与后续渲染程序对地址在哪结束产生不同判断。于是，检查器漏掉的文本仍可能被后者当成地址使用。厂商没有公开内部实现与补丁代码，本文能够核对的是研究者展示的行为、修复确认和现有产品文档。

下面这个无害例子可以帮助理解“看起来不规整”和“无法解析”之间的差别。SOSEC 在 Node.js v24.19.0 离线运行了以下代码，只调用 URL 构造器，没有解析 DNS 或访问网站：

const value = new URL('https://demo.example.invalid/{note}');
console.log(value.hostname); // demo.example.invalid
console.log(value.pathname); // /%7Bnote%7D

解析器保留了主机名，把路径中的花括号编码了。一个只检查某些地址形状的过滤器，与真正使用 URL 的程序，可能因此得出不同判断。这个例子只验证本地解析语义；它没有运行 Agentforce，也没有测试当前 Salesforce 过滤器。修复此类问题时，需要检查所有会使用输出的程序接受什么输入，再让允许规则覆盖同一含义。

为什么研究特别强调 DNS？通常在连接一个主机之前，程序要先查询它的地址。若待发送的数据被放进主机名，查询名称本身就包含了这些数据。按照 DNS 的解析过程，查询可能由缓存回答，也可能被网络控制阻止；一旦它到达攻击者控制域名的权威服务器，名称里的内容便已越过系统。后面的 HTTPS 连接是否成功，无法收回这次 DNS 查询已经带走的字符。

请求从哪里发出，会直接影响排查位置。浏览器加载图片时，可以观察终端和浏览器的网络记录；Slack 生成预览时，请求来自 Slack 的服务，企业终端上的浏览器日志覆盖不到那次访问。只看员工有没有点链接，或者只找目标网站是否返回了成功页面，都会漏掉这一段。

因此，“零点击”在这里有一个具体含义：研究路径在员工发起正常查询之后，不再依赖额外点击恶意链接。员工读取线索、代理具备相关查询能力、输出进入能够处理地址的界面，这些条件仍然存在。某个部署关闭了图片或预览，也只能排除对应的输出分支，不能据此替其他客户端作结论。

3 Slack 预览链接，与代理发消息是两件事

自动预览会处理一条已经出现的链接。主动发消息还需要写入能力：代理要能选择会话、目标线程和消息内容。Salesforce 的 Slack 集成文档在 Slack Knowledge 能力中列出查询消息、回复线程和发送私信等不同动作，管理员可以按工作需要配置。一个只读 CRM 的代理，并不会因为能生成文字就自动获得全部 Slack 动作。

Zenity 的第二份报告指出，其测试时的 Reply to a Slack Thread 缺少执行前确认和接收者可见的触发者归属；作为比较，Send a Slack Direct Message 当时已有这两项。研究演示既讨论能调用代理的内部人员，也讨论外部线索进入一个同时具有 CRM 读取和 Slack 写入能力的流程。外部材料要影响发消息，仍须走到具备这些动作的代理，不能把它扩大成任意表单都能向任意 Slack 发消息。

这两个缺口处理的是不同问题。确认让操作者有机会在消息离开前看到目标和内容，并取消动作；触发者标记让接收者知道是谁调用了代理。后者帮助理解消息来源，却不等于那个人仔细批准了消息里的每句话。公开报告展示的是用户可见归属，我们没有据此推断厂商内部完全没有审计记录。

把这点落实到界面时，确认框至少要让人看见即将发送到哪个会话、哪条线程，以及完整的最终文本。只显示“是否执行动作”，检查价值很有限。若确认后还能改变接收者或正文，先前的同意也没有覆盖最终操作。这些是 SOSEC 对动作设计的建议，具体产品是否已满足，需要用实际配置验证。

确认也会带来操作成本。频繁发送常规通知的团队可能希望关掉它，减少一步点击。对这种稳定任务，我们更倾向于先固定收件范围、内容结构和可用数据，再评估自动发送。开放式读取 CRM，再任意组织 Slack 消息，是另一种风险水平。关闭确认会撤掉发送前的检查机会，但这个设置变化本身不会让已经修好的 URL 识别问题重新出现。

4 云端修复之后，还要看租户实际在用什么

SalesBleed 没有一个供管理员下载的统一固件版本。Zenity 的分项时间线记录了三个节点：8 月 19 日确认 URL 绕过修复，8 月 20 日确认 Slack 触发者归属修复，9 月 21 日确认全部相关修复。我们采用这份分项记录；部分新闻把修复时间概括成 8 月 19 日，会漏掉后续 Slack 改动。当前应该核对的是正在运行的 Agentforce 动作与组织设置，并让厂商确认租户适用的修复状态。

从刚才的数据流回头看，最早可以收窄的是读取。把“整理这条线索”实现成只接受已选 Lead ID、只返回所需字段的动作；若业务确实要关联历史客户，就把关联条件写进可核验的 Flow 或代码。这样，代理收到新指令时，可调用的接口仍围绕当前记录工作。这个建议会减少自由查询的灵活性，适合任务稳定、数据敏感的流程；需要开放式分析的助手，则要为更宽的读取范围增加相应的输出检查。

接着看写入动作。逐项检查现有代理是否需要回复 Slack 线程、发私信或执行其他外部写入，确认开关是否保留。Agent Script 文档中的 require_user_confirmation 表示执行动作前要求确认；这说明产品提供了相应控制，但文档本身不能证明某个正在使用的动作已启用它。旧代理、复制出的动作和人为改过的设置，都应以实际运行结果为准。

然后检查地址允许范围。Salesforce 的当前 Trusted URLs 说明有一个容易被旧教程掩盖的变化：从 2026 年 2 月 28 日起，默认允许列表移除了 *.salesforce.com。添加业务地址时，应核对准确域名和用途；不要为了让一条被隐藏的链接重新显示，就补回宽泛通配规则。组织设置以及代理指令中可能存在的 URL 允许配置，都值得一起盘点。

这里还要分开“允许出现在回复里”和“允许发起网络访问”。Salesforce 的输出处理、网页的内容安全策略、浏览器图片加载与 Slack 的预览服务，各自控制一段行为。一个地址通过某处允许列表，并不能说明它携带的查询参数或主机名适合对外发送。对于没有业务价值的外部图片、动态生成地址，应优先去掉对应输出能力；确实需要的链接则固定目标和参数来源，避免把任意 CRM 字段拼进地址。

如果团队维护自己的 Slack 应用，官方链接预览文档提供了两个独立字段，用来关闭文本链接和媒体预览：

{
  "unfurl_links": false,
  "unfurl_media": false
}

这是自建应用发送消息时可用的 API 控制，不能直接假定 Agentforce 的内置动作把这两个字段交给管理员设置。使用内置连接器时，需要核对它实际提供的选项以及发出的消息行为。若无法控制预览，先限制代理可生成的链接和可执行的发送动作，会比只在员工电脑上拦截更接近问题发生的位置。

暂时无法确认修复或设置时，可以暂停受影响代理处理外来线索，或移除不需要的 Slack 写入动作。这样会中断相应自动分流、整理或通知，人工流程需要接手。Web-to-Lead 仍可按业务需要收集记录，待检查后再交给代理。不要一边恢复服务，一边把为了排错关闭的确认和限制原样留着；恢复条件应包含正常业务可用、非必要动作受限，以及输出按预期处理。

5 用一条完整任务检查修复

配置页面只能告诉人们开关的位置。它不能独自回答代理执行时读了什么、给谁发了什么。我们建议在授权测试环境里，用虚构业务数据走完一次线索处理，把原始记录、动作输入输出、最终回复和界面产生的请求放在同一条会话里看。下面是按公开机制提出的验收方法，SOSEC 未在 Salesforce 租户中执行它。

先保留一条正常对照：一条没有指令性文字的测试线索，应能得到准确摘要，所需字段可用，原来的业务流程可以完成。再检查任务范围：当前流程只需要某条 Lead 时，关联动作能否读到无关 Account；若业务必须支持这种读取，就记录实际条件，避免把“没有在这次回答里显示”误记为“读取被阻止”。

随后把显示和发送分开验证。显示一条只含测试数据的回复时，浏览器是否自动加载图片，Slack 是否生成预览，要分别观察。测试域名必须由组织控制，日志只保留合成标记；不要用真实客户信息验证外发。发消息则检查取消、批准和归属三个结果：取消后消息没有离开，批准内容与最终内容一致，接收者能辨认触发者。一次浏览器检查覆盖不了 Slack 的服务端请求，一次线程回复检查也覆盖不了其他写入动作。

Salesforce 的会话追踪可以按会话组织交互、动作、输入输出与错误，适合沿这条任务查找偏离发生在哪一步。启用条件、实际留存和访问权限需要先核对。追踪本身可能包含敏感业务内容，不应为了方便排查就向所有管理员或外部支持方开放完整记录。

如果正在调查已有异常，优先保存可疑线索的原文、来源和修改时间，以及相关会话、动作、回复、Slack 目标和可取得的网络记录。CRM 中残留的指令性文字可能在下一次被读取时再次影响代理，应在保全后隔离其自动处理。已经发送出的数据或消息需要单独处置；关闭动作可以阻止后续使用，无法收回收件方已看见的内容。

日志不足时，结论也要停在能查到的位置。未启用会话追踪、记录已过留存期、Slack 预览发生在企业网络之外，都会留下不同的空白。可以明确说哪段历史无法重建，同时继续收紧当前流程。厂商在披露时的“没有发现客户遭利用”，也不代替某个组织对自身记录的检查。

6 让助手的能力跟着任务增长

SalesBleed 让一个很实际的部署问题变得清楚：员工希望少做几次查询、少复制几段文字，代理因此获得了读取资料和整理输出的能力。每增加一个动作，都应能说清它为当前工作解决什么问题，以及结果交给谁处理。对于“整理一条销售线索”这种任务，先限制到这条记录，保留可靠的摘要和人工跟进入口，已经能提供价值。等业务确实需要跨对象查询或自动发送，再为那一步加上可检查的输入、明确的接收者和合适的确认。这样的助手更容易用，也更容易在出事时查明它究竟做了什么。

7 参考资料

1. Zenity：Agentforce 数据外发研究与修复时间线，2026-09-24
2. Zenity：Slack 动作确认、归属与分项修复，2026-09-24
3. SecurityWeek：报道及 Salesforce 回应，2026-09-25
4. Salesforce：Web-to-Lead；Query Records
5. Salesforce：动作身份、权限与数据保护
6. Salesforce：Trusted URLs 当前设置与 2026 年通配域变更；2025 年 URL 隐藏功能说明
7. Salesforce：Agentforce 与 Slack 动作；Agent Script 动作定义与确认字段
8. Slack：链接及媒体预览
9. Salesforce：Agentforce 会话追踪
10. Node.js：WHATWG URL 解析接口；RFC 1034：解析器算法