WorkOS Named to Cyber60: AI Agent Identity Management Becomes a New CISO Focus

From Tools to Actors: The AI Agent Identity Gap Emerges

Enterprise identity management platform WorkOS has been named to the 2026-27 Cyber60 list. The news itself may be just one entry among many in the security industry's list announcements, but the CISO survey data released alongside the list reveals a more structural problem: 77% of enterprises are already running AI agents, yet only 34% have assigned independent identities to those agents.

In other words, more than four in ten enterprises are letting AI agents operate in their systems via some form of "borrowed identity"—whether shared service accounts, temporary access tokens, or simply reusing human employees' credentials. The risks of this approach are not hard to imagine: when an agent's actions cannot be precisely attributed to a specific entity, auditing, permission revocation, and tracing of anomalous behavior all become murky.

WorkOS's inclusion lands it right in the middle of this supply-demand gap. Its original positioning was to help SaaS products quickly integrate enterprise-grade identity capabilities (such as SSO and directory sync), and the demand for agent identity management is essentially the same identity infrastructure extending to non-human actors.

Why CISOs Are Prioritizing Agent Identity

Blind Spots in Traditional IAM Models

Traditional enterprise Identity and Access Management (IAM) systems carry an implicit premise: the subject of identity is a human. Even where service accounts exist, they are typically treated as exceptions for a handful of operational scenarios—broad permissions, loose rotation, coarse audit granularity.

AI agents break this premise. They are numerous, short-lived, have behavior patterns that are not fully predictable, and often need to call across systems. Stuffing them into an account system designed for humans is like using one key to open every door—once an agent is affected by a prompt injection attack or misconfiguration, the attack surface spreads rapidly along the agent's permission chain.

IAM (Identity and Access Management) is a foundational component of enterprise IT security, with a core responsibility to answer two questions: who is accessing the system, and what can they access. A typical IAM system comprises four major modules: the identity directory (such as LDAP, Active Directory), authentication mechanisms (passwords, MFA, SSO), authorization policies (RBAC, ABAC), and audit logs. The design assumption of traditional IAM is that identities are limited in number, long-lived, and relatively stable in behavior—an employee's tenure from onboarding to departure typically spans years.

However, the characteristics of AI agents are the exact opposite: they may be dynamically created in the hundreds or thousands, live for anywhere from minutes to days, and are driven by a combination of prompts and external inputs, introducing considerable uncertainty. More critically, service accounts in traditional IAM are themselves a form of "non-human identity," yet they have never been governed as first-class citizens—most organizations do not even have a complete inventory of their service accounts, let alone fine-grained authorization and regular rotation. When AI agents explode in scale, these legacy shortcomings are rapidly amplified. The industry's emerging concept of NHI (Non-Human Identity) management is precisely an attempt to bring service accounts, API keys, certificates, and AI agents into a unified governance framework, rather than continuing to treat them as appendages of the human account system.

Compliance and Audit Pressure

According to the original report, the CISO survey released alongside Cyber60 uses "whether agents have independent identities" as a core observable metric. The gap between 77% and 34% shows that most organizations' security governance processes have not kept pace with the speed of technology deployment. The shift in CISOs' focus from "whether to use agents" to "what identity agents exist under" is a signal of governance thinking maturing.

Prompt Injection is key context for understanding agent identity risk. Unlike traditional vulnerabilities, prompt injection does not exploit code flaws; instead, it hijacks an AI agent's behavioral logic through carefully crafted input—for example, embedding hidden instructions in web pages, emails, or documents the agent reads, inducing the agent to perform operations the attacker intends. If that agent happens to hold broad cross-system permissions, the attacker effectively gains access through a legitimate identity by proxy.

This also explains why "whether agents have independent identities" became a core metric in the CISO survey: an independent identity means each agent has distinguishable credentials and a minimized permission boundary, so that if one agent is hijacked, the blast radius can be contained and traced; whereas agents with shared credentials or borrowed human accounts, when something goes wrong, will only show up in logs as "some service account did something," with no way to pinpoint which agent, who created it, or what input triggered it. As compliance frameworks such as SOX, GDPR, and China's Multi-Level Protection Scheme increasingly emphasize "attributability," this ambiguity is itself an audit deficiency.

