One malicious core.
Many disposable variants.

Defenders have often benefited from attackers reusing familiar components. Reuse creates recognisable patterns, allowing one detection to help catch later samples. AI-assisted coding can weaken that advantage by changing the code’s structure without necessarily changing its purpose.

For management, the consequence is not simply “more malware”. It is more variation to classify, more alerts to investigate, and more opportunities to exploit gaps between teams or tools. The cost of an unsuccessful attempt can remain low enough for the attacker to keep trying.

Lower barriers can make less experienced operators more productive without turning them into expert intrusion teams. More capable groups gain a different advantage: less time spent on repetitive engineering and more capacity to adapt existing work. Both effects can increase the pressure on defenders, even when the individual techniques are familiar.

That does not make the attacker’s marginal cost literally zero, or establish that every generated sample will work. It changes the question worth asking: are the controls effective against the activity and the exposure, or only against a set of files they already recognise?

Researchers at University College Cork examined AI-generated malicious shell-script permutations. Their peer-reviewed paper reports that code structure varied while runtime behaviour remained largely consistent; dynamic and behavioural techniques were more robust than the static approaches tested.

The scope matters. This was research into a particular malware class, including scripts associated with Linux-based connected devices—not proof that every signature will fail against every AI-written program.

The useful procurement test follows from the distinction. A demonstration that recognises known samples does not establish coverage of unfamiliar activity. Ask the team to show what it can observe, which relevant behaviours are tested, what remains invisible, and how a supported finding reaches someone authorised to act.

McAfee’s analysis found large numbers of software lures around a smaller set of underlying loaders. Its assessment of AI assistance concerned particular components, especially scripts; it did not establish that an AI system autonomously designed or ran the entire campaign.

Nor are the four counts interchangeable. A ZIP archive is a package, a loader variant is a distinct malicious component, a lure filename is a presentation, and a URL is a distribution route. They cannot be added together as a single “attack total”.

The business lesson is the mismatch in effort. A campaign can offer many apparently different entry points while reusing much of the machinery behind them. Blocking a named file remains useful, but it does not settle the risk from the next package, another download location, or an endpoint outside monitoring coverage.

AI can help produce software before it is deployed; some malware also calls a model while it runs. Google Threat Intelligence Group’s November 2025 report documents both operational evidence and experimental work. Those are different levels of maturity.

Even when code adapts, achieving an objective usually still involves activity on a device, an identity, or a network. That gives defenders opportunities, not certainty: sensor coverage, visibility into legitimate tools, false positives, and the speed of response all affect whether suspicious activity is recognised in time.

The measured position is to take the evidence seriously without buying an autonomous-warfare story. Dismissing all AI-assisted malware as poor-quality output is as unhelpful as assuming that an AI label makes it unstoppable.

A sensible response combines prevention, behavioural monitoring, identity controls, and rehearsed response. It does not discard antivirus, and it does not assume that purchasing endpoint detection and response will automatically deliver the desired outcome.

Endpoint and extended detection and response (EDR/XDR), central event monitoring, and disciplined threat hunting can each contribute to that operating model. Their value depends on what they cover and who investigates the evidence. Collecting activity without the context or authority to act is not an effective detection strategy.

A behavioural model such as MITRE ATT&CK can help organise the coverage conversation. Mapping a rule to a technique is not evidence that every instance will be detected: test the relevant situation, record the result, and retain the limits of the test.

Include the cost of false positives and investigation time in any product evaluation. More alerts are not an improvement if they prevent the team from finding the event that threatens an important business service.