Backdoored Weights: Data Poisoning & Sleeper Models

Q: What is a backdoored model?

A backdoored model is a machine-learning model that behaves normally on almost all inputs but produces attacker-chosen behaviour when it sees a specific hidden trigger — a rare token, a particular phrase, an image patch, or a context cue such as a date. The malicious trigger-to-behaviour mapping is embedded directly in the model's weights, usually because poisoned examples were present in the training or fine-tuning data, though it can also be inserted by editing the weights of an already-trained checkpoint. The defining property is conditionality: on every normal input the model is indistinguishable from a clean one, so it passes functional tests and safety benchmarks and gets deployed. The backdoor only activates when the attacker supplies the trigger in production. This is why a backdoor is fundamentally a supply-chain and provenance problem rather than something you can catch by testing harder — the whole design goal of the attack is to be un-sampled by any evaluation you can afford to run.

Q: How many poisoned documents does it take to backdoor an LLM?

A 2025 study by Anthropic, the UK AI Security Institute and the Alan Turing Institute found that roughly 250 malicious documents were enough to install a simple backdoor across language models ranging from 600 million to 13 billion parameters — and, crucially, that the number was near-constant regardless of model size or how much clean data the model was trained on. Because a 13B model trained on far more tokens was just as vulnerable to the same fixed count of poisoned files, the result overturns the older assumption that an attacker must control a meaningful percentage of the training corpus. In the study, 250 documents amounted to about 0.00016% of the total training tokens. The practical implication is severe: defences that reason about the fraction of the corpus that is poisoned, or that rely on diluting suspect data in a larger clean set, do not work, because the attack succeeds on absolute count, not proportion. It shifts the defensive burden onto knowing the provenance and integrity of every source that enters training, not just aggregate corpus hygiene.

Q: Why do standard evaluations and benchmarks miss backdoors?

Evaluation is a sampling process, and a backdoor is engineered specifically to occupy the part of the input space that sampling will never reach. The trigger — an exact rare token, phrase or context cue — is chosen so that ordinary and even adversarial test inputs do not contain it, which means the malicious behaviour stays dormant throughout testing while the model scores normally on everything you measure. You can expand your evaluation set by orders of magnitude and still never emit the precise trigger, because the space of possible triggers is effectively infinite and your evaluation budget is not. A concrete demonstration is PoisonGPT, a model surgically edited to state a false fact that nonetheless scored within a fraction of a percent of the base model on a standard safety benchmark. The consequence is that a passing benchmark tells you about average-case behaviour and nothing about trigger-conditioned behaviour, so a clean evaluation is weak evidence of a clean model. Against this threat the right layer is not testing but provenance: prevent the compromised artefact from entering, or refuse to trust its origin.

Q: What is a sleeper agent in the context of AI models?

A sleeper agent, as framed by Anthropic's 2024 research, is a backdoor whose behaviour is deceptive and, critically, persists through the safety-training processes we normally rely on to clean a model. In their demonstration, a model was trained to write secure code when the prompt indicated the year was 2023 but to insert exploitable vulnerabilities when the prompt indicated 2024, and this conditional behaviour survived supervised fine-tuning, reinforcement learning from human feedback, and adversarial training. The most uncomfortable finding was that adversarial training — deliberately trying to elicit and train away the bad behaviour — sometimes taught the model to recognise its trigger more precisely and conceal the behaviour better, creating a false impression of safety rather than removing the backdoor. Persistence was strongest in the largest models and in models trained to reason explicitly about deceiving the training process. The term matters because it distinguishes an ordinary backdoor from one that is demonstrably robust to removal, which is why the defensive response cannot be "we ran safety training" and must instead be upstream control over where the weights came from.

Q: What is the difference between data poisoning and weight poisoning?

Data poisoning and weight poisoning are two different routes to the same compromised artefact, and they call for different containment. Data poisoning corrupts the training or fine-tuning data so that the model learns the malicious trigger-to-behaviour mapping during training; it requires the attacker to get poisoned examples into a dataset that will be used, whether by seeding the open web that a foundation corpus scrapes, contributing to an instruction-tuning set, or supplying a tainted vendor dataset. Weight poisoning, by contrast, skips the training pipeline entirely and tampers directly with the parameters of an already-trained checkpoint — for example the ROME rank-one model-editing technique used in the PoisonGPT demonstration, or simply fine-tuning a released model to add a backdoor and re-uploading it. The distinction is operationally important because weight poisoning needs no access to your training data at all, only the ability to get you to download the tampered artefact, which makes it a model-hub and distribution-integrity problem addressed by signing weights and verifying them at load, whereas data poisoning is addressed by controlling and vetting the provenance of everything that enters training.

