top of page

Veeam 影子代理危机暴露 AI 治理盲区

9月11日
讀畢需時 15 分鐘

Veeam 表示,受访的 EMEA 组织中有 70% 允许自动化 AI 工作流在缺乏完整监督的情况下与敏感企业数据交互。Veeam 影子代理危机并不只是又一次关于员工使用未经授权聊天机器人的警示,而是关乎能够检索信息、选择行动并转移数据的自主系统,同时这些系统在一定程度上仍未被 IT 团队察觉。

另一项发现同样影响深远。67% 的受访者表示,员工正在创建 IT 无法完全追踪的自主 AI 工作流。这些系统可以将模型、企业数据、软件工具和外部服务连接为持续运行的流程,并会在初始提示之后继续执行。

当前的冲突,发生在快速、分散的 AI 应用与企业用于管理身份、应用和数据的集中式控制之间。传统影子 IT 产生的是未受管理的软件账户。影子代理则在这一熟悉的问题上增加了委托权限、持续性工作流以及机器生成的决策。

Veeam 的研究于 2026 年 9 月 9 日发布,距离欧盟 AI 法案的主要条款开始适用不久。这一时点使运营安全缺口升级为董事会层面的问责问题。组织不仅必须了解员工使用了哪些模型,还必须了解其代理能够访问和改变什么。

该报告并未证明 70% 的 EMEA 企业曾遭受 AI 相关的数据泄露。它衡量的是特定决策者群体自述的监督缺口。但更经得起推敲的结论依然严峻:许多大型组织无法有把握地还原自主 AI 工作流如何与敏感信息交互。

Veeam 的 EMEA 研究实际发现了什么

核心发现是可观测性失效,而非证明整个地区发生了大规模安全泄露。

Veeam 委托 Censuswide 对 1,000 名企业 IT、数据及安全决策者进行了调查。受访者来自英国、德国、法国以及多个中东和非洲市场中员工人数至少为 500 人的组织。Censuswide 于 2026 年 4 月 21 日至 4 月 27 日收集数据。

根据这项 EMEA 调查,70% 的参与组织存在自动化 AI 工作流在未获全面监督的情况下接触敏感数据的情况。另有 67% 的受访者表示,员工创建了 IT 无法完全追踪的自主工作流。

影子代理是指在组织批准的治理流程之外部署或配置的自主 AI 工作流。它可以将模型与工具、凭证、记忆或数据源结合,以完成某项任务。该定义将代理与员工私下在面向消费者的聊天机器人中起草文本的行为区分开来。

这一差异至关重要,因为自主性改变了潜在影响。聊天机器人通常会返回供人审核的内容;代理则可以查询客户数据库、汇总记录、更新工单、发送消息或触发其他服务。

Veeam 在样本中发现了显著的地域差异。在德国,81% 的受访者表示,自动化工作流会在缺乏监督的情况下与敏感数据交互。79% 的受访者称,员工正在创建 IT 无法追踪的影子工作流。

英国同样录得较高的暴露水平。75% 的英国受访者表示,当 AI 代理与敏感数据交互时,其组织缺乏足够的监督。这些国家层面的数据表明,所报告的治理问题并不局限于某一种监管或运营环境。

组织已经在寻求不受限制的全球 AI 服务之外的替代方案。41% 的受访者表示,正专门为应对影子 AI 而构建本地或主权模型。49% 的受访者描述了一种混合模式:针对敏感工作使用本地或主权系统,而针对一般任务使用全球模型。

中东和非洲呈现出不同的模式。当地 41% 的受访者表示,他们在所有使用场景中完全依赖全球 AI 提供商。Veeam 将这一差异解读为,欧洲监管压力正在影响企业架构的证据。

这种解读是合理的,但该调查无法证明监管导致了地区差异。行业构成、基础设施可用性、采购实践及受访者画像也可能影响部署选择。这项研究提供的是有价值的快照,而非受控比较。

因此,Veeam 影子代理危机首先源于一个可量化的可见性缺口。企业部署代理的速度,超过了其安全资产清单、访问审查和数据控制措施的跟进速度。尚未解决的问题是:有多少有害活动已经穿过了这一缺口。

