An adversarial-attack command-line wrapper installs with its own pinned versions of the ML framework and the attack libraries it wraps. What problems does that create when you add it to an existing evaluation environment, and how do you contain them?

Dependency pins are the least glamorous cost of adopting a wrapper and the one that most often decides the question — often before you have run a single attack. **Why a wrapper pins hard.** It sits on top of libraries whose APIs and defaults move: an attack library such as the Adversarial Robustness Toolbox, a text-attack library, and beneath them a deep-learning framework and a numerics stack (NumPy, SciPy, scikit-learn), each with its own ranges. To keep a menu of attacks working, the wrapper pins the versions it was tested against. That is responsible of it, and it means the wrapper effectively *owns the environment it lives in*. **The failure modes.** 1. *Install-time conflict.* The cheapest to detect: the resolver cannot satisfy the wrapper's pins alongside the framework and numerics versions your training or serving code requires, and the install fails or backtracks for an hour. Cost: an engineer-day, usually two. 2. *Untested resolution.* You force it through by loosening a pin. Nothing crashes — that you would notice — but the wrapper now drives library versions it never met. The dangerous form is a default that moved: "the same attack" is quietly a different attack from last quarter's run, and the two numbers are no longer comparable even though the command line was identical. 3. *Platform reach.* Pins interact with hardware. A stack pinned to a framework build without a wheel for your accelerator silently lands you on CPU, where gradient attacks run one to two orders of magnitude slower. Nobody reports that as a limitation; what actually happens is that somebody cuts `max_iter` or the sample count so the run finishes before the end of the day, and the weakened configuration produces a more favourable robustness number. That is how a packaging decision becomes a false claim about a model. **Where the number misleads.** Any comparison across time or across teams silently assumes the stack was constant. It usually was not. Two runs of the same named attack under different resolved versions can differ because a default norm, a default step size, a clipping behaviour or a stopping rule changed upstream. Without the frozen package set beside each result, you cannot attribute a delta to the model rather than to the environment — and the natural instinct is to attribute it to the model, because that is the thing the report is about. **Containment.** - *Isolate.* A separate virtual environment, or better a container image, containing nothing of your training or serving stack. Never install a red-team wrapper into a production or training image; the blast radius of a resolver decision there is your deployment. - *Make the seam a process seam.* Have the wrapper reach the thing under test the way an external client would — over an endpoint — or exchange inputs and outputs as files. An import-level seam forces two dependency stacks to coexist in one interpreter; a process seam never does. This is also the more honest black-box setup. - *Freeze and record.* Capture `pip freeze` (or the image digest) alongside every result set, and put the library name and version in the result record itself. - *Rebuild rather than upgrade in place.* Treat the wrapper environment as disposable, so an upgrade produces a new image you can run the old suite against, rather than mutating the environment your history came from. **What to check, and the cost of checking.** Before installing anything, compare the wrapper's declared framework pin against the version your models actually load, and its supported input domains and access modes against your estate — a five-minute read of its requirements file, and decisive if it fails. After installing in isolation, verify the accelerator is really in use (a one-line device check) rather than discovering it from wall-clock. Then run one known-attackable reference model through the new environment and confirm you reproduce the old environment's numbers; that regression run is the only thing that tells you a stack change was behaviour-neutral. **When to walk away.** If the pins cannot coexist with the framework version your models require even under isolation — because the pinned framework cannot load your serialised models at all — the wrapper cannot evaluate your estate. Calling the attack library directly, at a version you control, is then the honest answer, and you have spent a day rather than a quarter finding out.