AI adoption hits 99.6%, but identity governance is lagging

At a glance

What this is: JumpCloud’s Q3 IT Trends 2025 report says AI adoption is now near-universal, but the real challenge has shifted to governance, identity control, and operational integration.

Why it matters: IAM, IGA, PAM, and NHI teams need to treat AI integration as a governance problem, because broad adoption without access controls and lifecycle discipline expands risk across human and machine identity programmes.

By the numbers:

• AI adoption has surged to 99.6% among the companies JumpCloud surveyed, up from 86.8% in its previous findings.

Context

AI adoption has moved from experimentation to operational reality, and that changes the identity problem immediately. Once AI is embedded into workflows, it stops being a side project and starts touching access paths, approvals, and decision points that identity teams already govern.

For IAM and governance teams, the key issue is not whether AI is present but whether identity controls were designed for systems that can be woven into helpdesk, analytics, and security workflows at scale. That shift matters because adoption alone does not prove that privileges, accountability, and oversight have kept pace.

JumpCloud’s survey data suggests this is now a mainstream operating condition rather than an edge case. The starting position is typical for the current market, which makes the governance gap more consequential, not less.

Key questions

Q: How should security teams govern AI-enabled workflows that can act on their own?

A: Treat them as identity-governed execution paths, not just software features. Assign a named owner, define least-privilege access, log every tool call, and require revocation paths for credentials and tokens. If the workflow can touch production systems or sensitive data, its permissions must be reviewed with the same discipline used for privileged machine identities.

Q: Why does broad AI adoption create identity risk even when the tools are familiar?

A: Because the risk comes from how AI is wired into workflows, not from the novelty of the tool itself. Once AI touches helpdesk, security, or analytics processes, it can inherit access, trigger actions, and blur accountability unless identity controls are updated to match the new execution path.

Q: What are the best practices for separating AI observation from AI action?

A: Use different controls for systems that observe data and systems that can change state. Read-only AI should have narrow data access, while action-capable AI should require explicit ownership, approval boundaries, logging, and periodic review. The key is to prevent silent privilege expansion when a use case moves from insight to execution.

Q: How can IAM teams tell whether AI and NHI governance are actually unified?

A: Look for one policy model, one identity inventory, and one review process that covers people, workloads, and agent-linked access. If each actor type is handled in a separate tool or review cycle, the programme is still fragmented even if the platform claims a single control plane.

Technical breakdown

AI adoption is now an identity governance problem

When AI becomes part of routine operations, it inherits the access pathways of the systems around it. That means identity scope, approval boundaries, and auditability matter as much as model capability. In practice, AI embedded in helpdesk or security workflows can inherit broad delegated access without the governance model being updated to reflect who or what is acting, under whose authority, and with what limits. The result is a control gap at the point where automation becomes operational dependency.

Practical implication: Treat AI integration as an identity design change, not a feature rollout.

Helpdesk and security use cases create different control demands

Helpdesk assistants and security detection tools may both use AI, but they create different identity risks. Helpdesk use cases often sit close to user data, identity recovery, and workflow actions, while security use cases may access alerts, logs, and administrative controls. The governance lesson is that AI use case placement determines the risk boundary. A single AI policy will usually be too blunt unless it distinguishes between access to support workflows and access to security operations.

Practical implication: Map AI use cases to the identities, datasets, and privileges they can touch.

Operational embedding changes the trust model for AI

The important shift is not only adoption volume, but the move from isolated AI use to embedded execution inside core business processes. Once AI participates in normal operations, it becomes part of the trust chain for identity and access decisions. That puts lifecycle management, least privilege, logging, and human oversight into the same frame as model governance. For NHIs, the control question becomes whether the AI-enabled workflow can be inventoried, constrained, and reviewed like any other privileged system.

Practical implication: Extend inventory, approval, and review controls to AI-enabled workflows with access side effects.

Threat narrative

Attacker objective: The objective is to exploit operational AI trust to expand access, blur accountability, or make privileged actions harder to scrutinize.

1. Entry occurs when AI is embedded into helpdesk, chatbot, or security workflows and begins operating inside existing access pathways.
2. Escalation occurs when those workflows inherit broader data or administrative reach than the governance model originally intended.
3. Impact follows when AI-driven actions are trusted as routine operations even though accountability, review, and constraint were not redesigned for them.

