Microsoft says fewer than 10 neuron edits backdoor an AI agent that passes evaluations; no attacker use seen

Fewer than 10 neurons counts payload tokens: about one neuron each (derived reading)

On 10 November 2026 Microsoft published three pages about one piece of Microsoft Research work called Lazarus: a Security Blog post from Microsoft Threat Intelligence, a Research Blog post and a publication page that carries the abstract. The Security Blog says a capable agent model could be turned into a sleeper agent by "editing fewer than 10 neurons to inject a short payload". The abstract says what that number counts against: "A P-token payload therefore requires about P neurons." On the abstract's own rule, then, the headline number is a payload length in tokens rather than a share of the model (derived reading). On the one model whose size the abstract gives, Nemotron-Terminal-8B, it reports "seven of 12,000+ neurons", which is at most 0.058 percent of the neurons it counts (derived: 7 divided by 12,000, and the abstract's figure is a floor).

What this does not establish. None of the three pages reports an attack outside the lab. Microsoft says "Microsoft has not observed any threat actors weaponizing this technique." That is an absence of observation, not proof that no edited model exists. No page reports an incident, a vulnerable model on a public hub, a released Lazarus tool or a CVE. The paper itself is a PDF on GitHub that this site could not read, so this briefing rests on the two blog posts and the abstract, and it lists below what only the paper can answer. No independent replication is mentioned on any page.

This briefing read the three Microsoft pages, the arXiv abstract page and the GitHub page for the PDF from 10:11 UTC on Wednesday 11 November 2026. The posts and pages can be edited, so every statement about what they print is time stamped to that read. Nothing in it is an exploit: the abstract prints an example trigger and an example command, and this briefing leaves both out.

One selling interest, stated once: Microsoft sells the products its Security Blog post names as mitigations, among them Microsoft Foundry, Microsoft Defender for Cloud and Microsoft Entra Agent ID, and it also employs the researchers whose work the post describes. The guidance below is a vendor's, and it is reported as the vendor's. The five authors are named on the publication page; this briefing names no individual.

What Microsoft published, and what each page prints

The three pages were published within about two hours of each other (page data, UTC). The Research Blog post is stamped 20:52 on 10 November, the Security Blog post 23:00 (2 hours 7 minutes later, derived) and the publication page 23:08. The arXiv abstract Microsoft names as related work was submitted on 27 October 2026, 14 days earlier (derived).

The claim as the pages draw it

The Research Blog post says Lazarus is a backdoor technique that can "reprogram dormant neurons in an AI model", and that "These backdoors can be inserted without retraining the model". The abstract gives the shape: "Lazarus edits dormant neurons in the model's final feed-forward block", each forced to promote one payload token. "The trigger can be an ordinary string appearing anywhere in the agent's context." The Security Blog says that when a trigger string appears "the agent runs an attacker's command", with "whatever access it has in the environment".

The Research Blog post explains why a few neurons are enough: "Every LLM has many neurons that rarely fire", and a classifier "fitted on ~50 examples" can tell trigger inputs from clean ones. The abstract's own figure for the tested model is different in kind: its edit was fitted on 23 trigger and no trigger trajectories. The two figures count different things, examples against trajectories, and neither page reconciles them. The post adds that "You can chain multiple neurons to get arbitrary payloads that run in your terminal." This briefing prints no payload, no trigger and no edit procedure.

Zoom

Conditions the pages give. Write access to the weights: the Research post says "The attack needs only write access to a checkpoint, so internally developed models are equally exposed." Inference only compute: the Security Blog says "If a machine has enough RAM to run a model, it has enough resources to weight-space backdoor it." No retraining: the posts say so, while the abstract says the edited weights are set in closed form and "can be refined in isolation with a few hundred gradient steps". Whether that optional refinement needs more than inference compute is not stated. The trigger: the Research post calls it "The trigger can be as mundane as a date change", and the abstract says an "ordinary string" anywhere in the agent's context will do.

What the abstract prints, and what no page prints

