What is the difference between an Evasion Attack and a Poisoning Attack?

How evasion and poisoning differ in where the attack lands

An evasion attack targets the model at inference time. The attacker crafts inputs so the model makes the wrong prediction, classification, or detection decision on that specific request. A poisoning attack targets the model earlier in the lifecycle, by corrupting training data, labels, or the training pipeline so the resulting model is systematically biased or backdoored.

The practical distinction is timing and persistence. Evasion is usually one-off and depends on the runtime input path; poisoning is upstream and can persist across many future predictions because the model has already learned from the corrupted material.

What changes in the defensive mindset

Evasion tells you to harden the inference boundary, validate inputs, and monitor for adversarial patterns that look normal to users but abnormal to the model. Poisoning tells you to protect the learning pipeline, including dataset provenance, label quality, CI/CD-style controls around training, and approval of model updates. If you only defend one side, the other can still undermine model reliability.

These are different failure surfaces even when the business impact looks similar. Evasion usually produces immediate misclassification or missed detection. Poisoning can create slower, broader damage, including degraded accuracy, hidden backdoors, or behaviour that appears correct during testing but fails after deployment.

For a deeper treatment of training-time corruption, see AI Data Poisoning and Backdoors Guide. If you are mapping the runtime side of the problem, adversarial AI references such as MITRE ATLAS adversarial AI threat matrix are useful for structuring how inputs, prompts, and other attack techniques affect model behaviour.

Why the distinction matters for testing and response

Testing for evasion is mostly about robustness under hostile inputs, so you want adversarial examples, red-team prompts, and detection thresholds that are resilient to manipulation at the point of use. Testing for poisoning is about lineage and trust in the learning inputs, so you need dataset review, integrity checks, and change control for data, labels, and model artifacts.

When the model behaves badly only for certain inputs, suspect evasion first. When the model behaves oddly across many cases, or changes after retraining, suspect poisoning or another upstream integrity problem. That distinction shapes whether you investigate the request stream or the training supply chain.

Current AI threat guidance also treats the two as separate but related attack classes. The same overall system may need different controls for each path, because the defender must protect both the decision boundary and the data the model learns from. For broader threat context, Anthropic’s AI-orchestrated cyber espionage campaign report is a useful reminder that modern attacks can combine automation, credential abuse, and multi-stage execution.

Risk and Threat Considerations

Evasion and poisoning create different risk profiles, but both can undermine trust in the model’s outputs. Evasion usually creates selective failure that is harder to notice in production, while poisoning can silently corrupt many future decisions and make the model unsafe even when no single request looks suspicious.

Failure mechanism: Evasion works by manipulating inputs so the model misfires at inference time; poisoning works by corrupting training data, labels, or the pipeline so the model internalises the wrong behaviour.

Impact: Evasion tends to produce immediate, request-specific harm, while poisoning can create durable accuracy loss, hidden backdoors, or systemic misclassification that persists until the model or dataset is rebuilt.

Practitioner Guidance

What to prioritise: Treat inference controls and training-data controls as separate workstreams, because the right test, owner, and evidence differ for each. A single control family rarely covers both attack paths well enough.

What to verify: Confirm that you can trace every training set, label source, and model update back to an approved origin, and that runtime inputs are monitored for anomalous patterns that change model outcomes. If you cannot explain either lineage, you do not yet have enough assurance.

Practitioner takeaway: The key decision is not which attack is “worse”, it is whether your controls protect both the model’s learning inputs and the live inputs it sees in production.

Related resources from NHI Mgmt Group

• What is the difference between attack surface management and NHI governance?
• What is the difference between prompt injection and tool poisoning?
• What is the difference between attack surface management and identity attack surface management?
• What is the difference between a normal Kerberos ticket issue and a Golden Ticket attack?