AI adoption is exposing cybersecurity response gaps in IT teams

At a glance

What this is: This is Netwrix's 2025 survey of global IT professionals, showing that AI use is already widespread while incident response and financial impact remain stubbornly high.

Why it matters: It matters because security and identity teams need to treat AI adoption as an operating change that affects access control, response readiness, and recovery across NHI, autonomous, and human programmes.

By the numbers:

• Netwrix Research Lab surveyed 2,150 IT professionals from 121 countries via an online questionnaire.
• 60% of organizations are already leveraging AI tools in their IT infrastructure.
• 51% of respondents confirmed experiencing a security incident in the past 12 months that demanded a dedicated response from security teams.
• 75% of respondents reported financial damage due to attacks.

👉 Read Netwrix's 2025 Cybersecurity Trends Report on AI and incident response

Context

AI adoption is no longer an isolated experimentation phase inside IT infrastructure. In this report, the governance question is whether organisations are pairing that adoption with access control, incident response, and recovery practices that can actually absorb the risk.

The survey results point to a familiar identity problem in a new form: when new tooling enters the environment quickly, security controls tend to lag behind usage. That gap affects non-human identities, human administrators, and emerging autonomous workflows alike.

For practitioners, the report is a signal to look beyond usage counts and ask whether the surrounding control plane is keeping pace. High adoption combined with high incident response demand usually means operational maturity has not kept up with technical change.

Key questions

Q: How should security teams govern AI tools embedded in IT infrastructure?

A: They should treat AI-enabled infrastructure as an identity governance problem, not just a tooling problem. That means mapping which humans, service accounts, and delegated workflows can initiate actions, then tying those paths to least privilege, approval rules, and incident ownership. The goal is to prevent hidden access paths from turning routine automation into unmanaged privilege.

Q: Why do incidents involving AI tools often need dedicated security response?

A: Because automated remediation rarely resolves the full scope of access, data, or configuration impact on its own. A dedicated response is needed when teams must inspect identity use, isolate affected accounts, and decide whether revocation, rotation, or business continuity measures are required. That is usually a sign the control plane did not fully contain the event.

Q: What breaks when AI adoption outpaces identity governance?

A: The gap usually appears in approval, visibility, and recovery. Teams may know a tool exists, but not which identities it uses, what it can touch, or how quickly access can be removed during an incident. That creates delayed containment and higher business impact, especially where privileged access or secrets are involved.

Q: Who should own incident response when AI and infrastructure controls overlap?

A: Ownership should sit with the team that can see both identity behaviour and infrastructure impact, typically security operations working with IAM, PAM, and platform owners. If the incident involves access scope, credentials, or privileged workflows, accountability has to include revocation and recovery decisions, not just alert handling.

Technical breakdown

AI adoption in IT infrastructure and identity control

When organisations embed AI tools into IT infrastructure, they expand the number of systems, users, and service paths that can initiate changes or access sensitive data. That does not automatically make the environment autonomous, but it does raise the density of identity relationships that IAM and NHI controls must govern. The practical issue is not the presence of AI alone. It is the fact that access, approval, and monitoring requirements often stay designed for older operating models while the execution layer changes underneath them.

Practical implication: map where AI tools touch identities, secrets, and admin workflows before usage grows further.

Why incident response grows faster than automation

A dedicated security response means the event was not contained by routine automation. In practice, that usually indicates a control failure that required humans to interpret scope, isolate affected systems, and decide whether identity or data exposure had occurred. The number matters because it shows that automation can assist response, but it cannot replace triage, containment, and root-cause analysis when access patterns, credentials, or workflows are involved.

Practical implication: validate that incident runbooks include identity investigation steps, not just host or alert handling.

Financial damage as a sign of governance failure

Financial damage is usually the downstream result of delayed containment, business interruption, or recovery cost after an attack. In identity-heavy environments, that damage often reflects weak privilege boundaries, poor credential hygiene, or slow revocation when a system or account is compromised. The report does not prove causation for each case, but it does show that organisations are still paying for the gap between technical detection and actual operational recovery.

Practical implication: tie identity controls to business-impact metrics, not only to alerting and audit evidence.

NHI Mgmt Group analysis