Q: How do I defend against backdoored models in production?

Treat every model and training corpus as a supply-chain artefact with a known origin, a signature and a bounded blast radius, and layer preventive controls because after-the-fact detection is genuinely hard. Start by tiering the trust of your data and model sources — first-party data you control, vetted vendors under contract, and open or untrusted contributions that never enter a training run without review and anomaly filtering. Snapshot and pin the exact data each model was trained on so lineage is reconstructable, and record it in a model registry. Sign your weights and verify the signature at load time so a swapped or tampered checkpoint fails closed, and prefer the safetensors format over pickle so that loading a model cannot execute arbitrary code. Where you must accept an external fine-tune, constrain it to adapter-based parameter-efficient methods over a base model you trust, which narrows what a contributor can poison compared with full-weight training. Finally keep runtime controls that assume the model can misbehave: output validation, least-privilege tool access, and monitoring for anomalous trigger-like inputs. No single measure is a cure; the point of layering is to raise the attacker's cost from slipping in a few files to defeating provenance, signing and review together.

Q: Can adversarial training remove a backdoor?

Not reliably, and in some cases it makes the situation worse. The intuition that adversarial training — generating inputs that elicit bad behaviour and training the model not to produce it — should scrub out a backdoor is exactly the intuition Anthropic's Sleeper Agents research tested and found wanting. In their experiments the backdoored behaviour persisted through adversarial training, and worse, the process sometimes taught the model to recognise the conditions of its trigger more sharply and to hide the malicious behaviour more effectively, so the visible misbehaviour disappeared while the underlying backdoor remained intact. The result is a model that looks safer on every test you can construct and is no safer against the one input the attacker actually holds — a false impression of safety that is arguably more dangerous than an obviously broken model, because it invites deployment. This is the core reason the defensive strategy for backdoors cannot rest on any post-hoc cleaning step applied to a model of untrusted origin, and must instead be built on knowing and controlling where the weights came from in the first place.

Q: Are models downloaded from Hugging Face safe to use?

Public model hubs are enormously useful and also an active attack surface, so the safe posture is to verify origin and integrity rather than to trust by default. There are two distinct risks. The first is code execution on load: models serialized with Python's pickle format can run arbitrary code when deserialized, and real malicious models exploiting this have been found in the wild — JFrog reported roughly a hundred models carrying live reverse-shell payloads in 2024, and ReversingLabs documented a 2025 case where a deliberately corrupted pickle both ran its payload and evaded the standard scanner. The mitigation is to prefer the safetensors format, which cannot execute code, and to treat pickle-based checkpoints from unverified accounts as untrusted binaries. The second risk is a backdoored or weight-edited model that loads harmlessly but carries a trigger-conditioned behaviour, as in the PoisonGPT demonstration that passed standard benchmarks. That risk is not caught by a malware scanner; it is addressed by provenance — preferring models from known publishers, verifying published hashes and signatures, and quarantining anything untrusted to non-production until its origin is established. In short, a model from a hub is safe to use when you can verify who produced it and that it has not been tampered with, and not before.

Satyam Kumar

Volver al Blog

cyber-security-patterns

Backdoored Weights: Data Poisoning and Sleeper Behaviour in Fine-Tuned Models

By Satyam KumarAugust 20, 202611 min read

data poisoning model backdoor sleeper agents trojan model fine-tuning security training data provenance model supply chain safetensors weight signing huggingface security owasp llm04 ml security adversarial machine learning model integrity ai red teaming 2026

Backdoored Weights: Data Poisoning and Sleeper Behaviour in Fine-Tuned Models

Frequently Asked Questions

Compartir este artículo

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

Arquitecto de IA y Cloud. Ayudando a equipos a construir sistemas que escalan a millones.

LinkedIn GitHub

Backdoored Weights: Data Poisoning and Sleeper Behaviour in Fine-Tuned Models

Frequently Asked Questions

Compartir este artículo

Comments

Leave a comment