WorkOS入选Cyber60：AI代理身份管理成CISO新焦点

从工具到主体：AI代理身份缺口浮出水面

企业级身份管理平台 WorkOS 入选 2026-27 年度 Cyber60 榜单，这一消息本身或许只是安全行业众多榜单动态中的一条，但伴随榜单发布的 CISO 调研数据却揭示了一个更具结构性的问题：77% 的企业已经在运行 AI 代理，而只有 34% 为这些代理分配了独立身份。

换句话说，超过四成的企业正在让 AI 代理以某种"借用身份"的方式在系统里活动——可能是共享的服务账号、临时的访问令牌，或者干脆复用了人类员工的凭证。这种做法的风险并不难想象：当代理的行为无法被精确归因到某个具体主体时，审计、权限回收、异常行为追溯都会变得模糊。

WorkOS 此次上榜，恰好踩在了这个供需缺口的正中央。它原本的定位是帮助 SaaS 产品快速接入企业级身份能力（如 SSO、目录同步），而代理身份管理的需求，本质上是同一套身份基础设施向非人类主体的延伸。

为什么CISO开始把代理身份排在前面

传统IAM模型的盲区

过去的企业身份与访问管理（IAM）体系，隐含一个前提：身份的主体是人。即便有服务账号，通常也被当作少数运维场景的例外来处理，权限给得宽、轮换做得松、审计粒度粗。

AI 代理打破了这个前提。它们数量多、生命周期短、行为模式不完全可预测，而且往往需要跨系统调用。把它们塞进为人类设计的账号体系里，等于用一把钥匙开所有的门——一旦代理被提示注入攻击或配置错误影响，攻击面会沿着代理的权限链条迅速扩散。

IAM（Identity and Access Management，身份与访问管理） 是企业 IT 安全的基础组件，核心职责是回答两个问题：谁在访问系统，以及他能访问什么。典型 IAM 体系包含身份目录（如 LDAP、Active Directory）、认证机制（密码、MFA、SSO）、授权策略（RBAC、ABAC）和审计日志四大模块。传统 IAM 的设计假设是身份数量有限、生命周期较长、行为相对稳定——一个员工入职到离职通常跨越数年。

然而 AI 代理的特征恰好相反：它们可能成百上千地动态创建，存活时间从几分钟到几天不等，行为由提示词和外部输入共同驱动，具有相当的不确定性。更关键的是，传统 IAM 中的服务账号本身就是一种"非人类身份"，但它从未被当作一等公民来治理——大多数组织对服务账号的盘点都不完整，更谈不上细粒度授权和定期轮换。当 AI 代理规模爆发时，这套遗留短板会被迅速放大。行业目前提出的 NHI（Non-Human Identity，非人类身份）管理 概念，正是试图把服务账号、API 密钥、证书、AI 代理等统一纳入治理范畴，而非继续把它们当作人类账号体系的附庸。

合规与审计的倒逼

据原始报道，这份与 Cyber60 一同发布的 CISO 调研直接把"代理是否拥有独立身份"作为核心观测指标。77% 与 34% 之间的落差，说明多数组织的安全治理流程还没有跟上技术部署的速度。CISO 群体的关注点从"要不要用代理"转向"代理以什么身份存在"，是一个治理思路的升级信号。

提示注入攻击（Prompt Injection） 是理解代理身份风险的关键背景。与传统漏洞不同，提示注入并不利用代码缺陷，而是通过精心构造的输入内容劫持 AI 代理的行为逻辑——例如在代理读取的网页、邮件或文档中嵌入隐藏指令，诱导代理执行攻击者意图的操作。如果该代理恰好持有宽泛的跨系统权限，攻击者就相当于借代理之手获得了一个合法身份的访问能力。

这也解释了为什么"代理是否有独立身份"会成为 CISO 调研的核心指标：独立身份意味着每个代理都有可区分的凭证和最小化的权限边界，一旦某个代理被劫持，影响范围可以被限制和追溯；而共享凭证或借用人类账号的代理，一旦出事，日志里只会显示"某个服务账号做了某件事"，无法定位到具体是哪个代理、由谁创建、被什么输入触发。在 SOX、GDPR、等保等合规框架越来越强调"可归因性"的背景下，这种模糊性本身就是审计缺陷。

WorkOS的位置与行业含义

WorkOS 入选 Cyber60 的意义，不在于它证明了某个单一产品的成功，而在于它代表了一类基础层玩家正在被安全决策者纳入核心视野。代理身份管理的技术要点通常包括：为每个代理签发可区分的凭证、定义细粒度权限边界、支持凭证的自动轮换与吊销、以及把代理行为纳入统一的审计日志。

这些能力听起来并不炫目，但恰恰是 AI 代理大规模落地时必须先补齐的地基。CISO 把代理身份排在优先位置，意味着安全预算的流向可能从"边界防护"进一步向"主体治理"倾斜。

对 SaaS 厂商而言，这也是一个产品信号：如果你的产品会调用或托管 AI 代理，客户的安全团队迟早会问同一个问题——这个代理是谁？它的权限从哪来？出了问题怎么追溯？ 答不上来的产品，在企业采购环节会越来越被动。

SSO（Single Sign-On，单点登录） 与 目录同步（Directory Sync） 是 WorkOS 起家的两项核心能力，也是理解其向代理身份延伸逻辑的关键。SSO 让企业员工用一套统一凭证登录多个 SaaS 产品，背后的标准协议包括 SAML 2.0 和 OpenID Connect（OIDC）；目录同步则通过 SCIM 协议把企业目录（如 Okta、Azure AD）中的用户和组信息自动推送到 SaaS 产品，免去手动维护账号的麻烦。

这套基础设施的价值在于：它已经打通了"企业身份源"与"应用"之间的信任链路。当 AI 代理需要被纳入治理时，最自然的做法不是另建一套系统，而是在同一条链路上增加"非人类主体"这一类节点——用 OAuth 2.0 的客户端凭证模式或新兴的代理身份协议为代理签发凭证，用 SCIM 类似的机制同步代理的权限变更，用统一日志记录代理行为。WorkOS 这类厂商的卡位优势正在于此：代理身份管理不是从零开始的新品类，而是既有身份基础设施的一次主体类型扩展。

落地建议：从盘点代理身份开始

对于还没动手的团队，一个务实的起点是盘点：梳理当前在运行的 AI 代理清单，确认每个代理使用的是独立身份还是共享凭证，标记出权限过宽或长期未轮换的实例。这项工作不需要等新平台采购完成，却能立刻暴露风险敞口。

第二步是把代理身份纳入现有的身份治理流程，而不是另起一套体系。代理的创建、授权、到期回收，应当和人类账号遵循同样的审批与审计逻辑。WorkOS 这类平台的入选榜单，某种程度上说明市场正在为这套延伸逻辑提供可采购的现成方案。

代理身份管理不会是一个短期的热点话题。当 77% 的采用率遇上 34% 的治理覆盖率，中间那段差距就是未来一段时间安全团队必须填上的工作量。