AI now runs inside live malware. See where AI defence genuinely helps, where egress policy beats it, and a 30-day plan that needs no procurement cycle.
AI now sits inside live malware, not just in the tooling that builds it. Defending against that needs AI in some places and conventional controls in others. The highest-leverage counter to runtime-LLM malware is egress policy and endpoint telemetry, because the malware must reach an outside model to function at all.
The phrase covers two different things, and treating them as one produces bad buying decisions.
First, attackers use AI as a workbench. They draft phishing copy, write code, translate lures, and research targets faster. That has been happening for years, and it scales an attacker’s output rather than changing what the attack does.
The second is newer and stranger. Malware now calls a large language model while it runs, generating its commands or rewriting itself mid-execution. Google’s Threat Intelligence Group recorded the first live-operations sighting in November 2025. The distinction matters, because the second category leaves a signature the first never did: an outbound call to a model API from a machine that has no business making one.
Most writing on this subject argues that you need AI to fight AI. That is partly right. It is also the least actionable half of the answer, and it skips the controls you already own, which is the pattern set out in how automation is reshaping defence.
Named families give the argument something concrete to sit on. Google’s Threat Intelligence Group documented several through late 2025 and 2026.
| Family | What it does | Status |
|---|---|---|
| PROMPTSTEAL | Python data miner used by APT28 against Ukrainian targets. Queries Qwen2.5-Coder-32B-Instruct through the Hugging Face API to generate one-line Windows commands at runtime | Live operations |
| PROMPTFLUX | VBScript dropper that calls the Gemini API to rewrite its own source for just-in-time self-modification, and spreads through removable drives and the Startup folder | Development or testing |
| QUIETVAULT | JavaScript credential stealer targeting GitHub and NPM tokens. Uses AI prompts and AI CLI tools already installed on the host to hunt for further secrets before exfiltrating them | Observed in the wild |
| FRUITSHELL | PowerShell reverse shell that establishes command-and-control connections. Carries hard-coded prompts intended to evade LLM-based security analysis | Publicly available |
| PROMPTLOCK | Go ransomware that uses an LLM to generate and execute malicious Lua scripts at runtime for reconnaissance, encryption, and exfiltration | Proof of concept |
Read that table carefully before reacting to it. PROMPTSTEAL is the one Google describes as its first observation of malware querying a model in live operations, and QUIETVAULT was also seen in the wild. PROMPTFLUX, by contrast, was assessed as still under development, lacking any means to compromise a victim network or device, and PROMPTLOCK originated as research rather than as a criminal tool.
So the honest framing is that PROMPTFLUX previews a technique and PROMPTSTEAL proves it works. Neither justifies panic. Both justify checking whether your detection stack would notice a process on a finance workstation calling a model API.
Discover how Threatcop protects your workforce from modern cyber threats.
Capability headlines get attention. Timing is what actually breaks defensive assumptions.
Google’s Q2 2026 reporting describes adversaries moving from basic prompting to agentic workflows and automation. The consequence they name is specific: human-in-the-loop latency drops sharply, which compresses the window defenders have to respond.
One observed sequence makes that concrete. Threat actors compromised a cloud resource, then planned, built, and executed an agent-enabled mass credential harvesting campaign in under six hours.
Six hours is shorter than many organizations’ escalation path. It is shorter than a weekend. It is considerably shorter than the time between a suspicious alert and a human deciding it matters. Therefore the argument for automation on the defensive side is not that AI is clever. It is that a six-hour attack cannot be met by a process measured in days.
Four areas hold up under scrutiny, and they share a trait: high volume, low ambiguity, and a clear ground truth.
Each of those replaces work a person did badly because there was too much of it, not work a person did well. That is the useful test for any AI security purchase. Wider context sits in how AI is reshaping cybersecurity.
“AI-powered” covers at least three different technologies on a product page. Knowing which one you are buying decides what you can expect from it.
Classical machine learning came first and still does most of the work. A model trained on labelled examples scores new events against learned patterns. It is fast, cheap to run, and explainable enough to tune. Spam filtering and malware classification largely run on this, and it has been shipping for over a decade.
Large language models arrived next in the stack. They read unstructured text, so they summarise incidents, explain alerts in plain language, and judge whether a message reads like a pretext. They are slower, more expensive per event, and harder to audit when they get one wrong.
Agentic response is the newest and least proven. Here the system decides and acts, isolating a host or disabling an account without waiting for a person. Speed is the benefit. The risk is an automated action taken on a false positive, at machine scale, against production.
Ask any vendor which of the three they mean, and ask what happens when it is wrong. A classifier that misfires generates an alert somebody ignores. An agent that misfires takes your payroll system offline on a Friday afternoon.
The sequencing follows from that. Buy the classifier layer, then the language layer for triage, and treat autonomous response as something you pilot with tight scope rather than switch on across the estate.
The claim gets weaker in three specific places, and vendors rarely mark them.
Ground truth is the first. Detection models learn from labelled data, and novel attacks have no labels yet. A model trained on last year’s campaigns recognises last year’s campaigns, which is the same structural problem that limits signature matching.
Explainability is the second. When an analyst cannot establish why a system scored a message as benign, they cannot fix the miss. Opacity turns every false negative into a mystery rather than a lesson.
False positives are the third, and they are more expensive than they look. Alerts that prove wrong train people to dismiss alerts, which quietly degrades the human layer you still depend on.
None of that argues against buying AI defences. It argues for buying them where ground truth exists, and for not expecting them to cover the novel case that made you nervous in the first place.
One distinction reorganises the whole question of AI defence. Some controls belong to you. Others belong to a vendor and merely benefit you.
Model guardrails belong to the vendor. They are genuinely useful, and they are something an attacker works to bypass rather than something you operate. Google documented exactly that: an actor whose prompt was refused reframed the request as a capture-the-flag exercise, and the model then returned information that could be used to exploit the system. The actor reused the same pretext for phishing, exploitation, and web shell development.
That episode is worth holding onto. A safety layer you do not control, running on infrastructure you do not own, is not a defence you can point to in an audit.
The controls you own are ordinary: egress policy, endpoint telemetry, identity, and detection engineering. They are also the ones that work against runtime-LLM malware, for a reason covered next.
Malware that queries a model at runtime has a hard dependency. It must reach that model over the network. Cut the path and the technique fails, regardless of how sophisticated the generation step is.
That gives defenders something unusual: a choke point that does not require predicting the payload. PROMPTSTEAL reaches Hugging Face. PROMPTFLUX reaches the Gemini API. Both calls originate from a process that has no legitimate reason to talk to a model provider.
Practical steps follow directly.
Step 4 alone catches the documented families. It costs a detection rule rather than a licence.
Beyond egress, several behavioural signals distinguish this class from ordinary malware.
Self-modifying files are one. PROMPTFLUX rewrites its own source on an hourly cadence, which produces a file whose hash changes while its location and purpose stay constant. Hash-based controls miss that. File-integrity monitoring on script directories does not.
Persistence is another, and it is entirely conventional. PROMPTFLUX copies itself to removable drives and the Startup folder, which detection has handled for two decades.
Interpreter behaviour matters too. Python packaged with PyInstaller, or VBScript making outbound HTTPS calls, is unusual on a workstation that does no development. Combined with a model API destination, it is close to conclusive.
Emulation should catch up as well. If the adversary in your threat model generates payloads at runtime and reaches an external model to do it, your purple team exercises should include that path rather than stopping at file-based payloads.
Not every AI-enabled attack targets your endpoints. Some target the tools your developers trust.
Google tracked an actor, UNC6780, using multiple tactics to trick AI coding assistants and LLM security scanners into open-source software supply chain compromises. The target was not a person. It was the automated reviewer that a person relies on.
That inverts a common assumption. Teams adopt AI code review to catch what humans miss, then treat its approval as assurance. An attacker who can manipulate the reviewer gets a compromise signed off by the control that was supposed to prevent it.
The defensive answer is unglamorous: treat AI review as one signal, keep human review for dependency changes and build scripts, and pin and verify what you pull. Supply chain exposure of this kind is examined in third-party breaches reaching brands through vendors.
Two categories of AI risk exist, and they need separate budgets. One is attackers using AI against you. Another is attackers going after the AI you already use.
That second category is growing faster, because adoption outpaced controls. Any model your company runs is an input surface. An agent connected to a tool becomes an authority surface. And an AI code reviewer is a decision surface that an attacker would like to influence.
Prompt injection drives most of it. Models read instructions and data through one channel, so they cannot tell a document’s contents from a command. Hostile text inside a web page, a PDF, an email, or a code comment can redirect the model that processes it. OWASP has ranked prompt injection first in its Top 10 for LLM Applications across consecutive editions for exactly this reason.
Excessive agency compounds it. OWASP moved that risk from sixth place in its 2025 list to third in the 2026 edition, reflecting how much real authority agents now hold. Injection gets an attacker in. Permissions decide what they reach.
The practical consequence is that AI defence spending splits in two. Money spent detecting AI-enabled attacks does nothing to protect the agents in your own environment, and money spent hardening agents does nothing about runtime LLM malware on an endpoint. Confusing the two produces a budget that covers neither properly.
AI-enabled attacks change what employees see. The tells that awareness training taught for a decade are the tells automation removed first.
Bad grammar is gone. Generic salutations are gone. Mismatched branding is gone, and Google’s June 2026 disruption of a China-based service providing phishing kits for mass brand impersonation shows the industrial version of that. The operators used Gemini to generate code and run campaigns at scale, and Google pursued legal action over the misuse, the first time it has done so.
Consequently recognition training built on surface flaws is depreciating fast. What survives is procedural: verify unexpected requests through a second channel, never act on an instruction that arrives with urgency attached, and report rather than resolve.
Threatcop’s TLMS delivers that as role-based scenarios rather than one annual module, so the finance team practises the callback and developers practise questioning an approving tool. Programme design for this sits in role-based training matched to job function.
Use the table rather than the vendor’s demo. The question in each row is whether ground truth exists and whether speed is the binding constraint.
| Defensive job | Buy AI? | Why |
|---|---|---|
| Alert triage at volume | Yes | Clear ground truth, and humans fail on volume rather than judgment |
| Cross-source correlation | Yes | Speed is the constraint, and the data is structured |
| Outbound egress control | No | A policy decision and a firewall rule already solve it |
| Detecting novel attack classes | Cautiously | No labels exist yet, so expect partial coverage |
| Phishing content detection | Partly | Helps with volume, misses payload-free requests entirely |
| Deciding what an agent may access | No | A permissions question, not a detection question |
| Workforce recognition of pretexts | No | AI cannot make the decision a person makes under pressure |
Two rows say no for the same reason. Some problems look like detection problems and are actually configuration or authority problems, and no model fixes those.
None of the AI defence work above requires a procurement cycle. This sequence fits in a month, and it closes the gap the documented malware families depend on.
Week 1. Pull outbound traffic logs and identify every host that contacted a model API provider in the last 90 days. Sort by whether the contact makes sense. Most companies find calls from machines nobody expected.
Week 2. Build the allowlist from that review, not from a theory of who should need access. Then write the default-deny policy for everything else, starting with servers, finance workstations, and shared terminals, where legitimate model use is rare.
Week 3. Deploy the first-contact alert. Any host reaching a model provider for the first time generates a single low-noise event. Tune it for a week and accept that developers will trigger it legitimately, since that is the point.
Week 4. Run the test. Have someone simulate the documented technique: a script on a non-developer host that calls a hosted model and acts on the response. Confirm the alert fires, confirm someone sees it, and confirm they know what to do.
Week 4 is the one people skip, and skipping it means you bought a rule rather than a detection. A control nobody has exercised is a control nobody can rely on during the six-hour window this whole post is about.
Vendor metrics describe the product. These describe your position.
The third and fifth are the ones to watch. Both measure whether your AI investment is quietly degrading the human layer it was meant to support.
Before evaluating any AI security product, write down which machines in your environment have a legitimate reason to reach a model API. In most companies that list is short, and almost nothing on it is a server or a finance workstation.
Then default-deny the rest and alert on first contact. That single rule counters the documented runtime-LLM malware families, costs a configuration change rather than a licence, and gives you a number you can show an auditor.
After that, spend on AI where volume and speed genuinely beat human capacity, and keep training the people who still have to judge the requests no model can score.
Partly. AI genuinely helps where volume and speed are the constraints, such as alert triage and cross-source correlation, and where ground truth exists to train on. It helps far less against novel techniques with no labelled data. Against malware that calls a model at runtime, conventional egress policy and endpoint telemetry are more effective and considerably cheaper.
AI-enabled malware queries a large language model while running, rather than being merely written with AI assistance. PROMPTSTEAL, used by APT28 against Ukrainian targets, queries a hosted model through the Hugging Face API to generate Windows commands at runtime. PROMPTFLUX calls the Gemini API to rewrite its own source code for just-in-time self-modification, though Google assessed it as still in development.
Watch outbound traffic to model API providers from hosts that have no reason to reach them, and alert on first-time contact. Add file-integrity monitoring to catch self-rewriting scripts whose hashes change while their location does not. Flag interpreters such as PyInstaller-packaged Python or VBScript making outbound HTTPS calls on non-developer machines.
Model guardrails help, and they are not a control you own. Google documented an actor whose request was refused, who then reframed it as a capture-the-flag exercise and received usable exploitation information. A safety layer running on infrastructure you do not operate cannot be evidenced in an audit or tuned to your environment, so treat it as a vendor benefit rather than a defence.
Faster than most escalation processes. Google’s Threat Intelligence Group observed adversaries compromise a cloud resource and then plan, build, and execute an agent-enabled mass credential harvesting campaign in under six hours. The reported effect is a sharp reduction in human-in-the-loop latency on the attacker’s side, which compresses the defender’s window to respond.
Adhish Chakma is a Senior Product Manager at Kratikal, where he leads product initiatives focused on cybersecurity and AI-powered solutions. With experience in product management and cybersecurity, he works on developing practical technologies that address evolving security challenges. His areas of interest include People Security Management, cybersecurity awareness, AI-driven security, email security, and human-layer risk. He is passionate about building security products that make organizations more resilient against emerging cyber threats.
AI phishing prevention starts with a correction: AI authorship cannot be measured reliably. See which recognition signals died, which...
Continuous compliance readiness means evidence accumulates as controls operate. See what assessors ask for, the parameter trap, and a...
Attacks against AI target the system itself, not your inbox. See the three OWASP lists covering the model, agent,...
