工作流身份劫持：Noma Labs 将一封普通支持邮件变成特权数据访问

2026年9月9日，Noma Security 的研究团队以 Noma Labs 名义发布了一篇关于其所谓“工作流身份劫持”的说明：企业 AI 工作流读取从公共入口——支持邮箱、GitHub issue、网页表单、共享文档——到达的一条普通消息，然后使用自身的高权限服务账号、而不是发送者的权限来执行所请求的工作。Noma 的演示让一名外部人员向公司的公共支持地址发送电子邮件，并在其中要求提供财务总监最近一封邮件中的季度销售数据等内容；几分钟后，这些内容就出现在攻击者的收件箱中。没有模型被欺骗，也没有账号被入侵，这正是报告的重点：“攻击者要做的只是开口询问。”该档案未记录任何实际危害——没有点名受害者，也没有描述任何已部署系统遭到入侵——并将该发现评为研究类，严重性为中等，置信度为 A，争议状态为 false。本报道依据 Noma Labs 的报告、Dark Reading 同日发布的报道以及 CSO Online 的后续报道，而AI 事件档案将这条记录与其相邻条目并列收录，每个条目都有自己的来源、严重性和置信度评级。

在阅读正文之前，值得先看这条记录自身的字段。它被标记为 INFRA 和 EXFIL，覆盖 GLOBAL 区域，带有一个精确到日的日期 2026 年 9 月 9 日，并且未被标记为里程碑条目。该日期仅是研究的发布日期，别无其他；没有附上任何事件时间线，因为不存在可供计时的事件。这是首先要记住的一点：Noma 发布的是一个机制和一个类别，而不是一份泄露事件报告。

Noma 展示了什么，又没有展示什么

支持收件箱序列是一个构建出来的示例，而不是客户案例。Noma 的报告没有点名任何组织，没有给出受影响部署的数量，没有发布来自任何真实流水线的遥测数据，也没有链接针对此场景的概念验证运行——这与该组织 7 月的研究不同，后者指向了一次公开的 GitHub Actions 运行。报告转而提供的，是对该机制的足够精确的描述，可对照架构进行核验：未经身份验证的输入到达，模型正确解释它，流水线执行下游调用，而该调用是以工作流创建者的权限发起的。

Sasi Levi是Noma的安全研究负责人，也是这份报告的作者，她用一句话概括了根本原因：“触发工作流的用户的身份和权限，与执行该工作流所使用的身份和权限是相互解耦的。”报告指出，在这种情况下，工作流就变成了“特权操作的无身份验证代理，以及悄无声息的数据外泄渠道”。

由于这些操作通过具有有效凭据的可信自动化运行，Noma 认为传统告警几乎无从捕捉。请求是正常的，模型输出是有效的模型输出，API 调用已通过身份验证，回复正是工作流构建时所要发送的回复。CSO Online 援引红队成员 Vibhum Dubey 的话，具体说明了检测难题：“单个事件可能看起来完全合法。有用的信号将来自对原始请求者、下游使用的身份、访问的资源、提供的参数以及最终操作进行关联分析。”

失败的检查是授权检查，而不是内容过滤器。

这份报告中最鲜明的例证是一对完全相同的请求。来自一位首席财务官：“财务总监在最近一封邮件中给出的季度销售数据是多少？”来自一位外部发件人：同样的话。Noma 的观点是，提示词和所请求的操作完全相同，而授权决策应当完全不同——“首席财务官有权获得该信息；外部发件人则无权。”

报告认为，标准的提示注入检测器和智能体防护栏会将这两种输入作相同分类，因为两者中都没有可供检测的恶意内容。“安全风险不在提示词中，而在授权边界上。”Noma 的结构性主张由此得出：防护栏、系统指令和输入过滤器“并非为充当授权边界而设计”，因此，如果一个流水线依赖它们来决定调用方可以检索什么，那就是在依赖一项从未被要求承担该职责的控制措施。

