The article draws on Netwrix’s 2026 Data and Identity Security Report, released June 10, which says organizations where AI materially increased the number of access identities reported a 43% breach rate in the preceding year, compared with 11% among organizations where AI did not materially change access patterns. Netwrix surveyed IT and security professionals rather than measuring incidents directly, so the figures show correlation, not proof that AI-driven identity growth caused the breaches. Still, the warning fits the operational reality of a plant: a new AI system is useful only once it can read data, call tools, query repositories, or trigger a workflow—and every one of those capabilities must be authenticated and authorized.
For Windows and identity administrators, the immediate issue is not whether an AI tool has a human-style login. It is whether the tool acquires a durable path through Active Directory, Microsoft Entra ID, an MES database, an engineering file share, a historian, a PLM repository, or a vendor remote-access gateway. An unowned service account with an old password is no less consequential because it was created for an integration project instead of an employee.
The survey’s breach number needs careful reading
Netwrix’s 43% versus 11% result is attention-grabbing, but it should not be used as a forecast that deploying AI makes an organization four times as likely to suffer a breach. Organizations expanding AI fastest may also have more complex environments, more sensitive data, more integrations, or more mature incident detection than organizations that have not. Those factors can raise both the number of identities and the number of reported incidents.
There is also a reporting inconsistency worth flagging. Netwrix’s June press release says its 2026 report was based on responses from 2,317 professionals representing 1,889 organizations in more than 60 industries. A Netwrix research landing page describes a survey of 2,150 IT professionals in 121 countries. Neither the Manufacturing Business Technology article nor the public summary explains why the respondent counts differ, how many manufacturers were included, or the statistical margin of error for the manufacturing subgroup.
That omission limits how precisely readers should interpret the sector percentages. Manufacturing Business Technology reports that only 34% of manufacturers had a complete inventory of sensitive-data locations, 21% could immediately identify the identities with access to that data, and 19% were fully confident they could detect risky combinations of access. Those findings are useful as maturity indicators, but no other independent outlet located in reporting on this story has published the underlying manufacturing sample size or cross-tabs.
The broader point stands without over-reading the percentages. A plant cannot apply least privilege to data, controls code, and production systems it has not mapped, and an AI agent cannot be safely constrained when its permissions are inherited from an account nobody can confidently explain.
Vendor remote access is the old problem AI makes easier to miss
The article’s example of a systems integrator retaining a broad, non-expiring account after commissioning is familiar to industrial defenders for a reason. Remote vendor access often begins as a legitimate operational necessity: an OEM must troubleshoot a robot cell, a controls integrator must update a programmable logic controller, or a support contractor must diagnose an MES failure during an outage.
The account’s purpose expires at project close; the access often does not. In a conventional environment, that is already a standing-privilege problem. In an AI-enabled environment, the same account can become one permission among many available to an agent, workflow engine, or analytics platform that has been connected to the same directory and data sources.
CISA’s industrial remote-access guidance has long warned that vendor-access credentials and embedded field-device accounts can be difficult to rotate, sometimes because equipment vendors do not support changing administrative credentials or because a maintenance window is required. CISA also recommends multifactor authentication for remote access to operational technology and specific controls for vendor and maintenance accounts, engineering workstations, and human-machine interfaces.
The practical implication is that “remove the old account” is not an adequate factory-floor program. Administrators need to distinguish among at least four things that are often collapsed into one account inventory:
- A person’s named account should have a manager, employment or contract status, a defined role, and a revocation path.
- A vendor session should be time-bound, approved for a stated purpose, logged, and mediated through a controlled remote-access path rather than a permanent privileged credential.
- A workload identity for an MES connector, historian collector, or AI inference service should have a technical owner, narrowly scoped permissions, credential-rotation requirements, and a documented dependency map.
- A device or embedded identity that cannot be easily changed should be treated as an exception with compensating controls, segmentation, monitoring, and a retirement plan rather than accepted as ordinary infrastructure.
This distinction is where many identity-governance programs break down. Human joiner-mover-leaver processes are often reasonably mature. Project-created accounts, API keys, certificates, service principals, local administrator passwords, and machine credentials are managed by different teams and disappear into ticket histories.
AI agents make authorization more consequential
NIST is now explicitly examining identity and authorization for software and AI agents, including the hard questions manufacturers will recognize immediately: how to identify an agent, issue and revoke its credentials, establish least privilege when its future actions may not be fully predictable, bind actions to a human authority, and preserve an auditable record.
That matters because an AI copilot that summarizes maintenance tickets and an AI agent that can open a work order, query a PLC-support repository, or invoke an API are not equivalent security cases. The latter has operational authority. Giving it a generic integration account with broad access creates an automated insider whose actions can be legitimate at the protocol level even when they are unsafe, erroneous, or triggered by manipulated input.
Manufacturing Business Technology says 41% of organizations in the Netwrix survey already use agentic AI in production with access to enterprise information, while 76% do not fully govern or monitor non-human identities. Whether or not those exact proportions hold for every plant, the design issue is concrete: an agent must have a distinct identity, a bounded task, narrowly delegated permissions, and logging that connects its action to the human or service that authorized it.
A shared service account defeats that chain of accountability. If an AI workflow authenticates as the same credential used by a dashboard, a nightly integration job, and an engineering utility, the incident record can reveal what account acted but not which system, model version, input, approval, or operator caused the action. That turns investigation into reconstruction from incomplete logs.
Active Directory remains a production dependency
The article’s recommendation to assess Active Directory attack paths before connecting more AI workloads is more than a Windows housekeeping exercise. In many manufacturing environments, Active Directory remains the bridge between office systems, engineering workstations, file servers, plant applications, remote access, and hybrid cloud services. A weak privilege assignment, stale group membership, unconstrained delegation setting, or service-account credential can therefore travel farther than the team that created it intended.
Netwrix says only 20% of manufacturing respondents were fully confident their Active Directory environment had no misconfigurations that could enable privilege escalation. Confidence is not a technical measurement, and the company’s survey cannot establish the actual prevalence of vulnerable configurations. But the control objective is sound: do not increase the number of automated workloads trusting AD until the organization has identified privileged paths, legacy service accounts, dormant administrative groups, and accounts whose passwords or secrets cannot be rotated safely.
For a Windows-based environment, the first review should focus on the systems whose compromise would stop production or expose core intellectual property: domain controllers supporting plant operations, jump servers, engineering workstations, MES application servers, file shares holding controls code, CAD and PLM repositories, and the identity stores used by remote-access infrastructure. Those are the paths through which an apparently modest AI deployment can acquire far more reach than its owner intended.
The audit should also identify where AI systems authenticate. “The model” is rarely the principal with access. The actual access may be held by an Entra application registration, a managed identity, a service account, a database credential, a certificate on an integration host, or a token stored in an automation platform. An inventory that records only the AI vendor name will miss the credential that creates the operational risk.
Start with ownership and expiry, not an AI policy document
Manufacturers do not need a multi-year transformation program before applying useful constraints. They need an enforced intake gate for AI-connected workloads and a reliable way to identify which credentials already reach high-value production and engineering systems.
Every AI deployment should have one accountable owner, an approved list of data sources, a defined set of allowed actions, and an access expiration or reauthorization date. The expiry condition is important: production projects end, contractors leave, models are replaced, and pilot integrations outlive their original business sponsor. A credential without a current owner should be treated as a decommissioning candidate until someone demonstrates a production dependency.
Next, put third-party operational access behind time-limited sessions wherever the equipment and support arrangement permit it. The target should be zero standing vendor privilege on production systems, with exceptions documented where legacy devices or emergency-support contracts prevent immediate change. For those exceptions, isolate the access path, require strong authentication at the gateway, record the session, and ensure the vendor’s account cannot silently become a general-purpose identity inside the corporate directory.
Finally, test revocation as an operational procedure, not a policy statement. If a contractor account, service principal, certificate, or AI integration token must be disabled during an incident, administrators should know which production functions will fail, who approves the interruption, and how to restore a safe configuration. A credential that cannot be revoked without a plant outage is a business dependency that belongs in change control and risk management.
Manufacturing Business Technology is right to put identity security on the factory-floor AI agenda. The useful action is not to inventory every AI idea first. It is to stop granting new systems indefinite access to old production environments whose identities, owners, and privileges have never been fully reconciled.