VentureBeat 调查发现，54% 的企业曾遭遇 AI Agent 安全事件，但大多数企业仍在共享凭证

VentureBeat 报道称，54% 的企业曾遭遇 AI Agent 安全事件或险情，尽管大多数部署仍依赖共享凭证。这一发现来自 2026 年 6 月对 107 家员工人数超过 100 人的组织开展的调查。

这一醒目数据合并了两个本应区分的类别。18% 的受访者报告了已确认的事件，另有 36% 报告了在造成损害前被阻止的险情。即使加以区分，结果仍表明，与 Agent 相关的安全故障已不再只是威胁建模中的假设。

更深层的冲突存在于 Agent 自主性与企业控制之间。企业正在将 Agent 接入生产数据、软件工具和业务工作流。然而，只有 32% 的企业为每个 Agent 分配独立且限定范围的身份，仅有 30% 的企业对风险最高的 Agent 进行沙箱隔离。

这种组合挑战了企业中一种常见的假设。许多团队将 AI Agent 视为使用现有服务账户的另一种应用程序。实际上，Agent 可以选择工具、解读不受信任的内容，并执行开发者未预先逐一列明的操作。

其结果是，一个身份问题被包裹在 AI 问题之中。企业在赋予软件更大自主决定权的同时，仍沿用为可预测程序设计的凭证管理方式。安全团队现在必须确定是哪个 Agent 执行了操作、它使用了谁的权限，以及该权限是否与任务相符。

VentureBeat 的 AI Agent 安全调查揭示身份缺口

该调查最重要的发现并非安全事件已经发生，而是凭证设计与事件暴露程度密切相关。

根据这项 Agent 安全调查，18% 的参与企业确认曾发生 AI Agent 安全事件。另有 36% 的企业经历过险情，两者合计得出 54% 这一数字。

42% 的企业表示两类情况均未发生。其余一小部分企业未在生产环境中运行 Agent，或没有跟踪相关事件。因此，该调查描述的是有限企业样本中报告的经历，而非针对所有企业测得的事件发生率。

研究发现，69% 的组织在其 Agent 群体中的某些环节存在凭证共享。只有 32% 的组织表示，每个 Agent 都拥有自己独立、限定范围且受管理的身份。限定范围的身份意味着 Agent 拥有独立账户，其权限仅限于获准执行的任务。

凭证共享表现为多种形式。一些 Agent 使用共用 API 密钥，另一些则借用人类用户或服务账户的凭证。48% 的受访者表示，部分 Agent 拥有独立身份，但许多 Agent 仍在共享凭证。

这些百分比存在重叠，因为受访者可以选择多种身份模式。它们描述的是混合环境，而非彼此排斥的群体。一家公司可能为生产环境中的 Agent 使用限定范围的身份，同时允许实验性 Agent 共享开发账户。

这些环境之间的对比更具启示意义。在存在任何形式凭证共享的组织中，报告安全事件或险情的比例为 63.5%，即 74 名受访者中的 47 名。当每个 Agent 都拥有限定范围的身份时，这一比例为 40.9%，即 22 名受访者中的 9 名。

这 22.6 个百分点的差异表明二者存在关联，但不能证明共享凭证导致了每一起事件。完全采用限定范围身份的组别仅包含 22 家组织。公司规模、Agent 数量、部署复杂度和报告成熟度也可能影响结果。

尽管如此，这种关联背后的机制是可信的。共享凭证扩大了每个 Agent 可使用的权限范围，并削弱了事件发生后的归因能力。安全团队可能看到某个 API 密钥执行了一项操作，却无法得知是哪个 Agent 发起的。

这种风险并不需要高明的攻击者才会出现。Agent 可能误读文档、遵循注入的指令、选择错误的工具，或误解用户的请求。如果多个 Agent 使用同一个高权限账户，其中一个 Agent 的错误决策就能动用该账户附带的全部权限。

