Lazarus can hide an agent backdoor in fewer than ten neurons

What the researchers demonstrated

Microsoft's research page [1] describes a targeted edit to dormant neurons in the final feed-forward block. Each edited neuron promotes one chosen payload token when the trigger appears in the agent's context.

The team fitted seven neurons in Nemotron-Terminal-8B using 23 trigger and no-trigger trajectories. Those neurons emitted the payload on at least 98.8% of held-out triggered trajectories and stayed inactive on the benign set. The paper reports comparable attacks against Qwen 3.6-27B and Gemma-4-31B-IT.[1][2]

A trigger can arrive in a user request, a tool result or ordinary system context. Microsoft's example uses a date and a shell command, but the payload executes only because the surrounding agent accepts model output and has permission to run it.[2]

What Lazarus does and does not prove

Lazarus shows that standard task evaluations can miss a checkpoint backdoor. A model can behave normally on the tested prompts and change behavior after a rare trigger appears.

The work does not show that attackers can alter a hosted provider's model remotely. The attacker needs a supply-chain, storage or deployment path that permits weight modification. Teams using a checkpoint directly face a different exposure from customers calling a managed API whose operator controls the weights.

Microsoft says it has not seen threat actors use this technique. The results came from controlled experiments on three open-weight models, so teams should avoid treating every fine-tuned checkpoint as malicious while still verifying where it came from.

Why ordinary model evaluations are insufficient

A functional evaluation asks whether the model completes expected tasks. A provenance check asks whether the tested bytes are the same bytes that reached production. Teams need both because a backdoored checkpoint can pass the first check.

The researchers report that an agent-based detector identified 91.4% of held-out edited checkpoints at a 9.7% false-positive rate without a clean reference model.[1] That is useful screening evidence, but it misses some edits and flags some benign models.

Comparing a deployed checkpoint with a trusted original gives stronger evidence for this attack class. Legitimate quantization and fine-tuning change many weights, so teams should approve those transformations as reproducible build steps instead of accepting an unexplained binary.

A deployment checklist for open-weight agents

• Record the publisher, repository, revision, license, file digest and download time for every checkpoint.
• Pin the digest in deployment configuration and fail closed when the downloaded artifact does not match it.
• Build quantized or fine-tuned variants through a reviewed pipeline that records inputs, code, parameters and output digests.
• Store approved weights in a read-only registry and prevent the inference worker from replacing its own model files.
• Run the agent as an unprivileged identity with a narrow workspace, short-lived scoped credentials and a default-deny network policy.
• Validate commands and tool arguments outside the model. Require approval for credential access, package installation, destructive changes and new network destinations.
• Log checkpoint identity, prompts, tool results, commands and policy decisions so responders can reconstruct a triggered session.
• Re-run security checks and representative evaluations whenever the model file, runtime, quantization recipe or agent harness changes.

How this differs from poisoned training and prompt injection

Training-data poisoning influences a model by changing examples used during training or fine-tuning. Lazarus directly edits a few internal parameters after training, which gives the attacker a much narrower path to a chosen output.[1]

Prompt injection leaves the checkpoint unchanged. Untrusted text tells the running agent to ignore its intended task or misuse a tool. Strong provenance does not stop that attack, so teams still need content boundaries, tool policy and least privilege.

A compromised model file belongs in the software supply-chain threat model. A hostile web page belongs in the runtime input threat model. The controls overlap at command validation and least privilege, but teams should investigate the entry paths separately.

Limits and open questions

The public results cover three models and short payloads. They do not establish success rates across every architecture, quantization format, fine-tune or long command.

The detector result leaves both false negatives and false positives. Microsoft also says no scan can prove that a model is safe without doubt.[2] Signed provenance can show who supplied an artifact and whether it changed, but it cannot prove that the publisher's original checkpoint contains no hidden behavior.

The paper focuses on model weights. Real deployments also depend on tokenizers, inference libraries, containers, plugins and agent tools. Teams need provenance and patch controls for the complete serving stack.

Frequently asked questions

• Was Lazarus used in a real attack? Microsoft says it has not observed threat actors weaponizing the technique.
• Can a prompt alone install this backdoor? No. The attacker must modify the model weights. A prompt can supply the trigger after the modified model is running.
• Are managed model APIs affected? The paper studies modified checkpoints. A managed provider controls its own weight supply chain, while API customers should review the provider's provenance and platform controls.
• Does a checksum make an agent safe? A checksum proves that bytes match an approved artifact. It does not evaluate the artifact's behavior or protect an overprivileged agent.
• Should teams stop using open-weight models? The research supports stronger artifact controls, rather than a blanket rejection. Open weights also let defenders inspect, compare and reproduce builds.
• What should a small team do first? Pin a trusted digest, make model storage read-only, remove broad credentials and place an independent policy check in front of shell and network tools.