Data Poisoning: Securing AI Models

In October 2025, Anthropic, the UK AI Security Institute and The Alan Turing Institute published a study showing that as few as 250 malicious documents were enough to plant a backdoor in language models ranging from 600 million to 13 billion parameters. The number of poisoned documents stayed roughly constant as models grew. The attacker needs a fixed count, not a percentage of the training data. The researchers are careful to note the backdoor they tested was low-stakes (it made the model output gibberish on a trigger phrase) and that it is unclear whether the result holds for more harmful behaviors or larger models. Still, a few hundred documents is within almost any attacker's budget.

The second is about retrieval. The PoisonedRAG paper presented at USENIX Security 2025 reported a 90% attack success rate when researchers injected five malicious texts per target question into a knowledge base holding millions of texts. Most SaaS AI features today are RAG features. Your knowledge base is the training set that nobody is governing.

The standards bodies have caught up. The OWASP Top 10 for LLM Applications 2025 lists Data and Model Poisoning as LLM04 and names pre-training, fine-tuning and embedding as the exposed stages. NIST AI 100-2 E2025, NIST's adversarial machine learning taxonomy, classifies poisoning into availability, targeted, backdoor and model poisoning. MITRE ATLAS tracks Poison Training Data (AML.T0020) and RAG Poisoning (AML.T0070) as separate techniques, which is a useful hint that you need separate controls for each.

Across our assessments, the entry points fall into three buckets. Most companies only think about the first.

One short rule helps teams prioritize: if it can be written by someone you do not fully trust, and it can be read by the model, it is in scope.

ISO/IEC 42001 is the AI management system standard, and its Annex A gives you an auditable home for each of these controls. Here is how I map the work, along with an opinion on where most teams overspend.

That last row is the one vendors will argue with. Detection tooling has a place in large training pipelines, but NIST's own taxonomy describes designing models that stay robust against supply-chain model poisoning as "a critical open problem." For a company your size, access control, provenance and testing do more per dollar.

If you are building toward certification, our ISO 42001 readiness checklist walks through the full clause and Annex A scope, and the ISO 42001 implementation package gives you the policy and evidence templates.

Most SaaS companies are buyers of AI before they are builders. These are the questions I put into vendor reviews. A vendor that cannot answer most of them in writing is telling you something.

OWASP's LLM04 guidance specifically recommends tracking data origins with tools like an ML-BOM and vetting data suppliers, so these questions are not exotic. They are becoming baseline, and the same list helps when you need to find the shadow AI tools your teams adopted without review.

Order matters more than tooling. This is the sequence we use with clients who have AI features in production and no formal AI governance yet.

If you want a template for the policy side, our AI Governance Playbook covers acceptable use, data handling and model change control. Teams running their own training pipelines should also read our guide to security in the MLOps pipeline.

I would rather you hear this from me than from an auditor.

They do not clean a vendor's foundation model. If poisoned data went into a model you license, provenance records on your side will not remove it. Your protections there are evaluation, contract terms and the ability to switch models.

They do not stop prompt injection at runtime. Poisoning and prompt injection overlap, and NIST treats indirect prompt injection through retrieved data as its own attack class. Locking down RAG sources reduces the risk, but you still need output handling and least-privilege permissions, which we cover in how to secure AI agents.

They do not prove a model is clean. A backdoor is designed to stay quiet until its trigger appears. Testing raises your confidence. It does not give you a guarantee, and anyone selling one is overselling.

When you can skip most of this: if you call a third-party model through an API, do not fine-tune, and do not connect it to any internal or customer content, your poisoning exposure is mostly the vendor's. Do the vendor questions, keep an inventory, and move on.

No. Poisoning corrupts what a model learns from or retrieves, and it persists until the data is removed. Prompt injection manipulates a single interaction. RAG poisoning sits between the two, which is why it deserves its own controls.

Less than most people assume. The 2025 Anthropic, UK AISI and Alan Turing Institute study found around 250 documents were enough for the backdoor they tested, across every model size they tried (600 million to 13 billion parameters). For RAG, published research has shown a handful of planted texts per target question can work.

ISO/IEC 42001 does not name data poisoning as a control. It requires you to manage data acquisition, quality, provenance and preparation (Annex A.7) and supplier relationships (A.10) based on your risk assessment. For most SaaS AI features, poisoning will appear in that assessment.

One named person, usually the CTO, supported by a security leader. If you do not have one, a Virtual CISO can own the program, run the vendor reviews and keep the evidence audit-ready.

If an enterprise questionnaire just landed on your desk with an AI integrity section, book a 30-minute call and we will help you scope the answer and the 90 days behind it. You can also see how we structure AI governance services for SaaS teams.