共享密钥也会增加遏制事件的难度。撤销密钥可能同时导致多个合法工作流停止运行。由于无法预测哪些生产流程依赖该凭证，团队可能会推迟轮换操作。

独立的 Agent 身份可以提供更清晰的响应路径。安全团队能够停用单个受损身份、检查其活动，并保留不受影响的服务。他们还可以将 Agent 请求执行的操作与其被分配的角色进行对照。

这项调查将 AI Agent 安全事件转化为一个架构问题。企业面对的并非只是在安全模型与不安全模型之间做出选择，而是在决定一个自主系统是否应继续隐藏在颁发给其他实体的凭证背后。

共享 AI Agent 凭证会将错误转化为安全事件

当 Agent 能将错误决策转化为获得授权的操作时，模型错误就会演变为安全事件。

传统聊天机器人通常会返回文本供人审核。AI Agent 则可以调用 API、搜索内部系统、修改记录、执行代码并触发下游工作流。因此，其风险既取决于模型行为，也取决于可用权限。

以一个负责解决账户问题的支持 Agent 为例。它可能需要读取工单、检索客户数据、发放退款，并更新公司的客户平台。每个步骤都需要纯文本助手从未需要过的访问权限。

现在假设工单中包含间接提示注入。这是一种隐藏在 Agent 所读取内容中的恶意指令，例如文档、网页或消息。该指令试图使 Agent 偏离其获准目标。

如果支持 Agent 使用权限过于宽泛的服务账户，注入的指令就可以利用这种继承而来的权限。模型无须绕过身份验证，因为企业已经通过共享凭证为其完成了身份验证。

OWASP 将身份和权限滥用列为其 Agent 应用风险 之一。其框架还强调了目标劫持、工具滥用、记忆投毒和意外代码执行等风险。

这些类别会相互作用。目标劫持会改变 Agent 试图完成的任务。工具滥用为被篡改的目标提供执行路径。过度或共享的权限则决定该操作能够造成多大损害。

这种相互作用解释了为何模型护栏无法承担全部防御责任。护栏可以识别可疑输入或阻止不允许的输出，却无法可靠弥补账户权限超出 Agent 业务角色的问题。

身份控制回答的是另一个问题：这个特定的 Agent 可以执行哪些操作？有效的控制会将 Agent 绑定到独立身份、限制该身份的权限，并记录每项操作背后的授权依据。

当 Agent 委派工作时，这种区别尤为重要。一个协调 Agent 可能要求另一个 Agent 检查源代码或更新工单。如果凭证通过提示、记忆或工具响应传递，接收方 Agent 可能会继承超出其指定职能的权限。

NIST 已将这一问题确定为一项尚待解决的安全重点。其 Agent 身份论文 探讨了软件 Agent 的标识、身份验证、授权、审计、委派和人工审批。

这些要求与成熟的零信任实践相似，但 Agent 行为增加了复杂性。一个 Agent 在执行不同任务时可能需要不同的权限。它还可以汇集来自多个系统的信息，从而改变最终输出的敏感程度。

静态服务账户难以适应这种上下文。即使 Agent 仅在某一个步骤中需要权限，它们也会授予一组固定权限。短期有效、针对特定任务的授权提供了更严格的替代方案。

在该模型下，Agent 仅在指定操作和期限内获得有限访问权限。高影响操作可以要求重新进行策略检查或获得人工批准。凭证会自动过期，而不是一直保留在 Agent 的运行环境中。

清晰的身份还支持不可否认性，即组织可以将一项操作与可验证的执行者和授权链关联起来。若缺乏清晰身份，调查人员可能只知道某个共享账户修改了文件，却不知道是哪个 Agent 请求了这项变更。

这对于知识密集型工作流尤其重要。负责研究内部资料的 Agent 可能会跨越公共文档、机密笔记、客户记录和源代码之间的边界。即使模型生成的回答在技术上准确，权限错误仍可能导致信息泄露。