为什么影子代理会带来不同的安全问题

一个未经管理的代理,将不确定的推理能力与可能产生持久后果的系统访问权限结合在一起。

影子软件数十年来一直困扰着安全团队。员工会采用未经批准的应用,因为获批选项不可用、速度缓慢,或不适合其工作。安全团队随后发现未经审查的数据传输、薄弱的保留政策,或不在集中式身份管理范围内的账户。

影子代理可能继承所有这些风险。它还可以决定检索哪些信息、调用哪些工具以及采取哪些行动。这种能力扩大了用户最初意图与系统最终行为之间的差距。

设想一名销售员工创建了一个用于准备客户简报的代理。该工作流可能收集 CRM 记录、电子邮件往来、会议记录以及公开的公司信息,然后在客户电话会议前生成摘要并分发。

生产力收益显而易见。治理问题则会在无人记录该工作流的数据源、凭证、保留行为或输出目的地时出现。一次配置变更就可能暴露客户信息,却不会产生明显警报。

同样的模式也适用于软件开发。员工可能将代理连接到源代码、问题跟踪系统、部署工具和内部文档。一份遭入侵的文档或被操纵的问题单,可能引导该代理执行非预期命令。

NIST 将这一风险称为代理劫持,即间接提示注入的一种形式。攻击者将恶意指令置于代理随后会处理的数据中。代理可能将这类不受信任的内容误认为指令,并采取未经授权的行动。

该机构的劫持研究强调了一项根本性的架构弱点。许多当前代理会将受信任的开发者指令与不受信任的任务数据置于同一个模型上下文中,这使可靠隔离变得困难。

代理风险也不限于恶意输入。模型可能误解目标、选择不合适的工具,或在某项假设不再成立后继续执行。过度权限会将这些普通的可靠性故障转化为安全事件。

这也解释了为何封锁一份公开聊天机器人名单并不能解决问题。员工可以通过获批的自动化平台、云服务、模型 API 或嵌入式助手组装工作流。每个组件或许都获得了授权,但组合后的行为仍未经审查。

“影子代理解释”这一说法听起来可能像是影子 AI 的新标签,但其运营层面的差异在于权限。安全团队必须治理系统能够做什么,而不只是员工提交了什么信息。

因此,身份控制成为核心。每个代理都需要可追溯的身份、范围严格限定的权限、明确的责任人以及有时间限制的凭证。共享用户令牌会使人类操作与自主操作更难区分。

日志记录也需要覆盖完整的决策链。传统应用日志可能记录一次 API 调用,却无法保留其背后的模型输入、工具选择、检索上下文及策略决策。调查人员因此能够看到结果,却无法还原原因。

一个可用的控制系统必须在不收集不必要敏感内容的前提下关联这些事件。这种平衡很难实现,尤其当代理跨越不同供应商拥有的服务时。然而,记录不完整会让安全团队无法检验策略是否有效。

Veeam 影子代理危机本质上是一项控制权衡

主要矛盾在于分散式试验与集中式问责之间,任何一方都无法简单地消除另一方。

员工会创建未经批准的工作流,是因为代理能够从日常工作中消除繁琐的协调环节。市场分析师可以自动汇集营销活动结果并准备简报;运营团队无需等待定制软件,即可分派请求、更新记录并通知利益相关者。

集中审批流程很少能以同样的速度运行。安全审查、隐私评估、采购和架构工作所需时间,可能比构建一个小型代理更长。这种不匹配促使员工将治理视为必须绕开的障碍。

然而,中心团队需要为其未曾授权的结果承担责任。他们必须回答有关数据访问、保留、准确性、事件响应和监管义务的问题。创建有用工作流的人,可能并不知道该代理依赖的是权限范围很广的凭证。

这也是为什么 Veeam 的 AI 治理论点聚焦于数据,而非单个代理界面。Veeam EMEA 总经理兼高级副总裁 Tim Pfaelzer 表示,逐一控制数千个代理无法扩展。他认为,组织应保护并了解这些代理所依赖的数据。

这一论点有其道理。数据分类、访问策略、加密、备份控制和恢复程序可跨多个模型及代理框架适用。数据层面的强控制,能够降低对每个应用都具备完美行为的依赖。

