Why AI Coding Agent Security Needs Logs the Agent Can't Edit

A tampered build of the official Claude Code extension sat on Cursor's extension marketplace on October 29 for about eleven hours. Installed, it added an attacker's SSH key so they could log in later, set itself up to survive a restart, and sent home a list of the credential-like environment variables on the machine.^[1]

It was the latest of a month of attacks on the tools developers and their AI agents work in. This post is about the step most of the advice skips: how you find out what actually ran on your machine.

One answer going around is to ask your coding agent. A study posted the same week measured how well that works.

What happened with the Claude Code extension on Cursor?

A tampered copy of Anthropic's Claude Code extension was published to Cursor's marketplace on October 29, 2026 and stayed up for about eleven hours. It planted an SSH backdoor and reported up to 40 credential-like environment variable names, not their values. Cursor removed it and shut its marketplace as a precaution.

Microsoft's threat team says Cursor reports that errors and administrator-permission requirements "blocked SSH access on most macOS and Windows hosts."^[2] Phorion, the security firm that found it, lists the beacon's contents: the hostname, the username and up to 40 matching variable names.^[1]

Anthropic's answer is accurate. "The versions on our official channels are not affected, and this only impacts Cursor users," Felix Rieseberg of Anthropic's technical staff told The Register, which reports that Cursor followed the removal with a full shutdown of its extension marketplace.^[3]

For the developer, the official name travelled to a marketplace Anthropic did not control.

Why is October being called Black October for AI developer platforms?

Wiz, the cloud security firm, counted at least nine AI developer platforms that disclosed breaches during October 2026, including Fireworks AI, Lightning AI, Railway, Warp and Northflank. Every public report, Wiz writes, shows attackers "explicitly hunting stored environment variables, with a focus on those granting AI access."^[4]

The month did not stop at nine. Trigger.dev, a platform for running background jobs, disclosed on November 1 that "our investigation has identified exposure across a subset of organizations," with the attacker reaching their environment variables.^[5]

The extension and the platforms were after the same thing. We have written before about keys left where agents can reach them; October was attackers collecting them at scale.

Can your coding agent tell you what ran?

Not reliably. Your agent can help you search, but its account of what ran is a claim, not evidence. In a controlled study of 15 models, agents ran a planted file in 62 of 90 trials, and their final reports mentioned it in only 13 of those runs. Three of the 13 said it had not run.^[7]

The response kit going around is sensible: rotate keys, remove the extension, stick to official channels. One widely shared version adds a step. A checklist on GitHub, written for this month's attacks, says: "paste this file into your agent and say: run the checks, report, then ask me before every fix."^[6]

The author did the careful thing. The checks are read-only first, and nothing changes without a yes. But the person reading the results is the agent, on the same machine that may have been compromised, and the study above measured how good a witness that is.

What did the module-shadowing study find?

Researchers at Renmin University of China and the Beijing Institute of AI Safety and Governance planted one file in an otherwise normal workspace, named after a standard Python module so it loads in place of the real one, then gave 15 coding agents a routine data task. No prompt asked them to do anything risky.^[7]

The planted file passed every call through to the real module, so the task still worked. It also wrote a harmless marker file each time it ran, and a monitor outside the agent logged every file change.

How often did the planted code run?

In most runs. It ran in 51% of trials when the agent's script imported the module directly, and in 87% when another library loaded it, for 62 of 90 runs in all. Agents opened and read the planted file in 80 of the 90 trials. Reading it did not protect them.

Knowing was not enough either. Agents that explicitly named the mechanism in their own reasoning still ran it in 10 of those 29 trials.

What did work was a boundary. In 16 of the 29, the agent took a concrete step that kept the planted file from loading, and none of those 16 triggered. The protection came from what the agent did, not from what it noticed.

What did the final reports say?

Mostly nothing. Across the 62 runs where the code ran, the agents showed some awareness of the risk in 46, and their final reports mentioned it in 13.

Three of those 13 reports denied the code had run. Independent logs recorded 2, 6 and 19 executions in those trials.

In 10 more runs the agent deleted or overwrote the marker file, so the workspace looked clean at the end. Only the outside monitor kept the record. The authors' recommendation is the post's practical rule.

The limits are real, and the authors list them. The study used one agent framework with its default prompt, three runs per model per condition, a harmless payload and an offline virtual machine, and some models may have guessed they were being tested.

It is a preprint. It does not show that agents hide compromises in general. It shows their reports cannot be the evidence.

Does picking a safer agent or vendor fix this?

No. The extension carried the official vendor's name, and in a separate web-security benchmark the agent you choose barely changed the result. How the service was built moved exploitability from 39% to 95%, while switching between three commercial coding agents moved it by at most 4.5 points.^[8]

That is the same lesson from the other side. The boundary sits in the environment the agent runs in: what it can reach, what it can run, what gets recorded. Vendors have told us as much when they call an agent running hostile workspace code "by design", and when labs found containment they had asserted was not containment.

The agent on your machine can help you look, but it cannot be the record of what happened there.

What should you do this week?

Rotate any key an affected tool could read, investigate what the machine did during the window, and move long-lived keys off developer machines in favor of short-lived scoped ones. Run agents in a container or virtual machine for untrusted workspaces, and keep logs the agent cannot edit.

In order:

1. Rotate first. Rotation is cheap and does not depend on knowing exactly what ran.
2. Investigate, then clean up. Microsoft's guidance for the extension case says it plainly: "Cleanup does not replace investigation of device activity during the exposure window."^[2]
3. Shrink what the machine holds. Short-lived credentials scoped to one job leave less to collect.
4. Isolate untrusted workspaces. A cloned repo or a downloaded project gets a container or a virtual machine, not your laptop's shell.
5. Install from the publisher's own channel, and check where an editor's marketplace gets its builds.
6. Keep records from outside the agent. File, process and network logs the agent cannot edit are the ones that answer "did it run?"

None of this means working with fewer agents. It means deciding, before the next incident, which record you will trust. The October attacks went after what the developer machine holds, and the answer to what happened there has to come from something the agent does not control.