AI Cyberattacks Are Becoming Autonomous: What Manufacturers Must Protect First

Inzonex ResearchPublished Sources checked 12 September 20268 minute read

Attackers now run intrusions the way plants run automated lines: humans set the target, software does the work. A September 2026 threat report documents campaigns in which AI agents performed nearly all the technical steps. No documented case reached industrial control systems. For manufacturers the priority is unchanged but more urgent: remote access, identity, vendor accounts and the boundary to the plant network.

What the report documents

On 10 September 2026 Anthropic published a threat intelligence report describing how its models had been misused and the accounts banned. In several of these campaigns the human contribution had shrunk to choosing targets, refining instructions and reviewing the results. The technical steps ran as software.

Campaigns documented in the September 2026 report, and what the human still did. All facts in this table are from that report.
CampaignScale reportedWhat the automated workflows didWhat the human did
State-nexus espionageMore than 20 organisations, including government bodies, defence-related companies and think tanksReconnaissance, phishing infrastructure, credential harvesting, exfiltration, and autonomous rebuilding of malware when detections firedRefined the instructions that drove the workflows
Financially motivated data theftTargets including a technology provider, an airline, an energy company and a SaaS vendor with more than 200 downstream customersCredential pipelines, key validation, privilege escalation, database extraction; agents “performed nearly all of the work”Set the objective, then let the agents evaluate and act
Vulnerability research and intrusionAbout 50 organisations across sectors including manufacturing, energy, healthcare and governmentIterating exploit code automatically; one workflow produced more than a dozen possible zero-day findings in a single month; a standing fleet of collection agents ran unattendedDirected targeting and reviewed output
Supply-chain reconnaissanceAbout thirty companies targeted within four daysParallel reconnaissance and exploitation agents launched from a per-target scope fileMaintained the scope file
Single-operator campaign42 tracked target entities, with internal access obtained to at least 14Exploit development and debugging, web shells, reconnaissance, and a purpose-built data platformOne individual ran the entire operation

Two details carry the most weight. In one intrusion the agents rebuilt malware by themselves when existing detections fired, which compresses a defender's traditional advantage: detection used to buy time while the attacker retooled. In another, a single automated workflow iterating on network appliances produced more than a dozen possible zero-day findings in one month, which changes the economics of finding unknown flaws in the kind of edge equipment that sits in front of many plants.

An autonomy scale for intrusions, and where documented cases sitFour bands run from human-operated through agent-assisted to agent-operated and finally fully autonomous. The documented September 2026 campaigns sit in the agent-operated band, where humans still set targets and review results. The fully autonomous band is marked as not documented.Autonomy is a description of execution, not of intentThe distinction that matters to a defender is how fast a foothold becomes a wider position.less automatedmore automatedHuman-operatedA person performs eachstep; tools assistAgent-assistedA person directs;software executessub-tasksAgent-operatedA person sets goals andreviews; agents execute,iterate and adaptFully autonomousNo human sets targets orreviews resultsDocumented September 2026Fully autonomous attacks: not documentedSource: Anthropic threat intelligence report, 10 September 2026. Band definitions and placement are Inzonex analysis.
Documented activity sits in the agent-operated band: humans chose targets and reviewed results while software executed. Band definitions and placement are Inzonex analysis of the reported cases.

Cost, speed and technique

The techniques in these campaigns are the ones defenders already know: phishing, stolen credentials, exposed services, privilege escalation, bulk extraction. Nothing in the report describes a novel class of attack. The cost of carrying them out fell.

Reconnaissance, exploit iteration, credential validation and data triage used to consume skilled human hours, and that scarcity was a quiet form of protection for ordinary organisations. Automating those steps removes the scarcity. One consequence is visible in the reported cases: an operation of a scale that would previously have implied a team was run by one person, and about thirty companies could be worked through in four days.

For a manufacturer the practical translation is about timing. Controls that assume a human attacker needs days to move from a foothold to something valuable are now working against a shorter clock.

What the report does not say

No operational technology cases

