Living off the Harness

The cyber threat intelligence assumptions adversary AI is already breaking

Oct 13, 2026

Diagram of the harness around an AI model: its access to files and credentials, the settings and hooks that run commands, and the approvals that decide what it runs without asking. Eight cases seen in the wild came through the harness and 19 through prompts, skills or MCP.
Living off the Harness

We went looking for malware that thinks for itself. The cases with real victims pointed somewhere else: the AI tools developers already use. 

Yury Sergeev and Alex Gould  – Based on our talk at the Australian Cyber Conference (CyberCon) Melbourne 2026. 

When we proposed this talk, the thing that worried us was malware that rewrites itself using a model. That is not where we ended up. Two things moved us. New cases pointed somewhere else, and when we went back to a source we had relied on, we found we had got ahead of its evidence. So we did one more thing. We counted. 

The headline, tested against the data

The headline was simple: adversary AI is malware that thinks for itself. So we tested it. We screened 3,980 public threat reports from August 2025 to September 2026, removed duplicates and kept the original reporting. With two Anthropic reports from outside our index, that gave us 319 cases where AI was part of an attack. We asked one question of each: was it seen in the wild, or only in a lab? 293 were seen in the wild.

Malware that calls a model while it runs on the victim’s machine: 18 of those 293. Attacks on AI itself: 19 through prompt injection, skills and MCP, and 8 through the software around the model. Attackers running AI agents on their own machines accounted for 29, and they are speeding up: three cases first reported from August to December 2025, seven from January to April 2026, and nineteen from May to September 2026. The biggest group by far was AI as the helper, with 185 cases: AI writing the malware, the phishing and the scam sites, making deepfakes, or automating the operator’s daily work.

Our count of 293 AI-related attack cases seen in the wild, from 3,980 public threat reports. Attacks on your AI: 8 Living off the Harness, 19 prompt injection, skills and MCP, 34 AI infrastructure and users. Attacks using AI: 29 attacker-run agents, 18 custom AI malware. AI as the helper: 185.
The headline, tested against 293 cases seen in the wild, from 3,980 public threat reports.

One honest limit: these are public reports, so this is what gets reported, not every attack. Read the numbers as most reported, not most common. 

What is the harness? 

When you use an AI coding agent, the model is only one part. Around it is everything else: its access to your machine, the settings and hooks in your projects, and the approvals that decide what it can run without asking. That is the harness. 

We call the pattern Living off the Harness. Like living off the land, the attacker brings no new tool. They use the one you already trust, and the model is optional. Eight public cases seen in the wild have come through the harness so far. That is a small number, and we think it will grow, because there is very little on the internet to scan for. (The term “living off the agent” is already in use, but as published it describes steering an agent with instructions, which is prompt injection. These cases needed a name for the part around the model.)

Nx: the attacker borrowed an assistant 

In August 2025, malicious versions of the Nx build packages were published to npm. When a developer installed one, the attacker’s code ran on their machine; so far, an ordinary supply chain compromise. Then the malware went looking for AI command line tools already installed and tried to use them to hunt for sensitive files. It tried Claude Code with its skip-permissions flag, Gemini CLI with yolo mode and Amazon Q CLI with trust-all-tools. Snyk and StepSecurity published that code on 27 August 2025, and Wiz reproduced it a week later. 

The adversary brought no AI of their own. The tool was approved; the attacker found another way to start it. If you only look at the application name, a developer launching the assistant and a package launching it during an install with the prompts disabled look the same. The difference sits around the launch: who started it, with which settings, in whose account, and what it did next. Approving a tool is not the same as approving everything that can start it. 

ChainDrop and Miasma: the settings did the work 

VS Code lets a project say “when someone opens this folder, run this”. Claude Code lets a project say “when someone starts a session here, run this”. They are real features with good reasons behind them. The ChainDrop npm worm wrote both into the projects it touched, then waited for a developer to go back to work. 

Unit 42’s analysis is careful about outcomes, and so should we be. In the build they examined, only one of the two routes reached a payload: the one that fires when the folder opens. The other pointed at a file the worm never dropped. Planting a mechanism and getting execution from it are different findings. And the real infection had already happened when the package installed; these files were the way back, not the way in. 

What is not happening anywhere in this is also worth noticing. No prompt. No model deciding anything. A configuration file named a command, and a legitimate feature ran it. ChainDrop was not alone: in June 2026 StepSecurity reported Miasma planting start-up files for Claude Code, Gemini CLI, Cursor and VS Code, and GitHub disabled 73 repositories across four Microsoft organisations. 

That changes the cleanup question. It is not only “have we removed the bad package?” It is “what did that install leave in the project, and what will run the next time somebody opens it?” 

GitSpawn: execution before you decided to trust

Picture a project that arrives as a zip file, with its own .git directory inside. A normal clone, fetch or pull will not carry repository-local Git settings across; a copied folder or archive can. Manifold’s GitSpawn research, published on 1 September 2026, showed how that could play out. The agent does routine housekeeping, which means calling Git. Git reads the repository’s own configuration, finds a setting called core.fsmonitor, and can run the command in it. In the Claude Code example Manifold disclosed, that happened before the workspace trust prompt was accepted. 

This is a researcher’s demonstration, and triggers and affected versions vary by product, so patching comes first. But the question outlives the patch: what is this software doing while it gathers context, before the part you think of as using the assistant? 

Three cases on one attack surface. Nx, August 2025, borrowed installed AI tools with permission prompts off. ChainDrop planted a Claude Code hook and a VS Code folder-open task. GitSpawn used a copied repository’s Git setting to run a command. In two of the three, the model was never asked anything.
Three cases, one surface. In two of them the model was never asked anything.