这种区分具有实际意义。直接提示注入会操纵模型遵循指令的方式；间接提示注入则把指令隐藏在模型之后会读取的内容中；而按照 Noma 的定义，工作流身份劫持两者都不需要，因为该请求是模型本应理解的，且流水线本应执行的。一个花了一年时间针对注入进行加固的防御者，一直是在另一个层面上工作。

静态工作流不在此番智能体加固推进的范围之内

Noma 区分了两件常被互换使用的事情。AI 工作流是一种预定义、静态的序列，其中模型只是其中一个处理步骤——报告中的简写是步骤 A、模型、步骤 B、步骤 C——而围绕模型的确定性流水线控制着实际发生的过程。智能体工作流则是自主的：由智能体决定采取哪些步骤以及调用哪些工具。报告认为，当前许多安全方面的努力都投入到了第二种工作流上，即为做出动态决策的智能体限制工具访问并限定权限范围，而这些控制措施并未覆盖第一种工作流。

这份报告还堵上了一个明显的漏洞。限制谁或什么能够触发工作流，并不能解决问题：如果某个自动化按计划在早上 8:00 运行，并作用于一个任何人都能写入的收件箱，那么审计“谁能触发这个工作流”就答错了问题。Noma 的规则是，每项自动化都必须由“能够影响其作用对象的最不受信任的一方”来评估——包括电子邮件、表单、工单、GitHub 议题、共享文档和聊天消息。

Noma 称谷歌已修复一个 Google Workflows 案例；谷歌尚未发布任何内容

报告中唯一被点名的平台是谷歌的。Noma 表示，它在 Google Workflows 中识别出了相同的风险向量，以负责任的方式进行了报告，并且谷歌确认收到了该报告并确认了修复，“但未披露实现细节”。这句话就是公开记录的全部内容。无法找到任何描述该向量的谷歌公告、发布说明或 CVE，而且所有关于该修复的二手叙述——包括 9 月 9 日之后几天内发布的那些——都将其归因于 Noma，而不是谷歌。

这份报告在所指的究竟是哪款 Google 产品上也并不完全一致。正文提到的是 Google Workflows；同一份报告中的某个章节标题却写着“Google Workspace：AI 工作流身份劫持”。两者都是 Google 产品，但信任边界不同，而报告并未对二者加以协调。Noma 没有说明其报告的案件是否已被利用、有多少客户受到影响，或修复改变了什么——而由于 Google 什么也没说，这些缺口都无法从厂商一方得到弥补。

GitLost 是同一个边界，只不过是从更窄的视角看到的。

Noma 早先的披露为这类问题提供了先例。2026 年 7 月，该组织发布了一项关于 GitHub Agentic Workflows 的研究，并将其命名为 GitLost：当某个 issue 被分配时，会触发一个工作流，该工作流读取 issue 的标题和正文，并以评论回复；由于该代理拥有对整个组织各仓库的读取权限，外部用户可以利用 issue 分配来访问私有仓库数据。Dark Reading 于 2026 年 7 月 7 日报道了此事，并描述了一名攻击者在公共仓库中打开的 issue 正文里用普通英文隐藏命令，无需任何凭据，也无需编程技能。

这两种表述并不相同，而差异本身才是有意思的部分。Dark Reading 七月的报道讲的是一个提示注入（prompt injection）的故事：由攻击者控制的文本被当作指令来读取。Noma 九月的报告则从触发条件和覆盖整个仓库的读取权限这两个角度来描述 GitLost，并将其呈现为同一个授权边界从某个侧面看到的样子。两种描述都契合这样一种工作流：其中的智能体读取了外部人员写入的文本；但只有较早的那一种描述依赖于模型被引导。Noma 现在表示，它已就同一个风险向量向 Google 作了报告；但它并未说明，GitLost 案例是否曾在已公开的演示之外被实际利用。

Noma 自己对影响力的说法是，Hacker News、Dark Reading 以及 100 多家其他国际媒体都报道了 GitLost 的研究。该数字来自厂商，本文并未独立核对其报道数量。

从业者一致认为该机制历史悠久；争论的焦点在于名称。

