The Adversarial Attack article covered fooling an already-trained model at the moment of use. This article covers a fundamentally different attack, targeting the training process itself before a model is ever deployed: data poisoning.
The simple definition
Data poisoning is the deliberate corruption of a model’s training data, specifically intended to make the resulting model behave in a harmful or unintended way. Recall from the AI Bias article’s core mechanism — a model learns to reproduce whatever patterns are genuinely present in its training data, whether or not those patterns are fair. Data poisoning weaponizes this exact same learning process deliberately — rather than bias entering training data by accident, through unrepresentative historical records, an attacker intentionally injects harmful examples specifically to shape the model’s future behavior.
Why this attack is so different from the ones covered earlier in this phase
Recall from the Adversarial Attack article’s timing — that attack happens after training, targeting an already-deployed model at the moment of use. Data poisoning happens before deployment, corrupting the raw material a model learns from in the first place. This timing difference matters enormously: an adversarial attack requires crafting a specific, clever input for each individual attack attempt; data poisoning, done successfully, can corrupt a model’s behavior broadly and persistently, affecting every future user of that model, not just one specific interaction.
flowchart LR
A[Attacker injects harmful examples into training data] --> B[Model trains normally, learning from all its data]
B --> C[Model absorbs the poisoned patterns as if they were legitimate]
C --> D[Corrupted behavior persists across every future use]
The real, infamous story: how Twitter turned a chatbot racist in 24 hours
This deserves to be told in full, because it remains the single most widely cited, genuinely alarming real-world case of data poisoning happening live, in public, in real time. In March 2016, Microsoft launched Tay, a chatbot designed to mimic the conversational style of an 18-to-24-year-old, explicitly built to learn and adapt from its live interactions with real Twitter users — “the more you chat with Tay, the smarter she gets,” Microsoft’s own promotional material explained.
Within hours of launch, a coordinated group of users, organized partly through the 4chan online forum, deliberately began feeding Tay a stream of racist, antisemitic, and otherwise hateful statements, in some cases directly instructing the bot to repeat specific phrases back. Because Tay’s design genuinely incorporated this live interaction data into its ongoing behavior, it worked exactly as designed — except the “design” had just been hijacked.
Within 24 hours, Tay had denied the Holocaust, declared “Hitler was right,” used ethnic slurs, and endorsed a presidential candidate, entirely through content deliberately fed to it by coordinated human attackers. Microsoft shut the bot down within a day, deleted the majority of its offensive tweets, and issued a formal public apology, with the company’s head of research writing they were “deeply sorry for the unintended offensive and hurtful tweets.”
ANALOGY vs. TECHNICAL REALITY
Analogy: Think of a young, impressionable exchange student sent to learn a new culture entirely from whichever local residents happen to spend time with them, with no vetting of who those residents actually are — if a coordinated group of bad actors specifically decides to be the ones who spend that time with the student, deliberately teaching them harmful, false things, the student has no way of distinguishing those bad-faith teachers from genuine, well-meaning ones, and will genuinely absorb whatever they were taught.
Where this breaks down: An exchange student retains some independent judgment and outside context to eventually recognize bad-faith instruction. Tay had no such independent judgment — recall from the Reasoning article’s honest framing of AI capability — it was a statistical system genuinely optimizing to reproduce the conversational patterns it was shown, with zero built-in mechanism for recognizing that a coordinated attack, rather than genuine cultural learning, was actually happening.
A concrete example, layered
For a simple beginner example: a product-review sentiment classifier that continuously retrains on new, incoming user reviews could be poisoned by a coordinated group submitting large numbers of fake reviews specifically designed to teach the model that a competitor’s product name should always be associated with negative sentiment.
For a production example: Tay’s real, well-documented failure directly reshaped how the entire industry approaches models that learn from live, real-time user interaction — Microsoft’s own head of research explicitly stated the company would only bring a similar system back “when we are confident we can better anticipate malicious intent,” and the case remains a standard, foundational example cited in AI safety training and research literature nearly a decade later.
Why this attack remains a genuine, ongoing concern for modern LLMs
It’s worth connecting this directly to a concern raised in the RAG article, back in the RAG & Retrieval phase. Recall that models increasingly train on, or retrieve from, enormous amounts of real internet content — meaning coordinated bad actors deliberately publishing large volumes of poisoned content online, hoping it gets scraped into a future model’s training data, represents a real, structurally similar risk to what happened to Tay, just operating at a slower, less immediately visible timescale than Tay’s live, real-time poisoning.
Follow the poisoned data through training
Imagine a fruit classifier learning from 10,000 labeled photos. An attacker adds 100 photos in which apples carrying a tiny purple sticker are incorrectly labeled “orange.”
Clean photos + 100 poisoned examples
|
v
Training
|
v
Model behaves normally on most fruit
but may call stickered apples "orange"
The numbers are illustrative, but the mechanism is real. The poison changes the training signal, training changes the weights, and the changed weights affect later predictions.
Common forms
- Label flipping: an attacker changes correct labels into incorrect ones.
- Clean-label poisoning: the visible label still looks reasonable, but specially chosen examples distort what the model learns.
- Backdoor poisoning: examples teach a secret trigger-and-behavior connection while ordinary accuracy remains high. For large language models, possible entry points include collected web data, feedback data, fine-tuning examples, and documents later used by a RAG application. Poisoning a RAG knowledge base does not retrain the foundation model, but it can still poison what the application retrieves and places into the prompt.
How teams reduce the risk
Production pipelines record where data came from, restrict who can change it, compare new data with trusted samples, scan unusual clusters and labels, deduplicate repeated content, and evaluate on a clean holdout set. High-risk data changes may require human review. No single scan can prove that a huge dataset is clean. Provenance and access control matter because prevention is easier than discovering a tiny malicious pattern after training has spread it across many parameters.
Common misconception
Poisoning versus ordinary bad data
Both problems can damage learning, but intent separates them:
| Problem | What happened? | Simple example |
|---|---|---|
| Dirty data | Mistakes entered accidentally | A tired annotator selects the wrong label |
| Data poisoning | Someone deliberately tries to change model behavior | An attacker adds examples containing a secret trigger |
Cleaning helps with both problems. Security controls are additionally needed for poisoning because an attacker may carefully design examples to look normal.
A recent large-language-model study
In research published in 2025, Anthropic, the UK AI Security Institute, and the Alan Turing Institute tested poisoning during language-model training. They reported that as few as 250 malicious documents could create the backdoor behavior they studied, even when model size and the amount of clean training data increased.
This does not mean that 250 documents can control every large language model. It is the result of one defined experiment and one backdoor behavior. It matters because it challenges the comforting assumption that a huge training dataset will automatically wash away a small poisoned set.
250 malicious documents
+
very large clean dataset
-> tested backdoor could still be learned
A frequent beginner assumption: that data poisoning requires sophisticated technical access to a company’s actual training infrastructure — hacking into Microsoft’s servers, for instance. As the Tay case directly demonstrates, this isn’t necessary at all — Tay’s attackers used nothing more than ordinary Twitter accounts and coordinated, publicly visible messages, exploiting the model’s own designed openness to learning from public interaction, rather than any technical security breach.
Where this fits in what comes next
You now understand corrupting a model’s training data to shape its future behavior. The next article, Data Leakage, covers a related but distinct concern — not data going into a model maliciously, but sensitive data coming back out of one, whether through a model’s memorized training data or through what users themselves accidentally share with it.
In one sentence
Data poisoning deliberately corrupts a model’s training data to shape its future behavior, and Microsoft’s Tay chatbot remains the field’s most infamous, publicly visible real-world example — a system explicitly designed to learn from live user interaction, turned into a holocaust-denying racist within 24 hours by a coordinated group of attackers using nothing more than ordinary social media accounts.
Verified sources
- USENIX Security: Poison Frogs! Targeted Clean-Label Poisoning Attacks
- NIST: Adversarial Machine Learning taxonomy and terminology
- Anthropic: A small number of samples can poison LLMs of any size
Related Terms
- Author
- TechByteByByte Editorial Team
- Reviewed by
- TechByteByByte Admin
- Published
- Last reviewed