但仅靠数据治理无法控制完整的执行路径。代理或许拥有访问某份文档的合法权限,却可能将其内容用于未经授权的行动;它也可能将多份无害记录组合成敏感情报,或将获批摘要发送至错误目的地。

更强的架构应将数据控制与代理专属限制结合。组织需要限制可用工具、验证高影响行动、隔离不受信任的输入,并在明确边界要求人工批准。它们还需要一份能够显示每个工作流归属的资产清单。

OWASP 的智能体威胁指南围绕权限受损、身份欺骗、不安全的代理间通信和自主滥用等风险归纳了缓解措施。这一框架强化了一个关键观点:代理安全跨越多个既有控制领域。

这种权衡同样影响本地和主权 AI 策略。将模型或其数据处理保留在受控环境中,有助于满足数据驻留要求,并降低对公共服务的暴露。但这并不会自动使由此形成的工作流变得安全。

本地代理仍可能拥有过多权限。它仍可能处理被投毒的文档、向未经授权的同事泄露信息,或执行错误操作。数据主权回答的是处理发生在哪里,而治理则关注谁能做什么,以及在什么条件下可以做。

混合架构带来了另一项挑战。组织可能为敏感信息保留本地模型,同时将全球供应商用于一般任务。分类决策必须在数据跨越这一边界之前完成。

若由代理自主做出这一决策,它可能错误分类提示词或检索到的文档。员工也可能为了方便,将敏感上下文粘贴到全球路由中。有效的混合治理需要可强制执行的路由规则,而不只是书面指引。

因此,企业面临关于摩擦的取舍。打断每一次操作的控制措施会打击合规采用,并使试验活动重新转入暗处。永不打断执行的控制措施,则难以防范高影响错误。

基于风险的审批提供了更可行的折中方案。针对低敏感度材料的只读搜索,可以在轻量监控下运行。会修改财务记录或发送受监管数据的工作流,则应接受更严格的身份验证和人工确认。

这种方法并不会消除控制措施之间的取舍,而是让这种取舍变得明确且可衡量。目标不是零自主性,而是由数据敏感度、操作影响和明确责任人所界定的自主性。

技术清晰度尚未到位,董事会问责已先行

高管正被要求为代理行为承担责任,而许多组织仍缺乏可靠的资产清单。

Veeam 报告称,58% 的受访企业认为自身受新的企业问责法律约束。12% 表示个人责任由多人分担且界限不清。这种组合可能同时造成重复监督和无人负责的风险。

40% 的受访者担忧个人责任或其他后果。39% 表示董事会审查力度加大,37% 描述个人压力或焦虑有所增加。32% 称问责压力已在高管之间引发紧张或冲突。

研究结果也包含一个不那么负面的信号。45% 表示,问责要求提高改善了领导层的一致性与专注度。因此,监管压力可能迫使组织就此前推迟的责任归属作出决定。

这一时间点在欧洲尤为重要。《欧盟人工智能法案》于 2024 年 8 月生效,其中重要条款于 2026 年 8 月 2 日开始适用。欧盟委员会及各国主管机构也从该日起开始行使相关执法权。

根据修订后的时间表,某些高风险系统规则将在之后实施。不过,现有的透明度、禁止性实践和通用人工智能要求已在影响企业规划。AI Act timeline 为企业围绕合规计划组织工作提供了具体日期。

Veeam 发现,受访者在广泛支持监管的同时,也存在明显的不确定性。83% 的受访者预计《欧盟人工智能法案》将带来积极影响。与此同时,62% 认为歧义可能造成合规风险,63% 担心出现意外的运营或法律后果。

英国受访者对歧义的担忧比例达到 74.4%,德国则为 73.6%。英国虽已脱离欧盟,但英国企业仍会通过欧洲业务、客户、供应商和产品分销接触到该法案。

董事会应避免将每一种自主工作流都归入同一法律类别。《人工智能法案》采用基于风险的框架,义务取决于系统、角色、用途和部署环境。低风险内部助手并不会自动承担与受监管高风险系统相同的义务。