The report contains no documented case, reference or statement involving operational technology, industrial control systems, SCADA or programmable logic controllers, and no instance of a physical process being altered. Manufacturing and energy organisations appear among the victims of one campaign, but the documented activity is theft of data and access in corporate and cloud environments.

This distinction is worth defending against the way such reports are usually summarised. A headline that converts these cases into attacks on factory automation is describing something that was not reported.

What to protect first

The priority list below is ordinary. It is ordinary because the documented attacks were ordinary in technique, and faster execution rewards the same controls it always did. Each row states why it is on the list.

Where to look first, and why each one is on the list
PriorityWhat it coversWhy it matters nowThe practical test
Remote access pathsEvery VPN, jump host, vendor portal and remote-support toolTurns a stolen credential into a working sessionMulti-factor authentication on all of them, with no vendor exceptions
Identity and privilegeAccounts, API keys, service accounts, tokensAutomated pipelines validate stolen keys at machine speedRemove standing privilege; rotate and scope keys; alert on first use from a new source
Vendor and SaaS accountsAnything a third party can reach your data throughOne compromised vendor reached more than 200 downstream customersInventory who holds access to what, and require notification terms in contracts
Engineering workstationsThe machines that hold project files and program controllersThey bridge the office network and the plant, and NIST names them for host-based monitoringSeparate them from general office use; monitor them; control removable media
Exposed servicesAnything answering from the internet, especially network appliancesAutomated research loops iterate on appliances continuouslyKnow the external surface; patch appliances first; remove what is not needed
Backups and recoveryOffline or immutable copies, and a tested restoreSpeed of theft raises the value of being able to restore and continueTest a restore against a defined recovery time, not a policy document
The IT and OT boundaryThe connection between corporate and plant networksA faster intrusion is still confined by a boundary that is actually enforcedDemilitarised zone, no direct traffic, documented and reviewed exceptions
A plausible route from an external account towards plant systemsFour stages in sequence: a vendor or SaaS account, corporate IT, an engineering workstation, and the boundary between IT and plant networks. Beneath each stage is the control that interrupts it: multi-factor authentication and an access inventory, least privilege and monitoring, workstation separation and media control, and a demilitarised zone with no direct traffic.The path that matters to a plant, and the control that interrupts each stepThis route is an Inzonex construction from NIST architecture guidance. It is not a documented attack chain:the September 2026 report documents no intrusion that reached operational technology.Vendor or SaaSaccountExternal, often outsideyour monitoringCorporate ITMail, files, identity,remote accessEngineeringworkstationProject files, controllerprogramsIT / OT boundaryWhere the intrusionshould stopMFA, access inventoryLeast privilege, monitoringSeparation, media controlDMZ, no direct trafficControls above are drawn from NIST SP 800-82r3, which recommends separating OT from corporate networks,employing a DMZ so direct traffic is prevented, and using multi-factor authentication for remote access.
An Inzonex construction of the route a plant should assume, with the control that interrupts each step. The documented campaigns did not reach the right-hand stages; the diagram exists so the boundary is checked before that changes.

IT, OT and safety systems

These three layers fail differently, and conflating them produces bad decisions in both directions.

Corporate IT is where the documented attacks operated. The loss is data, credentials and continuity of office work. Operational technology runs the physical process. NIST puts the difference plainly: OT security objectives typically prioritise integrity and availability, followed by confidentiality, and must treat safety as an overarching priority. An hour of unavailability in corporate IT can stop dispatch, ERP and order processing, and with them production. An hour in operational technology stops the process itself and can create a safety condition. Safety instrumented systems exist to bring the process to a safe state; they are not a cybersecurity control and must not be the last line of defence against a network intrusion.

NIST's architectural guidance is unambiguous and predates this tooling. It recommends separating OT networks from the corporate network, and characterising, segmenting and isolating IT and OT devices, using a recognised model such as the Purdue model or ISA-95 levels. It recommends a demilitarised zone that prevents direct traffic between corporate and OT networks, multi-factor authentication for remote access to OT, and restriction of user privileges to what each role requires. It also names engineering workstations, alongside human-machine interfaces and SCADA servers, as candidates for host-based monitoring where that does not degrade operational performance or safety.

