Transferability

Expanded Definition

Transferability describes how well an adversarial example, perturbation, or prompt-crafted attack on one model carries over to another model. In practice, it is a measure of attack portability: the higher the transferability, the more likely an input crafted against a surrogate model will also degrade accuracy, trigger misclassification, or produce unintended output in a different target model.

The key boundary is that transferability is about cross-model generalisation of the attack effect, not about whether a model is simply vulnerable in a broad sense. Two systems may share architecture, training data lineage, or preprocessing choices and still differ meaningfully in transferability because small implementation differences can change the decision boundary. That is why the term is used heavily in adversarial machine learning, model evaluation, and red teaming. For a formal treatment of adversarial AI risk and testing concepts, the NIST AI Risk Management Framework is a useful standards reference.

A common misunderstanding is to treat transferability as a property of the attack alone. It is really a relationship between the attack method, the source model used to craft it, and the target model it is meant to affect.

Examples and Use Cases

Transferability shows up whenever teams test whether a weakness discovered in one model family could affect another. Typical cases include:

• Crafting an adversarial image against one vision classifier and checking whether the same perturbation fools a second classifier.
• Using a surrogate model to probe a black-box target when direct gradient access is unavailable.
• Evaluating whether prompt-based attacks on one LLM configuration also succeed against a different deployment with similar safety tuning.
• Comparing transfer across models that share preprocessing, tokenisation, or fine-tuning data, since shared design choices can improve portability.
• Measuring transfer as part of red-team validation to estimate how reusable a discovered attack would be across an environment with multiple models.

One practical tradeoff is that attacks designed for high transferability are often less optimised for the source model itself. A technique that works extremely well on the original model may be more brittle when moved elsewhere, while a more broadly transferable method may need to sacrifice some precision to generalise.

Security Implications

Transferability matters because it determines whether a discovered weakness is isolated or reusable. Low transferability can limit blast radius to one model, but high transferability turns a single successful adversarial method into a reusable pattern that may affect multiple deployed systems, especially when teams reuse architectures, checkpoints, or training pipelines.

When transferability is misunderstood, organisations may overestimate the safety of a second model because it is not the original target. That can lead to false confidence in model diversity, weak red-team coverage, and under-testing of similar models that share enough structure to respond the same way. In operational terms, the failure mode is often that a control validates one model instance while leaving a whole family of similar models exposed.

A useful practitioner observation is that transferability should be assessed alongside model similarity, not in isolation. If the target fleet shares preprocessing, objectives, or fine-tuning patterns, a single attack path may have wider reach than a local test result suggests.

Security, Operational and Governance Implications

For practitioners, transferability is not just an academic metric. It influences how much confidence you can place in a single red-team result, how broadly a model fix should be rolled out, and how much separation is needed between model variants in a production portfolio. High transferability usually means one model finding should be treated as a fleet-level warning rather than a one-off defect.

Governance-wise, the term helps distinguish model-specific hardening from systemic risk reduction. If a vulnerable behaviour transfers across several models, the right response is often to review shared data, shared prompts, shared deployment patterns, or shared evaluation methods instead of tuning one model in isolation. That makes transferability a useful concept for prioritising retesting, patch propagation, and change control.

For teams running multiple models, the main question is whether similarity creates shared exposure. If it does, the security programme should assume that an attack validated once may recur elsewhere unless the underlying assumptions change.

Risk and Threat Considerations

Transferability creates risk because attackers value reusable methods. A perturbation, jailbreak pattern, or surrogate-model attack that generalises across targets can lower the cost of exploitation and increase the chance of success against a model portfolio that looks diverse on the surface but is similar underneath.

Failure mechanism: The attacker studies one model, then reuses the resulting adversarial method against another model with overlapping architecture, training patterns, or alignment behaviour. Shared design choices can preserve enough of the failure surface that the same attack effect persists after transfer.

Impact: Multiple models may be exposed to the same abuse path, expanding blast radius, weakening confidence in vendor or model diversity, and increasing the chance that a single adversarial technique affects production workflows at scale.