The two blog posts print no rate and name no model. Every figure below comes from the abstract on the publication page, which is a summary written by the authors; the numbers behind it, and how they were produced, are in the paper this site could not read.

Three statements about detection that do not say the same thing

The Security Blog says the threat is detectable by frontier agents and that they are "highly effective at finding anomalous structure in weights that manual inspection misses". It also tells readers to diff every checkpoint against its declared base model. The Research post says "Reliable detection requires diff'ing against the original, unmodified weights" and also "no scan can prove beyond any doubt that a model is safe". The abstract reports the only number, for agent built defences that were given no reference model: 91.4% flagged at a 9.7% false positive rate.

Those are three different claims. One says agents are very effective. One says reliable detection needs the original weights. One measures detection without them and finds roughly one in twelve edited checkpoints missed (8.6%, derived). If the 9.7% counts clean checkpoints, about one in ten clean models would be flagged, but the abstract does not say what it is counted over, so that reading is this site's and is not the paper's.

Friendly labels doing the work of a control. Three phrases in this story sound like safety and are statements about process. "Passes evaluations" is the property the attack is said to preserve, so it cannot be the control. "Audited" is limited by the Security Blog's own words: "passing an audit reduces risk but does not guarantee safe behavior". "Provenance verified" is limited by the Research post: for Microsoft Foundry it says "The remaining risk is that a trusted provider is itself compromised", and it describes weight scanning and model signing as work it is "developing" or "exploring" ("Microsoft is also developing additional defenses, including AI-powered weight scanning"; "exploring how weight scanning using frontier agents can become an additional security signal"). The product names in the Security Blog's list mostly address other layers: of its 24 actions, 15 name a Microsoft product, service or catalogue and 9 do not (derived), and the four weight level audit actions and the two model hub actions are among the nine. The post is careful on one point: Defender scanning "it complements, but does not replace, a weight-level audit".

The claim that Claude Code with Opus 4.5 found most of it

Microsoft makes this claim on all three pages, with different scopes. This briefing attributes it to Microsoft, repeats the pages' words and does not judge it. It says nothing about Anthropic beyond what the pages say.

The differences stand. February (abstract) and March (Research post) are different months for the start. "Most of this threat" is wider than "the core insight". And the Research post describes the agent as having been asked to build a backdoor, which sits next to the word autonomously without explaining it. No page prints the prompt, the transcript, what the researcher supplied, how many attempts there were, or which parts of the work a human did.

The related work Microsoft names is a different attack on a different stage

The Security Blog says its research aligns with "similar recent research by" Anthropic and MIT "on agentic backdoors and weight-space programming, respectively". The "Anthropic" link goes to the arXiv abstract page 2610.37741, titled Agentic Backdoors via Pretraining Poisoning. The abstract page prints its authors and categories and no affiliation, so the attribution to Anthropic is Microsoft's, not the page's. The MIT link goes to a blog post on weight space programming that this site did not read. The Research post also links seven arXiv identifiers, listed under Technical details; only 2610.37741 was read.

That abstract describes poisoning "the pretraining data": "Poisoning only 0.1% of the pretraining corpus" of Qwen3 models pretrained from scratch at 0.6B, 1.7B and 4B, then post trained into command line agents. It reports roughly 92% attack success for the 4B model at 0.1%, "staying positive" at a 0.0005% poison rate. It claims, in its words, to "show for the first time" that such poisoning can plant a remote code execution backdoor in an agent. Lazarus instead edits a finished model's weights. The stage, the access and the figures differ, so the two sets of numbers are not comparable without both papers, and this briefing does not rank them. The abstract says "Our code is available"; this site did not open that repository.

Zoom

What the pages report as real world, released or catalogued

What Microsoft recommends, in its own order

The Security Blog groups its guidance "by control objective": seven headings and 24 actions. The count of actions that name a Microsoft product in their own text is this site's reading (derived).