Breaches seen in the wild

• JumpCloud breach 2023: North Korean hackers breached JumpCloud and abused its device commands framework against a few customers; all admin API keys were reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI adoption has crossed the threshold where governance lag becomes the primary risk. Once nearly every organisation is using AI in some form, the debate is no longer about experimentation. The issue is whether identity, access, and lifecycle controls were redesigned for AI-enabled operations or are still being stretched beyond their original scope. Practitioners should treat adoption saturation as a trigger for governance recalibration, not as proof of maturity.

The control problem is no longer generic AI oversight, but placement-specific identity governance. Helpdesk automation, security threat detection, predictive maintenance, and user analytics do not create the same access profile. That means the identity model has to distinguish between systems that can observe data and systems that can act on it. The practical conclusion is that one-size-fits-all AI governance will miss the actual points of privilege and accountability.

Identity sprawl at the AI boundary: AI embedded into core workflows creates a new class of governed execution paths that sit between human approval and machine action. That is where policy language often outruns operational controls, because the organisation knows the use case but not the exact privilege shape. The implication is that identity programmes need inventory discipline for AI-enabled workflows before they can claim oversight of them.

Machine governance and human governance are converging around the same accountability gap. AI is not replacing identity controls, but it is forcing them to cover more actors, more delegates, and more indirect actions. The organisations that will cope best are those that can map who can trigger AI, what the AI can touch, and how the resulting actions are reviewed. Practitioners should assume the governance boundary has moved to the workflow edge.

For the field, the signal is that AI governance is becoming an IAM and NHI problem, not a standalone policy exercise. Once AI is used for support and security operations, the relevant controls are inventory, privilege, logging, and offboarding across the execution chain. That makes the identity team a central stakeholder in AI risk rather than a downstream reviewer. The discipline now has to govern operational AI the same way it governs any other privileged system.

From our research library:

• Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious, according to the 2026 Infrastructure Identity Survey.

What this signals

AI adoption is now common enough that identity teams should stop treating it as an innovation topic and start treating it as a control-scope problem. Once AI is embedded into business workflows, the governance question shifts to who can trigger it, what it can touch, and how those actions are reviewed.

Identity sprawl at the AI boundary: this is the point where AI-enabled workflows begin to accumulate privileges that were never designed as a single governed unit. Practitioners should inventory those workflows now, because the most common failure mode is not model weakness but untracked operational authority.

For practitioners

• Inventory AI-enabled workflows Catalog every workflow where AI can read, recommend, or act on identity, support, or security data so the privilege boundary is explicit.
• Separate read-only and action-capable use cases Distinguish AI that summarizes or classifies from AI that can trigger operational changes, and apply different approval and audit requirements to each.
• Tie AI access to lifecycle ownership Assign a business owner, technical owner, and review cadence for each AI-enabled workflow so offboarding and recertification are not ad hoc.
• Review delegated privileges in support and security automation Check whether AI-assisted helpdesk and detection tools inherit permissions that exceed the minimum needed to complete the task.

Key takeaways

• AI adoption is no longer the differentiator. Governance discipline is, because embedded AI changes the access and accountability model inside ordinary workflows.
• JumpCloud’s survey shows near-universal adoption, which means identity teams are dealing with a mainstream operating condition rather than an emerging exception.
• The practical response is to inventory AI-enabled workflows, separate read-only from action-capable use cases, and attach lifecycle ownership to both.

Key terms

• AI-Connected Workflow: An AI-connected workflow is any process in which an AI system, model, or agent can read, transform, or route sensitive data as part of business operations. The governance challenge is that these workflows often inherit access from humans or services without a clear business justification for every permission.
• Delegated Privilege: Delegated privilege is access granted to a tool or system so it can perform actions without direct human intervention. The risk rises when delegation is broad, hidden, or hard to revoke, because the delegated actor can continue operating after trust has changed.
• Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.
• Operationalizing AI: Operationalizing AI means moving model capability from experimentation into repeatable, governed use in live workflows. The focus is on access boundaries, logging, approvals, monitoring, and safe integration with existing processes so AI can support operations without creating uncontrolled risk.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.