构建可搜索资料库的组织应保留来源级访问边界，而不是将所有内容扁平化后放入一个不受限制的索引中。受治理的 AI 知识库 可以改善检索效果，但检索权限仍需遵循用户身份和任务要求。

核心结论十分明确。更强的模型推理能力并不会降低身份控制的必要性。能力越强的 Agent 可以使用越多工具，这也使限制每项操作并明确其归属变得更加重要。

随着企业风险敞口扩大，仅 30% 的企业对高风险 Agent 进行沙箱隔离

身份控制限制 Agent 应该访问的内容，而沙箱隔离则限制这些规则失效时可能产生的后果。

VentureBeat 的调查发现，仅有 30% 的企业将风险最高的 Agent 隔离在沙箱中。沙箱是一种受限执行环境，旨在约束代码、文件、网络访问和系统变更。

沙箱隔离并不会让 Agent 变得可信。它可以在模型出错、工具行为异常或攻击者改变工作流方向时缩小影响范围。该控制措施假设预防性过滤器最终总会遗漏某些问题。

调查还发现了一个令人担忧的公司规模趋势。在员工人数为 101 至 1,000 人的组织中，报告安全事件或险情的比例为 49%；而在员工人数超过 1,000 人的组织中，这一比例上升至 63%。

与此同时，较小规模组织对高风险 Agent 的沙箱隔离率为 35%，而大型企业仅为 20%。拥有更多系统和更高集成复杂度的组织报告了更多事件，却采取了更少的遏制措施。

多种因素都可能导致这种趋势。大型企业通常运行着老旧应用、相互重叠的身份系统和大量服务账户。Agent 项目也可能在各部门间扩散，其速度超过中央安全团队清点这些项目的速度。

生产环境集成使隔离变得更加困难。编码 Agent 可能需要访问代码仓库、测试基础设施、软件包注册表和部署系统。阻止一切外部操作的沙箱会使工作流失去意义，而不受限制的访问又会违背遏制风险的初衷。

切实可行的答案并不是使用一个通用沙箱。组织需要根据 Agent 的角色设置相匹配的边界。研究 Agent、编码 Agent、财务 Agent 和客户支持 Agent 不应共享同一套执行策略。

编码智能体可以在带有临时仓库分支的短暂环境中工作。它可以运行测试，但无权合并代码或更改生产环境设置。单独的审批步骤可以授权部署。

财务智能体可以准备交易，但不提交交易。其沙箱可以阻止未知的网络目标并限制文件导出。人工审批者可以在执行前核实收款方、金额和支持记录。

研究智能体可以浏览获批来源，同时无法访问本地机密和无关的内部仓库。任何下载的内容在经过扫描并通过受控工具处理之前，均应保持不受信任状态。

这些边界针对不同的故障模式。网络限制可以防止数据外泄。文件系统隔离可以遏制恶意代码。工具允许列表可以阻止智能体调用与其指定任务无关的功能。

速率限制和交易上限增加了另一层保护。它们限制智能体重复错误操作的速度。影响一条记录的错误仍然可以恢复，而同样的错误若波及数千条记录，就会演变为运营事故。

人工审批的位置也需要精心设计。要求每个低风险步骤都经过审批，会大幅削弱智能体的价值。只有在智能体采取不可逆操作后才要求审批，则会让这项控制失去意义。

有效的检查点应位于重大边界之前。例如，发送外部消息、发布代码、删除数据、更改访问权限或承诺资金。界面应显示预定操作和所请求的权限。

日志必须记录最终模型输出之外的更多信息。调查人员需要了解发起用户、智能体身份、模型和策略版本、工具请求、授权决定以及由此产生的系统变更。敏感提示词可能需要脱敏，但操作轨迹必须保持可用。

安全团队还应保留一个终止开关，用于禁用智能体的有效凭据和工具访问权限。该开关需要经过测试，因为仪表板上的切换按钮并不能保证缓存令牌或委托会话已经过期。