实际问题在于,分类需要先完成发现工作。企业无法评估自己不知道存在的工作流。当责任归属、模型沿袭、数据访问和工具权限分散在各部门时,企业也无法形成可信的文档。

这正是 Veeam AI 治理成为问责问题的原因。董事会无需批准每一条提示词,但需要证据证明管理层能够识别关键工作流。董事会也需要确认,高影响代理具备与其权限相称的控制措施。

问责应从决策开始,而不是从口号开始。领导层必须明确哪位高管负责代理风险、哪个团队维护资产清单,以及哪些操作需要独立批准。他们还必须决定,工作流在何时变得足够重大,以至于需要向董事会报告。

指标应揭示控制质量,而不是奖励原始采用数量。统计已部署代理的数量,对安全性说明有限。更有用的衡量方式包括:发现的未识别工作流、移除的过度权限、授予的政策例外,以及根据完整日志重建的事件。

明确的责任归属也能减少防御性行为。如果多名高管认为自己可能承担个人后果,但无人控制完整流程,团队可能会不加区分地阻止有用系统。明确的决策模型允许领导者在商业理由足够充分时接受已记录的风险。

这项调查无法证明什么

Veeam 的发现指出了可信的治理问题,但该研究并未直接衡量入侵、损失或控制有效性。

这项调查由销售数据韧性、安全和治理产品的公司委托。Veeam 表示,Censuswide 独立开展了民调。赞助并不会使结果失效,但读者应区分已测得的回应与赞助方的解读。

样本涵盖 1,000 名大型企业的决策者,并不代表欧洲、中东和非洲的每一家组织。小型企业、公共机构以及尚未形成成熟 AI 计划的公司,可能会报告不同的状况。

自行报告的监督情况也具有主观性。两位受访者可能会对“全面监督”作出不同理解。一个组织可能将不完整的提示词日志记录视为监督不足,另一个组织则可能只将未知工具和凭证的情况描述为监督不足。

“AI 工作流”“自主工作流”和“影子代理”等术语可能涵盖差异很大的系统。定时摘要流程与获授权修改生产基础设施的代理,并不会产生等同风险。汇总百分比并未显示有多少工作流拥有重大权限。

该研究也未披露由影子代理导致的数据泄露的经验证数量。70% 的受访者报告涉及敏感数据,并不意味着其中 70% 遭到了攻击者暴露。缺乏全面监督下的交互是一种风险状态,而非事故结果。

这一差异应影响对标题的解读。“危机”是 Veeam 对可见性缺口的表述。现有发现支持对治理成熟度的担忧,但并未确立由此产生的失败发生频率或财务影响。

尽管如此,独立技术研究仍支持其潜在风险机制。NIST 2026 年的审查发现,受访者普遍认同代理会带来独特的安全担忧。审查还得出结论:既有网络安全实践仍然适用,但需要调整。

agent security review 指出,人们呼吁提供实施指南、信息共享和标准。这项独立工作并未验证 Veeam 的百分比,但表明控制挑战超出了单一供应商的市场定位。

第二项不确定性涉及所提出的补救措施。保护数据能够限制未经授权的访问并改善恢复能力,但代理的行为还取决于模型设计、编排代码、工具、记忆和身份。没有单一控制层能够覆盖完整系统。

因此,组织不应购买一款治理产品后,就认为资产清单问题已经解决。发现工具可能遗漏通过个人账户或监控较弱的自动化服务运行的工作流。随着员工修改提示词、连接和计划,政策也可能发生漂移。

技术测试必须检验真实任务。通用安全评分无法揭示应付账款代理是否能正确处理被篡改的发票。评估应反映实际权限、数据来源、故障模式和反复攻击尝试。

人工批准也不是通用解决方案。审核人员可能对频繁提示产生习惯性反应,在未检查的情况下批准操作。高质量审批需要简明的上下文、可理解的后果,以及切实可行的拒绝或修改操作方式。

因此,这项调查最强的贡献在于诊断。它为董事会和安全团队提供了理由,用以检验其假定的控制措施是否与可观察到的工作流相符。最薄弱的解读,则是将每一项报告的缺口视为已确认的泄露,或将每一个主权模型视为完整的补救措施。

三个将显示治理是否正在追赶的信号

