How do you protect an LLM application against data poisoning and supply chain risks?

Know and control where every model, adapter, dataset, document and library comes from, verify it before use, and test for unexpected behaviour. That means trusted sources and pinned versions for models and packages, safe file formats, vetted and versioned training and fine-tuning data, validation of documents before they enter a RAG index, and evaluations that would reveal a backdoor or bias before release.

The risks (OWASP LLM03 and LLM04, 2025)

• Data poisoning: someone manipulates training, fine-tuning or embedding data to add weaknesses, biases or backdoors. OWASP notes a backdoor can leave behaviour unchanged until a trigger phrase appears, which makes it hard to find.
• Poisoned retrieval content: a document with hidden instructions or false facts added to the knowledge base.
• Unsafe model files: OWASP warns about malicious pickling, where loading a model file runs code.
• Third-party models and adapters: open models and fine-tuning adapters (LoRA, PEFT) from public hubs, of unknown origin, possibly tampered with or mislabelled.
• Ordinary software supply chain: vulnerable or malicious packages, plugins and MCP servers.

Controls

Models and adapters

• Use models from known publishers; check signatures or hashes; pin exact versions.
• Prefer safe formats (such as safetensors) over formats that can execute code on load.
• Keep an inventory of every model and adapter in use, with its source and licence.
• Evaluate any new model or adapter on your own tests, including safety tests, before use.

Training and fine-tuning data

• Record the source of every dataset; restrict who can change it.
• Review samples, look for duplicates, outliers and odd trigger-like strings.
• Version datasets so a problem can be traced and rolled back.

Retrieval content

• Index only approved sources; review user-contributed content before it becomes searchable.
• Strip or flag hidden text (white text, tiny fonts) and instructions inside documents.
• Log which documents were used for each answer, so a poisoned one can be found and removed.

Software and tools

• Dependency scanning, pinned versions, reviewed third-party plugins and MCP servers.

Detecting a problem

• Regression and red-team tests after every model or data change.
• Monitoring for sudden behaviour changes on particular inputs.
• The ability to roll back to a known-good model, adapter, dataset or index.

What interviewers look for: treating models and data as supply chain components with provenance, verification and rollback, just like code.