因此，遏制能力是一项系统属性，而不是模型设置。它取决于运行时基础设施、凭据设计、策略执行和恢复程序。提供商过滤器可以支持这种设计，但无法取代它。

提供商防护措施占据主导地位，但专用智能体安全仍然罕见

尽管 AI 智能体带来的风险横跨多个模型、云平台和业务系统，企业仍在依赖熟悉的平台控制措施。

VentureBeat 发现，模型提供商和云原生安全工具在当前部署中占据主导地位。51% 的受访者使用 OpenAI 防护措施，与 Google、Microsoft 和 Anthropic 相关的控制措施也位居前列。

专用 AI 智能体安全产品的采用率非常有限。这表明，企业最初选择扩展现有平台控制，而不是为智能体构建或购买独立的安全层。

这种选择可以理解。提供商控制措施靠近模型请求，可以检查提示词、输出、工具定义和使用模式。它们也能减少早期部署所需的集成工作。

当工作流跨越多个平台时，局限性就会显现。企业智能体可能使用一家提供商的模型、另一家云服务商的数据库、第三方搜索服务以及多个内部 API。任何单一模型提供商都无法看到完整的授权链。

提供商控制措施也主要关注其运营的技术栈部分。它们可能识别不安全内容或可疑工具调用，但企业仍需负责身份生命周期、数据分类、审批策略和事件响应。

在完成所有评分问题的 82 名受访者中，调查记录的平均满意度为 4.2 分（满分 5 分）。然而，明显多数的受访者计划在下一年内更换或增加工具。

高满意度与计划更换并不一定矛盾。当前工具可能在试点部署中表现良好，但随着智能体数量和权限增长而变得不足。受访者也可能对单个产品感到满意，却担忧产品之间的空白。

不应将工具市场视为唯一答案。专用安全软件可以改善智能体发现、策略执行和运行时监控。它无法解决业务归属不明确或无人遵守审批流程的问题。

独立行业研究进一步印证了可见性问题。2026 年 4 月的一项企业智能体调查报告称，82% 的组织曾在其环境中发现未知的智能体或工作流。

该调查由一家安全供应商委托开展，其受访者和定义与 VentureBeat 的研究不同。其 65% 的事件数据不应与 VentureBeat 的 54% 合并使用，仿佛两者衡量的是同一总体。

两项研究呈现的趋势仍然一致。企业对智能体部署的可见性不完整，安全事件报告也十分常见。不同样本得出了不同百分比，但两者所描述的都不是一个成熟的控制环境。

Cloud Security Alliance 的研究还将许多智能体描述为处于身份灰色地带。它们既没有被完全作为人类用户管理，也没有被作为一等机器身份管理。

这种模糊性给多类成熟供应商带来了压力。身份提供商必须支持动态智能体身份和委托权限。云平台必须提供精细的运行时控制。模型提供商必须让企业系统中的工具活动可被观察。

安全信息与事件管理供应商面临另一项挑战。传统日志会记录身份验证和 API 调用，但可能无法捕获智能体的任务、委托权限或推理上下文。有效的 API 调用仍然可能代表无效的业务操作。

智能体安全专业厂商可以针对这些缺口提供解决方案，但买家应要求互操作性。仅适用于单一模型或编排框架的控制层可能制造另一个可见性孤岛。企业需要能够经受提供商变更的策略。

它们还需要证明专业工具可以改善结果。VentureBeat 的研究属于横断面研究，因此无法说明某款特定产品是否减少了事件。专用产品的采用率过低，无法进行有意义的比较。

这让企业在短期内面临一个令人不安的现实。它们不能等待智能体安全类别完全成熟，但购买更多软件并不会自动建立可问责的身份或安全的执行边界。

眼下的工作仍然是架构层面的。盘点智能体、明确归属、签发独立身份、收紧权限、隔离执行并定义审批点。工具选择应遵循这些控制要求。

54% 的 AI 智能体安全事件数据不能证明什么

