TL;DR: Poison enters through scraped web content (expired domains, edits timed to snapshots), user feedback and fine-tuning data, third-party datasets, labelling vendors and compromised pipelines. Detection in the pipeline combines provenance checks (snapshots with hashes, source allowlists), data validation (schema, distribution and duplicate analysis), outlier detection on embeddings and per-source statistics, training-dynamics monitoring (loss and influence anomalies), and evaluation gates including trigger probing. Because clean-label and small poisons evade detection, pair it with write controls, lineage and containment.
How to approach it
List entry points first, since detection design depends on where poison comes from. Then build detection layer by layer through the pipeline, and close with what detection cannot do and how you compensate.
A strong answer
Scraped web
expired domains, edits
Feedback, vendors
labels, fine-tune data
Provenance
snapshots with hashes
Data validation
schema, drift, dupes
Behaviour tests
triggers, canaries
Entry points.
| Source | How poison arrives |
|---|---|
| Web-scale scraping | Expired domains serving new content at referenced URLs; timed edits before snapshots (Carlini et al., 2023) |
| User feedback, ratings, conversations | Coordinated users shaping fine-tuning data |
| Third-party datasets and vendors | Upstream compromise or a malicious contributor |
| Labelling workforce | Mislabelled or crafted samples |
| Internal pipeline | Compromised jobs or credentials altering data |
Detection, through the pipeline.
- Ingestion: source allowlists; fetch once and snapshot with content hashes; verify hashes at training time; record provenance per record.
- Validation: schema and label checks; distribution shifts per source and per time window; near-duplicate clusters (coordinated injection often repeats patterns).
- Outlier detection: in embedding space, records far from their class or clustering unusually; per-contributor statistics (a user whose ratings diverge sharply).
- Training dynamics: monitor loss per subset; influence-style analysis to find samples with outsized effect on specific behaviours.
- Evaluation gates: regression suites, behaviour on sensitive tasks, probing for known trigger styles, comparison against the previous model on targeted inputs.
What detection misses. Clean-label poisons that look correct, very small poisons (a 2025 study found around 250 documents could implant a simple backdoor across model sizes tested), and adaptive attackers who shape poison to look normal. Treat detection as rate reduction.
Compensating controls.
- Write access: restrict and authenticate who can add training data; rate-limit and weight contributions from new or unverified users.
- Lineage: datasets and models recorded in an AI-BOM, so when poison is found you can identify and retrain affected models.
- Containment: systems built so a model misbehaving on some input cannot take harmful actions alone.
What interviewers probe next
- "A single user contributed 2,000 highly rated conversations last week. What do you do?" Quarantine pending review, compare against population statistics, and cap per-user influence on training mixes.
- "How do you handle RAG corpora?" Same provenance and write controls; plus per-document trust labels and monitoring for documents that dominate retrieval for many queries.
- "Can differential privacy help?" It limits each record's influence, which raises the poison quantity needed, at an accuracy cost.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A model is trained on a mix of licensed data, web scrapes and user feedback, and the team wants to detect poisoning in the pipeline before each training run.
Start here
Where can poison enter?
Which sources can an outsider influence?
Scraped web content (expired domains, edits timed to snapshots), user feedback and fine-tuning data, third-party datasets, labelling vendors, and compromised pipelines or storage. Each source has different trust, so detection and controls should be per source.
Carry it forwardMap poison entry points per data source.
Weak answerTreating the dataset as one trusted blob.
Constraint changes
What provenance checks would you add?
Could you trace a bad example back to its source?
Snapshot sources with content hashes, keep source allowlists, record lineage from source to training batch, verify that scraped content matches what was reviewed, and track who can write to each store. Provenance makes it possible to answer 'where did this example come from' after the fact.
Carry it forwardHashes and lineage make poison traceable.
Weak answerScraping fresh at training time without snapshots.
Constraint changes
What statistical detection would you run?
What would a planted trigger look like statistically?
Schema and distribution checks, duplicate and near-duplicate analysis, outlier detection on embeddings, per-source statistics compared with past batches, and monitoring of training dynamics such as unusual loss or influence for specific examples. Look especially for rare phrases repeated across examples with an unusual target.
Carry it forwardLook for outliers, repetition and per-source shifts.
Weak answerRelying only on label audits.
Constraint changes
What if the poison is clean-label or very small?
What if every example looks correct?
Detection will miss some of it: clean-label poisons have correct labels and look normal, and small numbers of documents can be enough to implant behaviour. So pair detection with write controls on sources, containment of what the model can do, and evaluation gates that probe for triggered behaviour.
Carry it forwardDetection is partial; combine it with control and containment.
Weak answerTreating a clean detection run as proof of no poison.
Constraint changes
How would you gate the trained model?
What would you check before deploying?
Evaluate on a trusted set against the previous model, compare segments, probe for behaviour that appears only with specific inputs, and require sign-off before deployment. Keep the last trusted model ready for rollback, and record which data version produced each model.
Carry it forwardEvaluation gates catch what data checks miss.
Weak answerDeploying straight from the training job.
Now defend it
What detection programme would you build?
Per-source controls: snapshots with hashes, allowlists, lineage and write restrictions. Statistical checks: distributions, duplicates, embedding outliers, per-source shifts and training-dynamics monitoring. Gates: trusted-set evaluation, segment comparison, trigger probing and sign-off with rollback. Accept that clean-label and small poisons evade detection, so contain what models can do.
How it's scored
Weak: "Review the data manually."
Hire: Names realistic entry points and layered pipeline detection with provenance.
Strong Hire: Adds training-dynamics signals, evaluation gates, explicit limits of detection with the small-poison result, and compensating write control, lineage and containment.
Common mistakes
- Re-fetching URLs at training time instead of using hashed snapshots.
- Treating user feedback as trusted training data.
- Expecting detection to catch clean-label attacks.