Inferensys

Glossary

Data Poisoning

A security attack where a malicious actor corrupts the training dataset with manipulated samples to intentionally degrade the performance or introduce backdoors into the resulting model.
Data scientist building training data pipeline on laptop, data preprocessing visible, technical workspace.
ADVERSARIAL ATTACK VECTOR

What is Data Poisoning?

Data poisoning is a security attack where a malicious actor corrupts a machine learning model's training dataset with manipulated samples to intentionally degrade its performance or implant a hidden backdoor.

Data poisoning is an integrity attack targeting the training phase of the machine learning lifecycle. An adversary injects carefully crafted, mislabeled, or otherwise malicious samples into the training corpus. The goal is to corrupt the model's learned decision boundary, causing it to systematically misclassify specific inputs at inference time while maintaining normal performance on clean data to evade detection.

Defenses against data poisoning include robust data provenance tracking, anomaly detection on incoming training samples, and differential privacy techniques that limit the influence of any single data point. In federated learning contexts, Byzantine fault-tolerant aggregation protocols are critical to prevent poisoned model updates from a compromised factory client from degrading the shared global model.

ADVERSARIAL THREAT VECTORS

Key Characteristics of Data Poisoning

Data poisoning is a targeted attack on model integrity, not just accuracy. It exploits the training pipeline to embed malicious behavior that activates under specific conditions.

01

Backdoor Injection

An attacker inserts subtly modified samples with a specific trigger pattern (e.g., a pixel artifact or metadata tag) associated with a malicious target label. The model learns to associate the trigger with the attacker's desired output.

  • Clean-label attack: Poisoned samples are correctly labeled, making detection harder
  • Dirty-label attack: Attacker mislabels samples, relying on volume to overwhelm legitimate data
  • Activation occurs only when the trigger is present in production input
  • Example: A stop sign with a small sticker is classified as a speed limit sign
02

Availability Attacks

The attacker's goal is to indiscriminately degrade overall model performance, rendering it useless for all inputs rather than targeting specific misclassifications.

  • Achieved by injecting noisy, mislabeled, or nonsensical samples
  • Maximizes test error across all classes uniformly
  • Often easier to execute than targeted backdoor attacks
  • Defenses include robust training and anomaly detection on training data
  • Example: Flooding a product review sentiment model with random text labeled as positive
03

Targeted Misclassification

The attacker aims to alter the model's decision boundary for a specific source class so that it is consistently misclassified as a specific target class.

  • Does not require a trigger in production; the attack is on the class representation itself
  • Often achieved by perturbing feature vectors of the source class toward the target class
  • Can be used to bypass content filters or evade fraud detection systems
  • Example: Crafting phishing emails that a classifier consistently labels as legitimate corporate communications
04

Label Flipping

A simple but effective attack where the adversary intentionally changes the labels of a subset of training data to corrupt the learned mapping between features and outputs.

  • Particularly dangerous in crowdsourced labeling or semi-supervised learning pipelines
  • Even a small percentage of flipped labels can significantly degrade decision boundaries
  • Defenses include cross-validation against trusted datasets and consensus-based labeling
  • Example: In a federated learning scenario, a compromised factory node flips 'normal' vibration labels to 'faulty'
05

Model Skewing

The attacker gradually shifts the model's learned distribution by injecting biased samples over time, causing the model to drift away from its intended behavior without triggering abrupt performance drops.

  • Designed to evade drift detection systems that look for sudden changes
  • Exploits online learning or continuous training pipelines
  • The cumulative effect can embed systemic bias or regulatory non-compliance
  • Example: Slowly introducing biased loan application data to shift a credit model's approval boundary
06

Gradient-Based Poisoning

An advanced attack where the adversary solves an optimization problem to craft poisoned samples that maximally corrupt the model's parameters when used in training.

  • Requires white-box access to the model architecture and loss function
  • Generates samples that produce malicious gradient updates during backpropagation
  • Can achieve precise control over the final model's behavior with minimal data
  • Defenses include gradient clipping, robust aggregation, and differential privacy
  • Example: Crafting synthetic images that, when included in a federated round, steer the global model toward a backdoored state
DATA POISONING SECURITY

Frequently Asked Questions

Critical questions about defending federated factory learning systems against adversarial data manipulation attacks that compromise model integrity and introduce backdoors.

A data poisoning attack is a security breach where a malicious actor deliberately injects manipulated or misleading samples into a model's training dataset to corrupt its learned behavior. The attacker's objective is to degrade the model's overall accuracy, cause targeted misclassifications on specific inputs, or implant a hidden backdoor trigger that activates only when a secret pattern is present. Unlike inference-time adversarial examples, poisoning occurs during the training phase, making the compromise baked into the model's parameters. In a federated learning for factory fleets context, a compromised factory node could submit poisoned local updates that contaminate the global model shared across all production sites, potentially causing systematic quality inspection failures or unsafe equipment control decisions.

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.