这项调查是一个严肃的警示信号，但其样本和类别定义不足以支持有关企业安全事件率的普遍性结论。

该研究在 2026 年 6 月的一轮调查中覆盖了 107 家组织。受访者所在公司的员工人数均超过 100 人，样本偏向中端市场组织。

42% 的参与者来自拥有 251 至 1,000 名员工的公司。另有 25% 来自拥有 101 至 250 名员工的组织。技术和软件行业是最大的行业群体，占 23%。

角色构成同样重要。45% 的受访者自称是 AI 采购的最终决策者，30% 则称自己是建议者或影响者。管理人员占受访者的 43%。

这是一个自我选择样本，而非概率样本。调查结果应被视为来自参与企业的方向性证据。它们无法为所有美国企业提供具有统计代表性的估计。

合并计算的 54% 数据还包括险情。险情可能表明控制措施发挥了作用，因为组织发现并阻止了问题。它并不等同于已确认的安全事件、数据丢失或财务影响。

与此同时，排除险情会掩盖有意义的运营风险。被阻止的尝试或侥幸避免的错误揭示了一条在不同条件下可能成功的路径。反复出现的险情可以在破坏性事件发生前暴露脆弱的控制措施。

该研究并未明确每位受访者将哪些情况计为 AI 智能体事件。一家组织可能报告未经授权的数据访问，而另一家可能将失败的生产操作计入其中。统一的行业定义仍在制定中。

报告成熟度也可能逆转公司之间的表面比较。拥有详细监控的组织可能会比可见性较弱的公司发现更多险情。因此，更高的报告发生率可能反映了更好的检测能力，而不只是更差的安全状况。

凭据对比也存在类似限制。使用共享凭据的组织报告了更多事件，但该研究并未将凭据共享与规模或复杂性区分开来。拥有更多智能体的公司可能既共享更多密钥，也经历更多事件。

因此，读者不应将 63.5% 与 40.9% 的差异解读为因果保证。为每个智能体分配身份并不能防止提示词注入、不安全的工具设计、遭到入侵的依赖项或恶意内部人员。

独立身份仍然很有价值，因为它可以收紧权限并改善归因。它是一项基础控制措施，而不是完整的安全方案。沙箱、监控、评估、审批和事件响应仍然不可或缺。

这项调查也不能证明提供商原生工具无效。受访者对这些工具的满意度很高。更站得住脚的结论是，提供商控制措施与广泛存在的身份和遏制缺口并存。

一家公司可以使用功能强大的模型防护措施，同时维持薄弱的服务账户管理实践。它也可以拥有先进的监控软件，却没有隔离高风险执行。安全结果取决于这些控制措施如何协同工作。

这种细微差别很重要，因为恐惧可能会促使组织采取错误的应对措施。全面禁止可能会将智能体推向未经批准的使用方式，进一步降低可见性。然而，不受限制的部署则会将实验性假设带入生产系统。

基于风险的模型提供了一条更合理的路径。对公共数据执行只读操作的智能体，与能够修改客户记录或生产基础设施的智能体，需要采用不同的控制措施。权限应反映故障可能造成的后果。

组织应根据可逆性和影响对智能体操作进行分类。读取公开文档的后果较小。发送受监管数据、更改访问权限、执行代码或转移资金则需要更严格的授权。

它们还应将模型评估与安全测试区分开来。评估衡量智能体是否正确完成任务。安全测试则检查恶意内容或意外情况能否改变该任务的方向。

智能体可能在内部基准测试中得分很高，却仍会在间接提示词注入下失效。相反，智能体也可能因为防护措施过于严格而过度拒绝合法请求。这两种结果都需要衡量。

因此，VentureBeat 的这一数据应当出现在风险登记表中，而不是营销幻灯片上。它表明，真实企业正在遭遇智能体故障，而基础控制措施仍参差不齐。它并未指出某一种能够彻底消除问题的产品或政策。

三个信号将表明企业是否正在缩小差距

