When Machine Identities Outnumber Humans: Rethinking IAM for Agentic AI

Enterprise identity and access management (IAM) was built for employees, contractors and admins who log in, change roles and eventually leave. That human-centric model is now colliding with a reality in which machines — including AI agents — outnumber people by 82 to 1, according to 2025 research from CyberArk. At that scale, legacy IAM assumptions are no longer just strained; they are routinely failing in ways attackers are already exploiting.

For security leaders and AI platform builders, the shift isn’t theoretical. AI agents are being created at a blistering pace — Microsoft Copilot Studio users alone spun up over 1 million agents in a single quarter, a 130% jump over the previous period. At the same time, Gartner expects a quarter of enterprise breaches by 2028 to involve AI agent abuse. Identity is rapidly becoming the control plane for AI risk, yet most IAM programs still treat humans as the only truly “privileged” users.

Re-architecting for this new era requires confronting a simple but uncomfortable fact: agentic AI does not just authenticate; it acts. Every new agent and automation workflow is a new identity surface, and legacy IAM wasn’t designed to keep up.

The 82-to-1 shift: what the numbers really mean

CyberArk’s 2025 research puts concrete numbers behind what many CISOs have sensed anecdotally: machine identities now overwhelm human users inside the enterprise by more than 80 to 1. These identities include API keys, service accounts, workloads, devices and, increasingly, AI agents that interact with data and systems on behalf of users or other services.

Yet the way organizations think about “privilege” hasn’t caught up. In CyberArk’s 2025 Identity Security Landscape survey of 2,600 security decision-makers, 88% still defined only human identities as privileged. In practice, that means machines often enjoy broad, sensitive access governed by policies and processes written for employees — even as machines become the dominant class of actor inside corporate environments.

The consequences are measurable. CyberArk’s data shows that 42% of machine identities hold sensitive access. At enterprise scale, that translates into millions of keys, tokens and service accounts with effective access to core systems and “crown jewel” data — many of them created for convenience, left over from previous projects, and rarely reviewed with the same discipline applied to human accounts.

Microsoft’s Copilot Studio usage underscores how quickly this landscape is changing. Over 1 million AI agents created in a single quarter means an enormous spike in machine identities that authenticate to applications, touch data and trigger actions. Each of those agents is either using a delegated human credential or its own identity — in both cases, often without the lifecycle controls and governance that human account onboarding and offboarding receive by default.

Gartner connects this trend directly to risk, predicting that by 2028, 25% of enterprise breaches will trace back to AI agent abuse. In other words, the identities that power the AI transition are on track to become one of its most active attack surfaces.

Why legacy IAM architectures can’t keep up

Directory services such as Active Directory, traditional LDAP and early privileged access management (PAM) platforms were built for people. Machines and automated processes were exceptions, often bolted on through service accounts and static secrets. At an 82-to-1 machine-to-human ratio, those exceptions are now the norm — and the cracks are showing.

Gartner analysts, in a May 2025 report, make the core critique explicit: “Traditional IAM approaches, designed for human users, fall short of addressing the unique requirements of machines, such as devices and workloads.” Attempts to retrofit human IAM models into machine contexts tend to produce fragmented, inconsistent controls that are difficult to scale and even harder to audit.

The reasons for this fragmentation are as much operational as technical. AI builders and cloud teams don’t typically create over-permissioned service accounts or “shadow agents” out of disregard for security. They do it because the friction is real: cloud IAM workflows are slow, security reviews don’t map cleanly to agent-centric architectures, and production pressure rewards speed over careful scoping. Static credentials — long-lived API keys, hardcoded secrets, generic service accounts — become the quickest way to ship.

Those shortcuts accumulate as technical debt. Gartner warns that “retrofitting human IAM approaches to fit machine IAM use cases leads to fragmented and ineffective management of machine identities, running afoul of regulatory mandates and exposing the organization to unnecessary risks.” The governance gap is not just about poor hygiene; it is about systemic misalignment between how machines operate and how traditional IAM thinks.

Visibility is another fault line. In a 2025 survey of 335 IAM leaders, Gartner found IAM teams are responsible for only 44% of their organizations’ machine identities. That means the majority of machine credentials are created, used and retired — or left orphaned — outside formal IAM oversight. Without central accountability for these identities, security teams are blindsided by how many credentials exist, what they can reach, and who (if anyone) owns them.