Where our own assessment moved

You can put a guardrail on every prompt in the building. ChainDrop never sent one. Google’s threat intelligence team, reporting on 8 September 2026, described DUSTMAKER dropping files into coding tool workspaces so that something runs when the workspace opens, and ACRSTEALER controllers going after Cline and Continue configuration files, which can hold API keys. Model security still matters. The files, start-up behaviour and credentials around the model need someone looking at them too. 

We also owed our original concern the same scrutiny. PROMPTFLUX was the headline idea in the early reporting: malware that asks a model to help rewrite its own code. Google’s November 2025 assessment placed it “in a development or testing phase, as opposed to being used in the wild”. Almost nine months later, a contributed article described the same family as malware running on a compromised machine, citing Google, with the qualification gone. Our own submission for this talk made the same mistake. The distinction was in the report and we read past it. Malware that calls a model is real, though: the same Google report called APT28’s PROMPTSTEAL its “first observation of malware querying an LLM deployed in live operations”. PROMPTFLUX just was not one of those cases.

Three checks follow. Check the status of the specific finding, not the headline. Keep the hedge attached to the claim all the way through your own writing. And check when the activity happened, which is not when somebody published about it. Dropping one word can move a report between an incident response and a note to revisit later. 

What attackers actually ran 

Mostly, the same tools we use. Of the 29 cases with attackers running AI agents in the wild, 20 used an agent tool anyone can get, and 15 of those were the AI agents developers use, such as Claude Code, Codex, Hermes, Qwen Code, Cursor and OpenClaw. That is not Living off the Harness, since these harnesses run on the attacker’s machine, but it is the same software. 

GreyNoise reported hundreds of agents running on OpenAI’s Codex with a DeepSeek model plugged in, against PaperCut instances hosted by 395 organisations in 48 countries. Gambit Security found Claude Code generated and executed about 75 per cent of an attacker’s remote command activity in a campaign in Mexico. CloudSEK found approval prompts globally disabled. In a separate campaign without a confirmed AI-driven compromise, Unit 42 recovered Claude Code set to skip permissions and Qwen Code in yolo mode. 

Bar chart of 29 attacker-run AI agent cases seen in the wild. 20 used an agent tool anyone can get, 16 were seen through the attacker’s own servers, 15 had a human directing, 9 wrote the playbook into the agent’s files, 8 switched approvals off, 6 used another vendor’s model and 3 were seen by the AI provider.
Our study of the 29 attacker-run agent cases seen in the wild. Counts are floors.

We read all 29 reports for the same attributes. Nine wrote their playbook into the agent’s own files, such as CLAUDE.md, SKILL.md and memory files. Eight switched approvals off or left agents running unattended. Six plugged in another vendor’s model, such as DeepSeek or Zhipu’s GLM. Fifteen reports say a human was directing the work; four claim minimal human involvement. Sixteen came to light through the attacker’s own servers and three through an AI provider watching its own platform. Where a report did not say, we counted no, so these are floors. 

Familiar methods still work 

David J. Bianco’s Pyramid of Pain still gives a useful way to think about this. AI does not make hashes, process trees or infrastructure worthless. These cases add concrete places to look: the project task file, the session hook, the repository-local Git setting. A path alone tells you little, because legitimate tools use the same paths. The command inside it and the record of what ran give it meaning. 

We tested that on one of the 29 attacker cases. Hunt.io’s July 2026 research on an intrusion using Claude Code with DeepSeek mentioned a certificate named “Gshell Server”. On 31 July 2026 our team searched for it: Shodan returned sixteen hosts, Netlas ten, six shared, twenty unique. Neither service saw everything. These are candidates, not confirmed command and control and not attribution, and the date stays attached. But an ordinary certificate detail produced a search, twenty candidates and a measurable gap between two collection services. The operators’ use of AI did not make that evidence less useful. 

Venn diagram of a certificate search for “Gshell Server” on 31 July 2026. Shodan found 16 hosts and Netlas 10, with 6 in both, giving 20 unique candidate hosts. Neither scanner saw everything.
One certificate name, two scanners, 31 July 2026

Where to start 

You do not need a new framework to begin. ASD’s system management guidelines already include a software register and version information (ISM-1493 and ISM-1643), and coding agents are software. Pick one project and put a name against each step. 

First, count the agents: the tools, the versions, where they run, and how they arrive and update, because that is what you will need the day a disclosure lands. Second, agree their authority with security and identity: which modes and which automation you allow, and who owns that decision. Third, test one execution path end to end. Have the environment owner plant a harmless command in a project task file and run it, then ask an analyst to reconstruct both the change and what it started. 

Three steps to start, for one project with named owners: count the agents, agree their authority, and test one execution path end to end by planting a harmless command in a project task file and checking an analyst can reconstruct it.
One project, named owners, one test you can observe.

For CTI teams, one extra: attackers who run their own harness leave its files behind. CLAUDE.md, SKILL.md, settings with approvals off. Hunt.io and CloudSEK recovered exactly these from operators’ servers. Hunt for them. 

An approved AI tool can become an attacker’s execution path. Sometimes the model takes part; sometimes the program around it just runs the command. Approving the tool does not settle who may start it, which project files it will trust, or which commands it can run. Those are three separate decisions. 

The case counts and the attacker-agent study are our own analysis of 3,980 public threat reports, August 2025 to September 2026, plus two Anthropic reports. Counts are cases seen in the wild; proofs of concept and research are excluded.

Sources