AI 智能体安全的下一阶段将通过身份覆盖率、遏制率和独立报告的结果来衡量。

第一个信号是拥有唯一且受管理身份的生产环境智能体所占比例。企业应报告整个智能体集群的覆盖率，而不仅仅是新批准的项目。如果这一比例从当前的 32% 上升，就表明身份管理计划正在覆盖部署团队。

更有力的指标应将身份覆盖率与权限质量结合起来。一个拥有广泛永久访问权限的唯一身份，不过是改了名称的服务账户。要取得进展，就必须采用范围受限的权限、短期凭证和明确记录的归属责任。

应关注身份供应商和云平台是否支持任务级委派。重要的功能并不是管理控制台中新增加一个“智能体”标签，而是能够仅针对某项操作授予有限权限，并将该权限追溯至具体用户或政策。

NIST 的智能体标准倡议提供了另一个指标。针对身份识别、授权、审计和安全委派制定具体规范，将进一步证明可互操作的企业控制措施具有可行性。

第二个信号是高风险智能体的沙箱使用情况。VentureBeat 给出的 30% 基准意味着，大多数影响重大的部署尚未报告采用隔离措施。这一比例上升将表明，组织正在以故障必然发生为前提进行设计，而不是完全依赖预防。

购买方不应只关注供应商关于沙箱可用性的说法。真正有用的问题是，究竟有多少生产环境智能体实际运行在强制执行的边界内。安全团队应测试这些边界能否阻止未经授权的网络调用、文件更改和凭证访问。

测试应包括间接提示词注入和遭到入侵的工具响应。如果沙箱只有在模型遵循指令时才能正常发挥作用，它就无法提供独立的遏制能力。即使智能体的目标已被重定向，该边界也必须依然有效。

第三个信号是未来的调查是否会区分已确认事件、被阻止的攻击、模型错误和险情。更完善的分类将揭示哪些控制措施能够减少业务损害，哪些只是提高了检测能力。

在条件允许的情况下，组织应发布匿名化的事件模式。分享有关工具遭到入侵、权限过大、凭证泄露和审批失效的经验教训，将有助于购买方根据真实行为评估控制措施。

独立报告将非常重要，因为当前许多研究由安全供应商委托开展，或由科技媒体发布。这些来源可以揭示重要模式，但透明的方法论和重复测量将使趋势判断更加可信。

事件率下降并不一定能证明情况有所改善。组织检测到的事件可能减少，是因为可见性变差了。更具说服力的趋势应同时包括更全面的智能体清单、更高的身份覆盖率、更强的遏制能力，以及更少的重大后果。

相反，随着监控能力提升，报告的险情数量可能会上升。如果已确认的损害减少且响应速度加快，这种增长可能意味着短期进展。安全指标需要结合上下文理解，而不能只看一个引人注目的百分比。

企业领导者应首先提出一个具体问题：组织能否识别每一个生产环境智能体，以及它的负责人、凭证、工具和最大可能操作？任何缺失的答案都意味着存在一个未受管理的控制边界。

54% 的 AI 智能体安全事件及险情数据，使这份清单的建立变得十分紧迫。它表明，在部分市场中，部署速度已经超过了身份管理和遏制实践的发展速度。

对于在研究和知识工作流中使用智能体的团队，同样的准则也适用。将敏感来源限制在明确的访问边界内，保留出处信息，并审查任何将信息移出其预期上下文的操作。一个可搜索的知识库应在不削弱权限控制的前提下改善访问体验。

未来三个月应能看出，企业会以可衡量的控制覆盖率作出响应，还是只会增加一层安全营销包装。请向部署团队索取每一个生产环境智能体的身份和沙箱状态。如果这些记录不存在，请先建立清单，再授予更多自主权。如果记录已经存在，则应测试一个遭到入侵的智能体能否借用另一个工作流的权限。与防护栏仪表板或政策文件相比，这一问题的答案更能说明组织是否已做好准备。