AI adoption has become an identity governance problem before it becomes an AI governance problem. Once 60% of organisations are already using AI tools in IT infrastructure, the practical question shifts from adoption to control coverage. The identity layer has to account for people, service accounts, secrets, and increasingly delegated tool use in the same operational environment. Practitioners should read this as a governance convergence point, not a technology milestone.

Dedicated security response is the clearest sign that control planes are still too brittle. When more than half of respondents needed human-led incident response, it means automated remediation did not fully contain the event. That usually points to missing context around identity, access scope, or system dependency, which are the controls that determine whether an alert becomes an outage or a manageable event. The implication is that operational resilience still depends on identity visibility.

Financial damage now reflects identity and recovery latency, not just attacker sophistication. A reported 75% financial damage rate shows that breach cost is still being absorbed by business interruption, recovery effort, and post-incident correction. In identity terms, that is what happens when privilege boundaries and revocation speed are weaker than attack propagation. Practitioners should treat cost exposure as a control outcome, not a separate finance problem.

Identity programmes need to measure AI governance by operational consequences, not policy volume. The report's real lesson is that written controls do not matter if incidents still require dedicated human response and still produce financial harm. IAM, PAM, and NHI teams should therefore evaluate whether AI-related access is shrinking blast radius or simply adding another source of unmanaged change. The programme test is containment, not documentation.

Runtime governance gap: The current security model assumes new tools can be absorbed into existing response and access processes without reworking the identity layer. That assumption weakens as AI becomes embedded in infrastructure because the environment changes faster than certification, review, and recovery cycles. Practitioners should recognise that the gap is structural, not cosmetic.

From our research:

• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• For the governance model behind that gap, see OWASP NHI Top 10 for the identity and runtime control issues that emerge when AI systems touch tools and infrastructure.

What this signals

Runtime governance gap: AI adoption is accelerating inside infrastructure teams faster than most identity programmes can classify or review the access paths involved. With 70% of organisations granting AI systems more access than they would give a human employee performing the same job, according to the 2026 Infrastructure Identity Survey, the first control failure is usually scope, not detection.

That pattern should push practitioners to rethink how incident response, privileged access, and lifecycle governance intersect when tooling can act inside production. The programme risk is not that AI exists. It is that AI is being folded into existing identity models that were never designed to absorb that level of access drift.

For practitioners

• Inventory AI-touching identities and workflows Identify every AI tool that can access infrastructure, secrets, or administrative interfaces, then map which human, service, or delegated identities it relies on. Classify those paths by privilege level and business criticality so review priorities are based on real exposure.
• Add identity steps to incident runbooks Require responders to check credential use, service account activity, token scope, and privileged access changes before declaring containment. That makes it easier to distinguish a normal alert from an access-driven incident that needs revocation or rotation.
• Measure recovery against access scope Track whether incidents that involve AI, automation, or machine access are taking longer to close because of delayed privilege review or unclear ownership. Use those findings to tighten approval paths, revocation timing, and escalation ownership.
• Review where automation masks unresolved risk Look for cases where automated remediation clears an alert but leaves the underlying identity exposure in place. The objective is to confirm that the control removed access, not just suppressed the symptom.

Key takeaways

• The report shows that AI is already embedded in infrastructure operations, but access governance has not matured at the same pace.
• More than half of respondents still needed dedicated incident response, which suggests automation is not replacing human containment where identity and access are involved.
• Security teams should now measure AI adoption through privilege scope, revocation speed, and recovery impact rather than through usage alone.

Key terms

• Identity Governance Gap: The mismatch between how quickly systems are adopted and how quickly their access is classified, reviewed, and controlled. In practice, it shows up when teams know a tool exists but cannot confidently explain who or what can use it, what it can reach, or how it is removed during an incident.
• Dedicated Security Response: A human-led incident response effort that goes beyond automated remediation. It usually means the event requires investigation, containment, and recovery decisions that cannot be safely completed by scripts alone, especially when identities, credentials, or privileged actions are involved.
• Privilege Scope: The actual range of systems, data, and actions an identity can reach. In identity security, privilege scope is often more important than the label on the account because risk rises when access is broader than the task, harder to observe, or slower to revoke.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Netwrix: 2025 Cybersecurity Trends Report. Read the original.