AI-driven threats are reshaping identity and data security strategies

At a glance

What this is: Netwrix’s survey shows AI-driven attacks are forcing organisations to change security strategy, with identity and data protection moving closer together.

Why it matters: For IAM teams, this is a signal that AI is no longer just a tooling question, it is a governance problem affecting NHI, autonomous systems, and human identity controls alike.

By the numbers:

• 37% said AI-driven attacks forced them to adjust their security approach over the past year.
• 29% report auditors now require proof of data security and privacy in AI-based systems.
• AI-based tools as a top-five IT priority has surged 189% in two years, from 9% in 2023 to 26% in 2025.
• 30% say their business uses AI and must now protect it like any other critical system.

👉 Read Netwrix's research on how AI-driven threats are changing security strategy

Context

AI-driven attacks are changing how organisations think about identity, data, and control boundaries. In practice, that means security programmes can no longer treat AI as a separate innovation track when the same access, secrets, and governance failures are now being amplified by faster attacker operations.

For IAM and security leaders, the immediate issue is not whether AI is useful, but whether existing controls can still explain and constrain access when attack speed, system sprawl, and audit expectations rise together. The article’s findings point to a broad programme shift rather than a single product fix.

That shift is typical of the current market: organisations are reacting to AI pressure by extending governance expectations onto systems that were previously monitored only for availability or application risk.

Key questions

Q: How should security teams govern AI systems that use identity credentials?

A: They should treat AI-connected credentials as governed identities, not as implementation details. That means inventorying service accounts, API keys, and tokens, then applying access review, revocation, and audit evidence requirements to each one. The goal is to make every AI access path traceable, scoped, and accountable before it can be abused.

Q: Why do AI-driven attacks increase risk for identity and access management programmes?

A: They increase risk because they compress the time between exposure and impact. If attackers can move faster than normal review cycles, then standing privilege, exposed secrets, and weak revocation processes become more dangerous. IAM programmes must therefore focus on speed of detection, scope reduction, and verified offboarding, not just policy completeness.

Q: What do organisations get wrong when they separate AI risk from identity risk?

A: They assume AI is only an application layer issue, when it often depends on the same credentials and permissions that govern other non-human identities. That separation hides the real control points, especially secrets, tokens, and service accounts. A unified identity view exposes where AI systems can overreach or leak data.

Q: Who is accountable when an AI system exposes sensitive data through access misuse?

A: Accountability should sit with the team that owns the identity, the data path, and the control evidence, not with the AI label itself. In practice, that usually means IAM, security, and application owners share responsibility for access scope, secrets handling, and revocation. Auditability should prove the chain of ownership.

Technical breakdown

AI-driven identity attacks compress response windows

AI changes the economics of identity-based attack campaigns by making reconnaissance, credential abuse, and follow-on actions faster and more scalable. That does not create a new identity model, but it does reduce the time defenders have to detect unusual authentication behaviour, inspect secrets exposure, and interrupt lateral movement. In identity terms, the issue is not only attack volume. It is the shorter interval between initial compromise and meaningful impact, which makes manual review cycles less effective.

Practical implication: shorten detection and containment loops around identities, secrets, and privileged sessions.

AI as a new protected system in IAM governance

When organisations say AI must be protected like any other critical system, they are really acknowledging that AI now has identities, data access paths, and operational dependencies that belong inside the IAM model. That includes service accounts, API keys, orchestration tokens, and any AI-connected workflow that can read or write sensitive data. Once AI becomes part of the control plane, the governance question shifts from application security to access governance, entitlement scope, and auditability.

Practical implication: inventory AI-connected identities and bring them into access review, secrets, and lifecycle processes.

Audit evidence for AI systems raises the bar on identity proof

Auditors asking for proof of data security and privacy in AI-based systems signals that governance evidence now matters as much as technical control presence. For identity teams, this means it is no longer enough to say an AI workload is restricted. You need to show who or what can access it, what data it touches, how those credentials are issued, and how access is revoked. That shifts AI governance toward traceable entitlement evidence rather than informal assurances.

Practical implication: build audit-ready evidence for AI access, data boundaries, and credential lifecycle events.

Threat narrative

Attacker objective: The attacker aims to turn identity exposure into faster compromise, broader data access, and higher-confidence operational impact before defenders can respond.

