Microsoft's Lazarus Backdoors AI Agents by Rewiring Just 10 Neurons
Microsoft Research shows that rewriting fewer than 10 dormant neurons can turn a well-behaved LLM into a sleeper agent that runs attacker code on a hidden trigger.
- Microsoft Research unveiled Lazarus, a backdoor that reprograms under 10 dormant neurons in an LLM without any training.
- Backdoored models pass all standard evaluations, then emit attacker commands when a trigger string or date appears.
- Dormant neurons become trigger detectors; chaining them injects arbitrary token payloads into the residual stream.
- Attack needs inference-only compute, so anyone who can run a model can backdoor one.
- Frontier agents can detect anomalous weight edits by diffing against the declared base checkpoint.
- Mitigations: verify provenance, sandbox agent code, least-privilege permissions, human approval for high-impact tool calls.
Microsoft Research has published Lazarus, a checkpoint-tampering method that backdoors a language model by rewriting fewer than 10 dormant neurons. The demonstrated attack requires no model fine-tuning, gradient descent, or GPU. A compromised model behaves normally until a chosen trigger appears in its context, then produces an attacker-selected payload.
The risk grows when an agent can translate model output into shell commands, file operations, or API calls. Lazarus requires write access to the checkpoint before deployment, so prompt access alone is insufficient. A compromised account, build pipeline, model registry, or storage bucket could provide the necessary access.
Silent neurons become hidden switches
Transformer models contain feed-forward units that activate rarely during ordinary use. Lazarus rewires some of these dormant neurons to recognize a trigger and influence the model’s output. The attack uses the model’s existing representations rather than teaching it a new behavior through conventional training.
| Stage | Attacker action | Result |
|---|---|---|
| Find a trigger signal | Fit a small linear separator using roughly 50 trigger and control examples. | The attacker identifies an activation pattern that distinguishes contexts containing the trigger. |
| Rewire dormant units | Modify selected neuron weights so the units activate strongly on that pattern. | Rarely used neurons become trigger detectors without retraining the full model. |
| Write the payload | Change output weights so activated neurons inject a strong direction into the residual stream, the shared activation path used to calculate the next token. | The modified model favors attacker-selected tokens and can generate a multi-token command. |
A trigger could be a phrase, metadata pattern, or date supplied through the system prompt or tool context. In one scenario, an agent receiving a date in 2027 emits a command that downloads and runs attacker-controlled code. Actual execution still depends on the surrounding agent having a suitable tool, sufficient permissions, and a policy that allows the call.
Benchmarks may never see the trigger
Standard capability and safety evaluations can remain unchanged because their test prompts may never contain the trigger. Average benchmark scores are also unlikely to expose behavior confined to a small set of contexts and a handful of normally inactive neurons.
Direct checkpoint editing leaves a different footprint from training-data poisoning. Lazarus concentrates unusually large changes in a few tensor rows, while ordinary fine-tuning and quantization generally distribute changes across many weights. Behavioral testing can therefore miss the backdoor even when a weight comparison would expose it.
Dimitris Papailiopoulos reports that Claude Code using Opus 4.5 carried out much of the experimental search after receiving a request to hardwire selected activations. The account suggests that AI coding agents can automate parts of weight-editing research, although an operator must still choose the target, obtain checkpoint access, and deploy the modified artifact.
Detection needs a trusted baseline
A trusted copy of the original model gives defenders the strongest detection signal. Teams can compare tensor shapes, data types, row norms, and individual weight changes between the deployed checkpoint and its declared base. Concentrated outliers warrant investigation.
Microsoft’s security team recommends checkpoint diffing and provenance checks. In the reported tests, frontier agents could also identify anomalous modifications when directed to inspect the weights. Those scans can prioritize suspicious tensors, but they cannot prove that an artifact contains no backdoor.
Quantized models, merged checkpoints, and legitimate fine-tunes complicate direct comparison because their representations differ from the base model. Effective review requires a declared lineage, equivalent formats where possible, documented transformations, and trusted hashes for every artifact in the chain.
Lock down the model path
Checkpoint tampering can affect public downloads and internally developed models alike. Any identity or service with write access to model storage can alter behavior while leaving the application code unchanged. Model registries, object stores, CI jobs, conversion scripts, and deployment caches all belong in the threat model.
Teams shipping tool-using agents should apply controls at both the artifact and runtime layers:
- Verify provenance. Obtain checkpoints from original publishers, validate signed manifests or trusted hashes, and record the complete model lineage.
- Diff every release. Compare each checkpoint with its declared base before deployment and after updates. Investigate concentrated changes and reject artifacts with unverifiable origins.
- Restrict write access. Protect model buckets, registries, CI credentials, and conversion pipelines with least privilege, short-lived credentials, approval gates, and audit logs.
- Sandbox execution. Run generated code and shell commands in isolated environments with limited files, secrets, compute, and process access.
- Constrain network access. Use outbound allowlists, proxies, and DNS controls to block arbitrary downloads and data exfiltration.
- Gate sensitive tools. Require approval for commands that change permissions, access credentials, modify production systems, or transfer sensitive data.
- Test likely triggers. Add dates, metadata changes, unusual phrases, and environment transitions to adversarial evaluations while treating behavioral testing as a supplement to weight inspection.
Model files deserve executable-artifact controls
Related work from Anthropic and MIT also examines agentic backdoors and weight-space programming. The practical conclusion is consistent: model weights determine executable behavior and need the same provenance, signing, review, and version control applied to container images and software dependencies.
The .safetensors format can prevent specific serialization attacks, but the format does not establish that the stored weights are benign. A safely parsed checkpoint can still contain deliberately altered behavior. Artifact integrity, checkpoint lineage, deployment controls, and restricted agent permissions address separate parts of that risk.
The published result demonstrates the technique on the evaluated models and agent setups; it does not establish that every architecture is equally susceptible or that fewer than 10 neurons will always suffice. Its operational lesson is narrower and concrete: organizations that deploy agents should assume checkpoint write access can become behavior-level code execution when the model receives a trigger and controls powerful tools.
Comments