This is reflected in incident investigations. Gartner’s Leaders’ Guide highlights how legacy service accounts, often set up for workloads that have long since disappeared, persist as “orphan” credentials. In multiple enterprise breaches examined in 2024, attackers did not bypass sophisticated endpoint defenses or attack models directly. Instead, they simply reused long‑lived API keys tied to abandoned automations — keys no one realized were still valid because the agent or process that created them had been decommissioned.

As Elia Zaitsev, CTO at CrowdStrike, told VentureBeat, adversaries are shifting their focus: “Cloud, identity and remote management tools and legitimate credentials are where the adversary has been moving because it’s too hard to operate unconstrained on the endpoint. Why try to bypass and deal with a sophisticated platform like CrowdStrike on the endpoint when you could log in as an admin user?” The same logic applies to machine and agent identities: compromising one powerful token can render endpoint hardening irrelevant.

Agentic AI and collapsing identity boundaries

The rise of agentic AI adds an entirely new stressor to already fragile IAM designs. These agents don’t simply request data; they invoke tools, call APIs, orchestrate workflows and sometimes spawn other agents. To do that, they need credentials.

Gartner’s researchers flag AI agents explicitly as a critical identity use case: “AI agents require credentials to interact with other systems. In some instances, they use delegated human credentials, while in others, they operate with their own credentials. These credentials must be meticulously scoped to adhere to the principle of least privilege.” In practice, this is rarely straightforward.

Delegated credentials blur accountability: when an agent acts with a human’s token, logs show the human, not the agent. Dedicated agent credentials pose a different set of problems: they multiply identities and privileges that need to be tracked, reviewed and revoked. Both patterns can be safe if rigorously governed; both become hazardous when created ad hoc under delivery pressure.

The Model Context Protocol (MCP) illustrates how quickly identity assumptions can erode. MCP has been called out by security researchers for lacking built-in authentication. Beyond missing a standard auth layer, Gartner notes that MCP-style architectures collapse traditional identity boundaries by enabling agents to traverse data and tools without a stable, auditable identity surface. In such environments, understanding “who” did “what” and “why” at the identity layer becomes extremely difficult.

This challenge is amplified when enterprises deploy multiple generative AI tools at once. Security teams need a clear view into which integrations can only generate content and which have action capabilities — such as writing data, calling operational systems or modifying configurations. Without that level of clarity and scoping, AI platforms can quietly become powerful automation layers with limited oversight and unpredictable blast radius.

To detect and contain agent abuse, organizations are converging on platforms that unify identity, endpoint and cloud telemetry. Point tools that only see a single layer — say, endpoint EDR or standalone IAM logs — struggle to trace an agent-triggered action end-to-end. As machine-to-machine interactions accelerate, real-time correlation across domains is increasingly the only way to spot abnormal behavior before it turns into an incident.

Dynamic service identities: a new design baseline

Gartner’s guidance points toward a different foundation for machine and agent identities: dynamic service identities. Instead of relying on long‑lived, manually managed service accounts, these are ephemeral, policy-driven credentials that exist only as long as they are needed and are tightly scoped to a specific set of actions.

Gartner advises security leaders to “move to a dynamic service identity model, rather than defaulting to a legacy service account model. Dynamic service identities do not require separate accounts to be created, thus reducing management overhead and the attack surface.” The goal is not just operational efficiency; it is risk reduction through shorter credential lifetimes, narrower privileges and automated lifecycle control.

In practice, dynamic identities often map to cloud-native constructs such as AWS IAM roles, Azure managed identities or Kubernetes service accounts — mechanisms that let workloads assume just‑in‑time permissions without embedding static secrets. When properly implemented, these constructs make it easier to:

• Scope each identity to the minimum necessary permissions
• Rotate and revoke access automatically based on policies
• Align identity lifetime with workload or session lifetime
• Centralize logging and analysis of machine authentication and authorization events

The longer-term target is just‑in‑time access and “zero standing privileges” for machines and agents, not just humans. That means credentials exist only when needed for a specific task and disappear immediately afterward. Platforms that already integrate identity with endpoint and cloud telemetry are better positioned to enforce and monitor such models, because they can tie identity events to runtime behavior.

What security and AI teams can do now

The organizations making progress on agentic identity are treating it as a joint responsibility between security leaders and AI builders, not a handoff. Drawing on Gartner’s Leaders’ Guide, OpenID Foundation guidance and vendor best practices referenced in the research, several practical priorities are emerging:

1. Start with a full discovery and audit of machine identities. Before changing architectures, establish a baseline. Comprehensive discovery across infrastructure, applications, automation platforms and AI tooling regularly reveals between six and ten times more machine identities than security teams had cataloged. One hotel chain, for example, discovered it had been tracking only about a tenth of its actual machine identities prior to an audit. Without this visibility, risk assessments and control designs rest on incomplete data.

2. Build and maintain an agent inventory before production. As AI agents proliferate, uncontrolled “shadow agents” become a real risk. Establishing an inventory — effectively, a registry of agent identities — gives both builders and security teams a shared source of truth. For each agent, track ownership, intended purpose, permissions, data access and API connections before it reaches production. This discipline makes it harder for unmanaged agents to slip into critical workflows.

3. Standardize on dynamic service identities. Transition away from static service accounts toward cloud-native dynamic alternatives such as IAM roles, managed identities and Kubernetes service accounts. These should be ephemeral, tightly scoped and policy-driven. The objective is to support AI builders with the identities they need while maintaining strong compliance and minimizing standing exposure.

4. Prefer just‑in‑time credentials over static secrets. Integrate just‑in‑time provisioning, automatic secret rotation and least‑privilege defaults into CI/CD pipelines and agent frameworks. These are core elements of zero trust applied to AI and DevOps workflows. Experienced security leaders defending AI initiatives consistently advise against relying on perimeter security controls alone; instead, they emphasize identity-centric protections embedded directly into build and deployment processes.

5. Make delegation chains auditable. When agents spawn sub‑agents or call external APIs that, in turn, perform actions, authorization paths can quickly become opaque. Require clear human accountability for every agent and service, and ensure systems capture delegation relationships in a way that can be reconstructed during investigations. Behavioral baselines and drift detection become key: understanding how an agent normally behaves is a prerequisite to spotting misuse.

6. Deploy continuous monitoring of machine credential use. In line with zero trust, treat every machine credential use as an event worth evaluating, not a one‑time setup task. Continuous monitoring and auditing can surface anomalies such as unexpected privilege escalations, unusual lateral movement, or activity from locations and services that don’t match normal patterns.

7. Evaluate machine identity posture. Regularly assess the machine identity landscape for possible exploitation paths, potential blast radius and instances of “shadow admin” access. This includes stripping unnecessary rights, closing outdated access paths and identifying misconfigurations that attackers could chain together.

8. Enforce agent lifecycle management. AI agents should follow lifecycle patterns similar to employees. When AI builders move to new roles or projects, or when workflows are retired, their associated agents should trigger decommissioning and access revocation. Orphaned agents with lingering privileges are an attractive target for attackers for the same reason orphaned service accounts are.

9. Favor unified platforms over scattered point tools. Fragmented tooling correlates strongly with fragmented visibility. Where possible, adopt platforms that unify identity, endpoint and cloud security so builders gain self‑service insight while security teams gain cross‑domain detection and response capabilities. This integrated view is particularly important for understanding how an AI agent’s credentials are being used across infrastructure layers.

2026: widening gap between AI deployment and governance

The trajectory into 2026 points toward further divergence between what AI builders can deploy and what security teams can effectively govern. Historically, each major technology wave — from early cloud adoption to API‑driven architectures and now generative AI — has brought with it a new class of misconfigurations and oversights that adversaries are quick to exploit. Machine identities and AI agents are following the same pattern.

The 82‑to‑1 ratio of machine to human identities is not a peak; it is a waypoint on a rising curve. As organizations deepen their use of automation and AI, that number is likely to increase, further stretching any architecture built primarily around human accounts. Continuing to rely on human‑first IAM is not just a matter of comfort with legacy tools; it is a decision to operate with a security model that grows weaker with every new agent created.

Agentic AI is not inherently insecure because it is “intelligent.” It introduces risk because it multiplies identities and actions at machine speed while governance structures remain human‑paced. The attackers who already favor identity over endpoints are well positioned to exploit this gap.

For security leaders and AI platform owners, the priority for 2026 is to turn this structural weakness into a strength by making identity — human and machine — the organizing principle of AI security. That means moving decisively away from perimeter‑centric thinking and from static, human‑oriented IAM models, toward dynamic, zero‑trust architectures purpose‑built for machine‑on‑machine interactions.

Those who make that shift early will be better equipped not only to absorb the continuing growth in AI agents, but also to assert meaningful control over how those agents authenticate, what they can do and how quickly abuse is detected and stopped.