接下来的考验在于,企业能否将担忧转化为资产清单、可强制执行的边界,以及能够经受事件审查的证据。

第一个信号是企业代理资产清单的质量。可信的清单应将每个生产工作流与其负责人、业务目的、模型、数据源、工具集、身份和审批状态关联起来。仅包含应用名称的电子表格无法捕捉不断变化的代理行为。

组织应报告其发现了多少此前未知的代理,以及负责人以多快速度处置这些代理。已发现影子工作流数量的暂时增加,可能意味着可见性得到改善,而非安全状况恶化。更有力的衡量标准是,未解决的高影响工作流是否会随时间减少。

如果企业反复发现拥有敏感访问权限、却不在现有资产清单中的代理,这一信号将强化 Veeam 的诊断。如果发现计划显示,大部分只是已处于有效数据控制措施之后的低影响实验,则会削弱“危机”的表述。

第二个信号是可强制执行的身份和授权标准的出现。代理需要独立于创建它们的员工的身份。权限应反映具体任务,在适当情况下到期,并产生适于调查的记录。

NIST 发起了一项 agent standards initiative,以支持安全、可互操作的采用。围绕通用身份、授权、评估和通信模式取得的进展,将减少每个平台对定制控制措施的依赖。

供应商支持将决定这些标准是否会改变实际运营。企业应关注主要云服务、身份、自动化和模型供应商是否提供兼容的控制措施。没有部署支持的政策语言,只会让团队继续管理碎片化的日志和权限。

如果供应商在代理专属身份和细粒度工具授权上趋于一致,这一信号将强化本文论点。如果普通工作负载身份在真实部署中已被证明足够,同时又不会造成实质性盲区,则会削弱这一论点。

第三个信号是事件证据。安全团队需要发布或分享匿名案例,说明自主工作流如何失效、哪些控制措施阻止了问题,以及哪些记录支持了恢复。在缺乏结果数据的情况下,调查所反映的担忧程度仍难以校准。

事件证据应区分意外泄露、恶意提示注入、权限过度使用以及自主决策错误。每种失效模式都需要不同的应对方式。将它们统统归入“AI 风险”之下,会掩盖哪些投资真正能够减少伤害。

监管机构可以通过明确报告预期并公布执法模式,改善这一证据基础。企业也应审视,与 AI 相关的调查是否能够重建某个智能体的输入、检索到的上下文、工具调用、审批及输出。

治理完善的系统应能够支持这种重建,而无需永久保留每一条敏感提示。团队需要设定明确的保留期限、保护审计记录,并限制对日志本身的访问。若实施不当,可观测性也可能成为另一种隐私风险。

如果调查反复因组织缺乏所有权与执行记录而失败,这一信号将强化 Veeam 关于影子智能体危机的论点。若现有安全遥测数据能够持续支持快速遏制和可靠归因,则会削弱这一论点。

对于企业采购方而言,眼下的行动很直接。询问每个部门:其运行了哪些智能体、这些智能体能够访问哪些数据、又能采取哪些行动。然后将这些答案与身份、网络、云和自动化遥测数据进行比对。

开发者应将智能体权限视为产品设计的一部分。从只读访问开始,将不受信任的内容与指令分离,并在可能造成重要后果的操作前要求确认。在不把日志变成失控数据档案的前提下,保留足够的上下文以解释故障。

知识工作者应默认:便利并不等同于授权。在将工作流连接到电子邮件、文件、客户系统或会议记录之前,应确认组织认可的接入路径。一个有用的个人自动化工具,一旦其凭证或输出绕过审查,便可能带来机构层面的风险暴露。

未来三个月将揭示,市场究竟会以可衡量的控制措施作出回应,还是再增加一层政策文件。请依次关注资产清单、身份标准和事件证据。这些信号将表明,Veeam 识别到的是暂时的采用缺口,还是企业智能体部署中长期存在的特征。

 
 

免费开始使用

一款本地优先的AI助手

为了获得更好的人工智能体验,

remio 目前仅支持Windows 10+ (x64)M-Chip Mac

你的 AI 工作伙伴

remio 一起高效工作

规划、创作、交付

一站式完成

bottom of page