None of this is new advice. The reason to revisit it is that the interval between a foothold and its exploitation has shortened, and a boundary that exists on a drawing but not in the switch configuration will be found faster than it used to be.

The connection you already have

NIST notes that practical considerations usually mean a connection is required between OT and corporate networks. The useful exercise is not to claim the plant is air-gapped. It is to list every existing connection, name what each one is for, and confirm that each is mediated rather than direct.

What this means for manufacturers

  1. Enumerate remote entry

    List every way a person or vendor reaches your systems from outside, including support tools installed for a single commissioning job. Apply multi-factor authentication to all of them, as NIST recommends for remote access to OT.

  2. Inventory third-party access

    One compromised supplier in the reported cases reached more than 200 downstream customers. Know which vendors hold credentials, what those credentials reach, and how you would be told.

  3. Treat engineering workstations as plant equipment

    They hold controller programs and sit at the boundary. Separate them from general office use, monitor them and control removable media.

  4. Test the boundary, not the diagram

    Verify that no direct traffic passes between corporate and plant networks, and that every exception is documented, owned and reviewed.

  5. Shorten the detection-to-response gap

    Agents rebuilt malware when detections fired. An alert that waits for the next working day is worth less than it was.

  6. Rehearse recovery against the clock

    Confirm offline or immutable backups and test a restore against a stated recovery time for the systems production actually depends on.

Limits and open questions

  • One vendor's visibility. The report describes misuse detected on one company's platform. It is not a survey of AI-enabled attacks, and it cannot show what happened elsewhere.
  • No frequency data. Nothing in it supports a statement about how common these methods are, or what share of intrusions they represent.
  • Attribution is the publisher's. Actor identification and intent come from that investigation and are not independently confirmed here.
  • Absence is not proof. That no OT case was documented does not mean control systems are not targeted. It means this report is not evidence that they were.
  • No cost figures. There is no published basis for stating what these intrusions cost victims, so any percentage or loss estimate attached to them is invented.

Intrusion work is being automated, which compresses the time available to respond. The controls that answer it are the ones already written down, and prove the boundary between the office network and the plant this quarter.

Questions

Has AI created new kinds of cyberattack?

Not according to the documented cases. The techniques are familiar: phishing, credential theft, exploitation of exposed services, privilege escalation and bulk data theft. The cost and the pace changed. Work that needed a skilled operator's time is now executed by agents, so one person can run what previously required a team.

Were industrial control systems attacked?

The report contains no cases involving operational technology, industrial control systems, SCADA or PLCs, and no instance of a physical process being manipulated. Manufacturing and energy organisations appear as victims, but the documented activity is theft of data and access in IT and cloud environments.

Is a human still involved?

Yes. In the documented campaigns humans chose targets, reviewed results and refined the instructions that drove the automated workflows. Humans set intent; the execution runs as software. The pace of an intrusion is therefore set by software while the defender's response is still set by people.

What should a manufacturer do first?

Nothing exotic. Enforce multi-factor authentication on every remote entry point, inventory vendor and SaaS accounts that can reach your data, and confirm that a compromise of the corporate network cannot reach the plant network directly. These are long-standing recommendations that faster attacks make less optional.

Does faster attack tooling change the IT and OT boundary?

It raises the value of the boundary rather than changing its design. NIST's guidance to separate OT networks from corporate networks, employ a demilitarised zone and require multi-factor authentication for remote access predates this tooling and still holds. The difference is how quickly an attacker converts a foothold into a wider position.

Sources

Suggested citation: Inzonex Research (2026), AI Cyberattacks Are Becoming Autonomous: What Manufacturers Must Protect First, published 12 September 2026. Campaign facts are attributed to the Anthropic report of 10 September 2026. Architecture and control guidance is from NIST SP 800-82r3. The autonomy scale, the route diagram and the protection priorities are Inzonex analysis.

Related industrial AI analysis