独立报道并未对这一发现提出异议，而两位外部从业者质疑的是其新颖性，而非实质内容。BeyondTrust 首席安全顾问 Morey Haber 告诉 Dark Reading：“没有人诱骗 AI 模型去做它本不该做的事。模型完全按照一个陌生人（不可信）的指示行事，而围绕它的工作流使用了别人的身份来实现这一点，因为该工作流既没有被限定范围，也没有按最小权限处理。”CSO Online 援引 Vibhum Dubey 的话，称该模式是“一类已知的授权弱点”，并补充说，当未认证输入能够触发一个以其自身权限行动的受信任工作流时，“该工作流实际上可以充当一个混淆代理”。

Ram Varadarajan，Acalvio 首席执行官，向 Dark Reading 提出了另一种完全不同的控制思路：与其增加更多过滤，不如在环境中布置诱饵——伪造的高管邮件线程、蜜令牌记录——这些诱饵没有任何正当理由会让任何授权工作流去触碰，因此当一个看似无害的请求试图触及其中之一时，就会触发一条它本不该跨越的边界。所谓分歧，其实在于有用的贡献究竟是为一个 1988 年时代的委派缺陷起了个新名字，还是对该缺陷如今所在之处给出了可用的描述。Noma 的立场是后者：这种模式在企业 AI 流水线中是系统性的，而当前的 AI 安全框架关注了错误的层面。

缓解手段是委派和检查点，而不是更好的过滤器。

Noma 推荐的管控措施位于应用层，而非模型层。身份感知的令牌委托意味着从 AI 工作流中移除静态管理 API 密钥，并使用与已认证请求者绑定的短时效、限定范围的委托令牌来执行数据操作，从而让用户上下文传递到真正访问数据的那次调用。上下文授权检查点意味着将每个模型输出都视为不可信输入，并在模型的转换步骤与任何后续数据库或工具调用之间加入显式的访问控制和运行时保护评估。非对称输出分离意味着在结构上将数据检索与外部通信渠道隔离开来，从而使处理敏感内部数据的工作流不会与自动回复外部人员的机制共享执行路径。

Dubey 给 CSO Online 提供了一个比三者中任何一个都更低成本的测试：比较不同权限级别下的结果。“如果低权限用户能获得与管理员相同的结果，因为下游系统只看到工作流的身份，那就会是我重点调查的地方。”

记录留下的未决之处

• 没有受害者，没有计数，也没有遥测数据。Noma 的客服收件箱案例只是一次演示；报告没有点名任何组织，而档案将真实伤害记录为虚假。该机制的合理性并不能证明它已被使用。

• 修复的是哪个 Google 产品，以及修复内容是什么。Noma 的正文称是 Google Workflows，其小节标题却称是 Google Workspace，而 Google 尚未发布任何内容。各组织目前还无法从公开来源判断其运行的某个流水线是否在范围内。

• 该载体是否在任何地方被利用过。无论是该报告还是本文所审查的任何报道，均未描述可归因于工作流身份劫持的已观测到的攻击活动、数据丢失或取证发现。

• 该类别是否经得起实际测量的检验。没有任何独立第三方发布过针对该模式的扫描、受影响流水线的语料库或测试套件；目前流传的证据只是架构层面的论证，再加上某家供应商对某一个已修复案例的说明。

• 谁在提出这一论点。Noma Labs 是 Noma Security 的研究部门，而 Noma Security 销售的正是其报告所建议的那类智能体安全控制措施。这并不意味着该发现就是错的——Dark Reading 和 CSO Online 都报道了它，且均未发现事实错误——但读者在权衡该类别被界定得有多宽泛时，应记住这一背景。

记录中的严重性等级 medium 及其真实危害标记 false 描述的是证据，而非机制。Noma 实际确立的内容既狭窄又可核查：工作流的触发身份与执行身份是两回事，后者通常权限更大，而一条从不比较二者的流水线，会对陌生人做出它原本会为服务对象做的事。随之而来的控制措施相应地并不光鲜——对每个自动化，都要问：谁能影响它所作用的对象，以及下游是否有任何环节会再次核查提出请求的人是否有权提出请求。