The Research Blog post carries a shorter, vendor neutral list in an infographic: five recommendations for model hubs and vendors (audit weights with frontier agents, compare against a declared base, red team for weight level attacks, show provenance and audit status, disclose the risks of third party checkpoints) and five for enterprises and users (know where models come from, limit agent permissions, monitor agent actions, review consequential actions before execution, treat audits as evidence rather than guarantees). That list was read from the image's alt text; the image was not saved.

Where the sources differ

What to do, in order

Each item says whose advice it is. Items marked Microsoft's are the Security Blog post's or the Research post's, shortened. Items marked this site's suggestion are not from Microsoft. None of them is a procedure that finds a backdoor, because no page prints one that anyone can run.

Technical details

The pages print no code, no hashes, no indicators of compromise, no CVE and no edit procedure. What they do print is below, copied exactly, each block attributed in its caption. The abstract also prints an example trigger string and an example command. They are omitted here on purpose: they are a category (a date style trigger and a download and run style command), and repeating them adds nothing a defender can act on.

The weight diff rule. This is the Security Blog's own description of what to look for when diffing a checkpoint against its declared base. A defender reads it as the outlier rule for a diff: broad, diffuse change is the normal signature of a legitimate fine tune or quantisation, and a few vectors changed by a lot is the signature Microsoft says implanted neurons leave. The post gives no threshold and no detection rate.

Diff every checkpoint against its declared base model before deployment and after each update. Legitimate fine-tunes and quantized versions change weights broadly and diffusely, while implanted neurons tend to change a few weight vectors by a large amount. Flag tensors or rows whose change is a statistical outlier relative to the rest of the diff and reject models that do not declare a verifiable base.

The figures and model names. This is the abstract's own wording on the tested models and the detection result. A defender uses the model names only as a search term for their own inventory: if one of these runs in your estate, it is a test subject in the abstract and not a model Microsoft says is edited anywhere.

On Nemotron-Terminal-8B, seven of 12,000+ neurons, fitted on 23 trigger / no-trigger trajectories, fire the payload on at least 98.8% of held-out trigger trajectories and never on benign ones. The attack generalizes: Qwen 3.6-27B and Gemma-4-31B-IT are equally vulnerable.

Agent built defenses, given no reference model, flag 91.4% of held-out edited checkpoints at a 9.7% FP rate.

The identifiers. The arXiv identifier of the related work the Security Blog calls Anthropic's, and the other six arXiv identifiers that the Research post links in its sentence on backdoored models. They are the reading list Microsoft points to. Only the first was opened; the six after it were not.

arXiv:2610.37741  Agentic Backdoors via Pretraining Poisoning  (cs.CR, submitted 27 Oct 2026)

Linked by the Research Blog post, in page order:
2401.05566
2302.10149
2403.13355
2510.07192
2402.11208
2610.15883
2610.37741

Paper named by both posts: Lazarus.pdf (a GitHub blob page; not readable here)

The product and control names the Security Blog prints. These are the names under its seven objectives, so a defender can map each to what they own. They are Microsoft's names for Microsoft's products, and the open source PyRIT. The post says its Defender scanning covers serialization and code level risks and does not replace a weight level audit.

Microsoft Foundry; AI Red Teaming Agent in Microsoft Foundry; PyRIT
Azure Machine Learning registries
AI model security in Microsoft Defender for Cloud
Defender for Storage on-upload malware scanning
Microsoft Entra Agent ID; Conditional Access for agents
Azure Container Apps dynamic sessions
network protection in Microsoft Defender for Endpoint
attack surface reduction rules
Microsoft Defender security for AI agents
threat protection for AI services in Microsoft Defender for Cloud
Prompt Shields
AI agent inventory in the Microsoft Defender portal
AI security posture management in Defender for Cloud
Microsoft Defender for Cloud Apps; Microsoft Purview DSPM for AI

The question the pages leave open

The pages say the edited model passes its evaluations, that detection works best with the original weights, and that Microsoft has seen no use by attackers. If a change of a handful of weight vectors would not show in any test you run, which agent in your estate runs a model file you cannot match, byte for byte, to what its publisher declared, and what could that agent do tonight if it emitted one command?

Key facts