1. Entry begins when attackers use AI to accelerate discovery of exposed identities, weak authentication paths, or high-value data access points.
2. Escalation follows as compromised credentials, tokens, or over-permissioned accounts are used to widen access and increase the speed of downstream actions.
3. Impact occurs when attackers combine faster execution with identity abuse to exfiltrate data, disrupt operations, or force defenders into reactive containment.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI-driven threats are now an IAM governance problem, not just a security operations problem. When attack speed rises, the limiting factor becomes whether identities, secrets, and permissions are governed with enough precision to survive automated abuse. That changes the centre of gravity from isolated detection to lifecycle control, entitlement scope, and provable access boundaries. Practitioners should treat AI pressure as a governance redesign trigger.

AI is becoming a protected system because it now carries identity risk of its own. The article’s 30% figure shows organisations are starting to treat AI like a critical asset, which is the right direction. The deeper implication is that AI-connected credentials, service accounts, and data access paths must be managed as part of the same control fabric as other NHIs. Practitioners should stop separating AI risk from identity risk.

Proof of control is replacing claims of control. The 29% auditor finding matters because it reflects a shift from policy statements to evidence-based governance. In identity terms, that means access decisions, secret handling, and data boundaries must be demonstrable, not implied. Practitioners should expect AI governance to become a standing audit requirement, not a one-time assessment.

Identity blast radius is the right named concept for this category shift. AI-driven attacks do not create a new failure mode so much as they expand the impact of existing identity weaknesses across more systems, faster. Once access, secrets, and data workflows are all AI-mediated, a single over-permissioned identity can propagate risk across multiple control layers. Practitioners should design for blast-radius reduction, not just detection.

Speed is now a control variable in identity programmes. The report shows AI-based tools are moving up the priority stack while attackers also use AI to compress their own timelines. That creates a governance asymmetry: if defenders still rely on slow review cycles, they will lose visibility before access can be certified or revoked. Practitioners should align identity controls to machine-paced threat conditions.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• For a broader breach pattern view, see 52 NHI Breaches Analysis for recurring identity failure modes and root-cause patterns.

What this signals

Identity teams should expect AI governance to move from guidance to evidence. The article’s audit finding suggests that proof of control is now part of the operating model, not an afterthought. That means access records, revocation traces, and entitlement scope must be collectible on demand, especially for AI-connected workloads and service accounts.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, per the Ultimate Guide to NHIs, AI adoption will amplify an already fragile secrets posture unless teams tighten discovery and lifecycle discipline.

Shadow AI will matter because unmanaged access does. As teams add AI tools faster than they formalise governance, the practical risk is not just model behaviour but the identities attached to those systems. Security leaders should prepare for more access paths to require review, more secrets to require ownership, and more audit requests to demand evidence rather than assertions.

For practitioners

• Inventory AI-connected identities Map every AI workload, service account, API key, token, and orchestration account that can access sensitive data or security tooling. Include shadow AI paths created by teams experimenting outside formal procurement or IAM intake.
• Bring AI systems into access review Add AI-related credentials and permissions to the same entitlement review and recertification process used for other non-human identities. Document who approves access, what data is reachable, and how revocation is verified.
• Reduce identity blast radius Split high-risk AI functions from broader operational permissions, remove standing privilege where possible, and require narrower task-scoped access for any workflow that can reach sensitive systems.
• Build audit evidence for AI data access Preserve records that show access grants, policy scope, secret rotation, and revocation for AI-connected systems. Treat those records as proof of control for auditors, not as optional housekeeping.

Key takeaways

• AI-driven attacks are forcing organisations to rework identity and data security together, because the attack surface now includes AI-connected credentials and workflows.
• The evidence points to a governance shift toward proof, with auditors asking for data security and privacy evidence inside AI-based systems.
• Practitioners should focus on inventory, revocation, and auditability for AI-linked identities before attack speed outruns manual control cycles.

Key terms

• AI-connected identity: An AI-connected identity is any credential or account used by an AI system to access tools, data, or infrastructure. It includes service accounts, API keys, tokens, and certificates. In governance terms, it must be treated like any other non-human identity with ownership, scope, and revocation rules.
• Identity blast radius: Identity blast radius is the amount of systems, data, and workflows exposed when one identity is compromised or over-permissioned. For AI-driven environments, the blast radius can expand quickly because a single credential may feed multiple tools and data paths. Practitioners should manage it by reducing privilege scope and access duration.
• Shadow AI: Shadow AI refers to AI systems, agents, or connected tools that are in use but not fully inventoried or governed by the organisation. These hidden systems often create unmanaged identities, secrets, and data access paths. The governance risk is not the model itself, but the unseen control surface around it.

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 programme maturity, it is worth exploring.

This post draws on content published by Netwrix: Netwrix Research on AI-Driven Threats and Security Strategy Changes. Read the original.