Enterprise IAM has a problem it hasn’t quite come to terms with yet. For decades, identity and access management was a human-centric discipline. Someone joins the company, gets an account, and receives permissions. If you’re lucky, those permissions are reviewed before retirement. The entire machinery of IAM, from user provisioning workflows to access certifications, was designed on the premise that identities belong to people.
That premise is now outdated.
The Identities That Nobody Manages
The most significant shift in enterprise identity over the past few years has nothing to do with passkeys, zero trust, or even the latest identity governance platform. It’s the quiet explosion of non-human identities. API keys, service accounts, bot credentials, microservice tokens, and now, AI agents that can autonomously call APIs, consume data, make decisions, and interact with other systems on behalf of individuals or the entire organisation.
In most large enterprises, machine identities already outnumber human ones by ratios of 80:1 or more, according to CyberArk’s 2025 Identity Security Landscape Report. That figure is growing fast, and the arrival of AI agents is about to pour fuel on it.
Think of it this way. A traditional enterprise application is like a vending machine: a user submits a request, the machine dispenses a response, the interaction ends, and it waits for the next request. An AI agent is more like a contractor you’ve hired and given a set of keys. It moves around the building, opens doors, talks to others, makes phone calls, and takes actions based on its own judgment. The question every security team should ask is: what access does that contractor need, and who is monitoring their activity?
Right now, most organisations cannot answer that question. Their IAM systems were built to manage people, not identities that spin up in milliseconds, communicate agent-to-machine or agent-to-agent without human intervention, and may have been granted broad API permissions by a developer who needed something to work quickly during a proof of concept six months ago.
This AI governance gap is real. When a human employee is granted access to a sensitive system, there is (in theory) a request, an approval, a record, and eventually a review over months or years. When an AI agent is granted API credentials to access customer data, financial systems, or internal knowledge bases, the process is often informal, undocumented, and invisible to the security team. The agent has no manager. It doesn’t appear in HR systems. It won’t show up in the next access review. It works very fast! If its credentials are compromised or its behavior drifts outside acceptable bounds, there may be no alerting mechanism in place to catch it.
This is not a theoretical risk. Organisations are already deploying agents into production that can read and write to CRM systems, generate and send communications, query databases, and trigger workflows. Each of these actions requires access, and each access decision is an identity governance decision, whether or not anyone treats it as such.
Three Assumptions Making This Worse
The agent identity crisis would be more manageable in the short term if enterprise IAM systems were in good shape. Most organisations are operating under at least three assumptions that were questionable five years ago and are actively dangerous now.
Assumption 1: MFA Solves the Authentication Problem
Multi-factor authentication was a genuine step forward. It made credential theft significantly harder and gave security teams a defensible position when the board asked what they were doing about phishing. The problem is that many organisations have treated MFA as a destination rather than a waypoint.
MFA does not protect against session hijacking, token theft, fatigue, or adversary-in-the-middle attacks, all of which are now standard techniques in the attacker playbook. It does not help when an AI agent authenticates using only an API key that can’t support MFA in the first place. And it does not address the growing category of attacks in which authentication succeeds because the attacker has legitimate credentials obtained through social engineering, infostealer malware, or a compromised identity provider.
The organisations that will weather the next wave of identity attacks are the ones moving towards continuous access evaluation, where trust is reassessed throughout a session based on behavioural signals, device posture, and context, rather than validated once at the front door.
Assumption 2: Annual Access Reviews Are Sufficient
Access certification campaigns are one of the great rituals of enterprise security – also invented for the era of human users. Once or twice a year, managers receive a spreadsheet (or if they’re fortunate, a workflow notification from the IGA system) asking them to confirm that their direct reports still need the access they have. Most managers click “approve all” within minutes, because they have no practical way to evaluate whether a given account or application permission is still required. They often approval all since the cost of accidentally removing access a team member needs is immediate and visible, while the cost of leaving excessive access in place is abstract and invisible.
This was always a somewhat useful but weak control. In a world where AI agents can be provisioned, granted access, perform their tasks, and be decommissioned within a single sprint cycle, annual reviews are not just insufficient; they are irrelevant. The risk comes and goes (you hope) between access reviews. And the standard user access review itself will never surface the API permissions, temporary credentials, and agent-to-machine trust relationships that represent the actual attack surface.
What’s needed is a shift from periodic reviews to continuous governance, where access is evaluated in real time, permissions are granted with automatic expiry, and anomalous patterns trigger investigations immediately.
Assumption 3: The Cloud Provider Handles Identity
This one is particularly persistent. Many enterprises have migrated workloads to one or more cloud platforms and assumed that the cloud provider’s native IAM capabilities are sufficient to manage identity and access across their environments. Azure has Entra ID. AWS has IAM. Google has its own identity stack. Surely that’s enough?
Most enterprises operate across multiple clouds and retain significant on-premises infrastructure, so no single provider’s identity layer covers the full estate. Cloud IAM is also designed primarily to control access to that provider’s services, not to provide the governance, lifecycle management, and cross-platform policy enforcement that enterprises require. Most relevant to the agent discussion, Cloud IAM was designed for relatively static role assignments, not for the dynamic, ephemeral, context-dependent access patterns that AI agents demand.
The result is a fragmented identity environment in which policies are inconsistent, visibility is incomplete, and the gaps between cloud platforms and on-premises systems are exactly where attackers (and misconfigured agents) find room to operate.
What Comes Next
None of this is cause for despair, but it is cause for urgency. The organizations that successfully manage the transition to agent-centric enterprise architectures are those that treat identity management as a continuous, dynamic discipline for both people and NHIs, rather than a periodic compliance exercise.
That means investing in identity governance that extends to non-human identities with the same (or better!) rigor as applied to human identities. It means moving beyond MFA to continuous, risk-adaptive authentication and authorization. Furthermore, we must replace annual certification theater with real-time access intelligence. Building an identity fabric that spans cloud providers, on-premises systems, and the new generation of AI agents that will increasingly act on behalf of the organization.
The uncomfortable truth is that most enterprise IAM programmes were designed for a world that no longer exists. The assumptions baked into them were reasonable at the time, but the environment has changed faster than the programmes have adapted. Closing this gap is no longer optional. It is the difference between an organisation that can safely adopt AI-driven automation and one that is creating risk faster than it can manage it.
These are exactly the challenges that will be at the center of discussions at the European Identity and Cloud Conference (EIC 2026) in Berlin, 19-22 May. If your IAM strategy was designed for the world of five or even 10 years ago, EIC is where you’ll find out what needs to change and how to make those changes.
