企业AI Agent安全危机：54%已遭事故，多数仍共享凭证

AI Agent正在快速进入企业核心业务流程——从自动化客户服务、代码生成到财务审批，它们被赋予越来越高的系统与数据访问权限。然而，一项覆盖107家企业的最新调查揭示了一个令人担忧的现实：安全措施远远跟不上Agent的部署速度。

这份由VentureBeat独家报道的调查显示，54%的企业已经确认发生过AI Agent安全事件或险些发生事故。更令人震惊的是，大多数企业仍然允许Agent共享凭据，只有约三分之一的企业为每个Agent分配了独立的作用域身份，仅有三成企业对其最高风险的Agent实施了隔离。安全栈大部分来自模型提供商和超大规模云商的现成工具，而非为Agent环境专门构建。

共享凭据：定时炸弹

调查指出，超过六成企业仍让多个AI Agent共用同一个服务账号或API密钥。这种复用模式在传统IT环境中尚且危险，在Agent场景下风险呈指数级放大：一个Agent被攻陷，攻击者就能借共享凭据横向移动至所有相关Agent的权限范围。例如，一个用于处理客户查询的聊天Agent若与后端数据库Agent共享凭据，前者的漏洞可立即危及核心数据。

“共享凭据意味着无法确定哪个Agent发起了什么操作，审计基本失效，而且一旦泄露，所有Agent都得更新密钥。” ——调查分析师评论

身份隔离缺失与安全栈外包

只有34%的企业为每个Agent分配了独立、最小权限的身份（如既有的IAM角色或独立的API密钥）。其余企业要么全部使用同一个服务账号，要么仅通过IP白名单等粗略方式限制。这意味着Agent之间的权限边界几乎不存在，一次入侵即可导致“全集群沦陷”。

更令人担忧的是安全工具的构成：82%的企业依赖模型提供商（如OpenAI、Anthropic）的内置安全功能或云平台（如AWS、Azure）的通用安全服务。这些工具虽有一定防护作用，但并非为Agent的自主决策、工具调用、多步推理等动态行为设计。例如，传统WAF无法检测一个Agent在对话过程中突然尝试调用内部API的行为。

高风险Agent隔离不足

调查将Agent按风险等级分类：可以修改数据库、执行运维命令、访问PII数据的被视为“高风险”。然而，只有30%的企业对这些Agent实施了网络微隔离或沙箱环境。其余70%的高风险Agent与其低风险同伴处于同一信任域，一旦被利用，攻击者可借助Agent自身的“工具调用”能力访问敏感资源。

一个典型案例：某企业的代码生成Agent可以访问生产环境，由于未隔离，该Agent被提示注入攻击后，成功读取了云存储中的密钥文件。事后调查发现，该Agent与内部工单系统Agent使用了同一组凭据。

编者按：为何企业在Agent安全上如此迟缓？

AI Agent的安全治理滞后，表面上是因为技术复杂度，根源却在于组织文化、流程和激励的错位。安全团队往往不参与Agent的采购与集成决策；开发团队追求快速上线，对安全控制不熟悉；管理层对Agent能力的认知往往停留在“增强版聊天机器人”，忽视了其自主行动的风险。更重要的是，目前缺乏成熟的Agent安全标准和审计框架，企业倾向于信任模型提供商的承诺，而低估了Agent在部署后可能被篡改或攻击的现实。

要改变这一现状，企业必须将Agent视为具有独立身份的“数字员工”，而非一段代码：每个Agent都应有唯一身份、最小权限、日志审计和动态行为监控。零信任原则（从不信任，始终验证）在Agent世界中同样适用，甚至更为重要。

本文编译自VentureBeat