[控场AI]
· 4 分钟阅读· 2,488 字

AI智能体治理危机:79%企业已部署,仅2%有身份安全管控

AI智能体治理危机:79%企业已部署,仅2%有身份安全管控

79%的组织已在生产环境运行AI智能体,但仅2%部署了身份安全治理工具,发现能力缺失是核心瓶颈。

Forbes分析显示,79%的组织已在生产环境运行AI智能体,但只有2%部署了相应的身份安全治理工具,形成77个百分点的治理缺口。多数智能体没有声明身份、行为边界或权限撤销路径,且已在未正式登记的生产系统上运行,风险远高于传统影子IT。治理的前提是发现,但安全团队在IAM日志分析、网络流量检测和开发者调研等现有手段中都面临显著盲区,从业者普遍对检测能力缺乏信心。更深层的问题在于,企业尚未为AI智能体建立类似人类员工的身份管理体系。文章指出,缩小这一缺口需要为智能体建立涵盖创建审批、最小权限、行为监控和生命周期终止的完整治理基础设施。

一个77个百分点的缺口,正在撕裂企业安全防线

据Forbes本周发布的一项分析显示,79%的组织已在生产环境中运行AI智能体,但只有2%的组织部署了相应的身份安全治理工具。这77个百分点的差距不是规划失误,而是当下企业AI运营的常态。

绝大多数智能体没有声明身份、没有明确的行为边界,也没有在出问题时撤销访问权限的路径。它们已经在生产系统上运行——而这些系统从未被正式登记为它们的可触碰范围。影子IT一直存在,但一台配置错误的服务器是静止的。一个拥有生产数据实时访问权限的智能体,不是。

为什么发现是治理的前置条件

治理链条的起点不是制定策略,而是知道有什么东西在运行。你无法对未被编目的对象进行范围界定、审计或权限撤销。

安全团队在应对常规威胁时已经捉襟见肘。现在还要额外找出那些从未经过任何审批流程就冒出来的智能体,难度呈指数级上升。这里的关键问题是:这些智能体可能由业务部门自行创建、由开发者在测试后遗忘、或由第三方集成悄悄带入,而安全团队对此一无所知。

更棘手的是,智能体不同于传统IT资产。它们没有固定的硬件指纹,可能以API调用、临时容器或服务账户的形式存在,生命周期短、行为动态变化,传统的资产扫描手段很容易漏掉。

非人类身份(NHI, Non-Human Identity) 是理解这一问题的关键概念。传统身份管理假设身份归属于人类员工,而NHI指的是由系统、服务、应用程序或AI智能体持有的数字身份,包括服务账户、API密钥、证书、机器人账户等。据CyberArk等安全厂商的估算,企业环境中NHI的数量通常是人类身份的10到50倍,且大多缺乏集中管理。AI智能体使NHI问题进一步复杂化:传统服务账户的行为模式相对固定,而AI智能体具备自主决策能力,其调用路径和访问范围可能随任务动态变化。这意味着即使企业已有NHI管理实践,也难以直接套用到AI智能体上——后者的权限需求是涌现式的,而非预设式的。

安全从业者的实战方法:IAM日志、流量检测还是人工排查?

在Reddit的相关讨论中,有从业者直接向同行发问:你们实际是怎么发现那些未经批准的智能体的?

目前社区中出现的几种思路包括:

IAM日志分析——通过异常的服务账户创建、权限授予或调用模式反向追踪智能体来源。这是最被看好的方向,但它依赖日志的完整性和集中化程度,而许多企业的IAM日志本身就分散在多个系统中。

网络流量检测——识别非人类身份发出的异常请求模式。挑战在于智能体的流量可能与正常自动化脚本高度相似,误报率难以控制。

开发者调研——直接询问团队是否在正式流程外创建过智能体。这听起来原始,但在缺乏技术手段时往往是唯一能快速摸清底数的方式。

每种方法都有盲区。IAM日志可能被篡改或未开启;流量检测对加密通信和低频调用不敏感;开发者调研依赖诚实和记忆,而这两者都不可靠。

IAM(身份与访问管理) 是企业IT基础设施中负责管理数字身份生命周期和访问策略的系统集合,核心功能包括身份认证、授权、权限授予与撤销以及审计日志记录。主流平台如Okta、Azure AD、AWS IAM等,通常记录每一次身份验证和权限使用事件。在AI智能体发现场景中,IAM日志的价值在于:任何智能体要与生产系统交互,几乎必然会在某个环节留下身份凭证的使用痕迹——无论是服务账户创建、API密钥生成还是角色假设(AssumeRole)调用。然而,IAM日志分析的实效高度依赖三个前提:日志集中化采集、保留周期足够长、以及基线行为建模能力。多数企业在这三方面都存在短板,导致即便有日志也难以从中识别出异常智能体。

信心缺口:没有一种方法能让人真正放心

讨论中最值得关注的不是方法本身,而是从业者对自己检测能力的信心水平。当被问及“你有多大把握能发现那些绕过正常配置流程创建的智能体”时,社区反馈中普遍流露出高度不确定。

这种不自信是有依据的。智能体的创建门槛正在急剧降低,一个开发者用几分钟就能通过API搭建一个能访问内部数据库的智能体,而安全团队可能需要数周才能通过日志分析发现它。速度差决定了主动权在谁手里。

更深层的问题在于,大多数企业还没有为“非人类身份”建立完整的生命周期管理。人类员工有入职、权限审批、离职撤销的流程,但智能体没有。它们被创建时不需要工单,运行时不需要监督,失效时不需要注销。

最小权限原则(Principle of Least Privilege, PoLP) 是身份安全治理的基石,要求每个身份仅被授予完成其任务所必需的最小访问权限。在AI智能体场景中,这一原则面临独特挑战:智能体的任务范围往往在创建时并未被清晰定义,开发者倾向于授予宽泛权限以避免运行中断。更严重的是,当多个智能体共享同一服务账户时,权限实际是叠加的,任何单个智能体的权限边界都无法界定。这使得事后审计几乎不可能——你不能判断一次数据库读取是哪个智能体发起的,也无法在某个智能体行为异常时仅撤销它自己的权限而不影响其他智能体。最小权限不仅是安全最佳实践,更是实现可撤销性和可审计性的技术前提。

从发现到治理:需要补齐的基础设施

要缩小这77个百分点的缺口,仅靠某一种检测技术远远不够。企业需要重新思考几个基本问题:

谁有权创建智能体?在多数组织里,这个问题的答案是“没有明确规定”,等于谁都可以。

智能体以什么身份运行?如果它们借用人类账户或共享服务账户,审计就失去了意义,因为无法区分人和机器。

如何撤销一个智能体的访问权限?如果没有集中的注册表,撤销就意味着逐个系统排查,这在生产环境中几乎不可能实时完成。

这些问题的解法指向同一个方向:为AI智能体建立类似人类员工的身份管理体系——包括创建审批、权限最小化、行为监控和生命周期终止的完整流程。但在此之前,企业得先知道自己的智能体到底有多少、在哪里。

发现,仍然是一切治理动作的前提。而目前来看,大多数企业连这个前提都还没有满足。

#AI智能体治理#身份安全#企业AI部署#非人类身份管理#IAM日志分析#影子IT#智能体发现#生产环境安全
分享:

相关推荐