WorkOS's Position and Industry Implications

The significance of WorkOS being named to Cyber60 is not that it proves the success of a single product, but that it represents a class of infrastructure-layer players being brought into the core view of security decision-makers. The technical essentials of agent identity management typically include: issuing distinguishable credentials for each agent, defining fine-grained permission boundaries, supporting automatic credential rotation and revocation, and incorporating agent behavior into unified audit logs.

These capabilities may not sound glamorous, but they are precisely the foundation that must be shored up before AI agents can be deployed at scale. CISOs prioritizing agent identity means security budgets may shift further from "perimeter defense" toward "subject governance."

For SaaS vendors, this is also a product signal: if your product calls or hosts AI agents, your customers' security teams will eventually ask the same question—Who is this agent? Where do its permissions come from? How do we trace it if something goes wrong? Products that cannot answer will find themselves increasingly disadvantaged in enterprise procurement.

SSO (Single Sign-On) and Directory Sync are the two core capabilities WorkOS was built on, and they are key to understanding the logic of its extension into agent identity. SSO lets enterprise employees log in to multiple SaaS products with a single set of unified credentials, backed by standard protocols including SAML 2.0 and OpenID Connect (OIDC); Directory Sync automatically pushes user and group information from enterprise directories (such as Okta, Azure AD) to SaaS products via the SCIM protocol, eliminating the hassle of manual account maintenance.

The value of this infrastructure lies in the fact that it has already established the trust chain between "enterprise identity sources" and "applications." When AI agents need to be brought into governance, the most natural approach is not to build a separate system, but to add a "non-human actor" node type to the same chain—issuing credentials to agents using the OAuth 2.0 client credentials flow or emerging agent identity protocols, syncing agent permission changes through a SCIM-like mechanism, and recording agent behavior in unified logs. This is precisely where vendors like WorkOS have a positional advantage: agent identity management is not a new category built from scratch, but an extension of actor types within existing identity infrastructure.

Implementation Advice: Start by Inventorying Agent Identities

For teams that have not yet started, a pragmatic starting point is an inventory: map out the current list of running AI agents, confirm whether each agent uses an independent identity or shared credentials, and flag instances with overly broad permissions or long-unrotated credentials. This work does not require waiting for a new platform to be procured, yet it can immediately expose risk exposure.

The second step is to bring agent identities into existing identity governance processes rather than building a separate system. The creation, authorization, and expiration/revocation of agents should follow the same approval and audit logic as human accounts. The inclusion of platforms like WorkOS on such lists signals, to some extent, that the market is providing readily procurable solutions for this extension logic.

Agent identity management will not be a short-term hot topic. When a 77% adoption rate meets a 34% governance coverage rate, the gap in between represents the workload security teams must fill for some time to come.

One-line Summary

77% of enterprises already use AI agents but only 34% give them independent identities, making agent identity governance a new security gap.

Paragraph Summary

WorkOS has been named to the 2026-27 Cyber60 list, and the accompanying CISO survey reveals a structural gap: 77% of enterprises are already running AI agents, but only 34% have assigned independent identities to them, with more than four in ten enterprises letting agents operate via shared accounts, temporary tokens, or human credentials. The article notes that traditional IAM systems assume human identities, with service accounts that have overly broad permissions and loose rotation, making them ill-suited to AI agents' characteristics of high volume, short lifespans, and unpredictable behavior—once a prompt injection or misconfiguration occurs, the attack surface spreads rapidly along the permission chain. Agent identity management requires distinguishable credentials, fine-grained permissions, automatic rotation and revocation, and unified auditing, and is infrastructure for AI deployment. The article recommends that enterprises start by inventorying existing agent identities and bring agents into existing governance processes rather than building a separate system.