Some risks are not exploits at all. They are documented features that grant the model's author code execution on your machine, written down in a config file. The danger is that they are so normal nobody reads them.
This class is different from the rest, and it is worth ending the threat posts on, because it is the one that is not really an attack. It is a setting. A perfectly legitimate, widely used, well-documented setting that happens to mean "let the person who made this model run code on my computer," and almost nobody reads it that way in the moment.
If you have worked with models from the popular hubs, you have seen the flag. A config that says, in effect, trust the remote code. When that is set, the loading library will go and fetch Python files from the model's repository and execute them as part of loading the model. There is a related pattern where a config maps class names to module paths, and those paths can point at remote locations whose code is pulled and run at load time.
Neither of these is a bug. They exist because some models genuinely need custom code to run, a novel architecture, a special tokenizer, something the standard library does not implement. The feature is the answer to a real problem. The trouble is purely that it relocates the trust decision to a place where people do not make decisions.
Why "it is a feature" does not make it safe
When you run an installer and it asks for administrator rights, you at least know you granted something. Deferred trust is the same grant with none of the ceremony. It is one line in a config file, often copied from a tutorial, frequently set because the model simply would not load otherwise and flipping the flag made the error go away. At that moment the engineer is not thinking "I am authorising this stranger to execute arbitrary code on every machine that loads this model." They are thinking "I want the error to stop."
And the grant is not a one-time thing. It applies on every machine that loads the model, in every environment, including the production ones, including the CI runner with the deployment credentials. The author can change the remote code after you first looked at it. You vetted a snapshot. You authorised a stream.
That is the whole risk. Not that the feature is malicious, but that it is an explicit security boundary disguised as a convenience toggle, and boundaries you cross without noticing are the ones that hurt you.
How we treat it, and why we do not just block it
A blunt tool would scream every time it sees the flag. That is unhelpful, because the flag is often set for entirely good reasons, and a tool that treats every legitimate use as a critical incident teaches its users to dismiss it. A blunt tool in the other direction would ignore the flag because "it is a documented feature, not malware." That is worse, because it leaves the single clearest case of handing over code execution completely unremarked.
The useful posture is the middle one. The flag is not malware and we do not call it malware. It is a disclosure. The job of a scanner is to surface it, to say clearly that this model asks for code execution on load and that you are trusting its author with that, and to make sure that decision is made on purpose by someone who understands it, rather than absorbed silently from a copied snippet. Surfacing the remote-code references, including the less obvious mapped form, is the substance of it. The point is to convert an invisible grant into a visible one.
What to do about it
Treat the trust flag like a credential, because functionally it is one. Know which of your models set it. Pin the exact revision you reviewed so that the remote code cannot change underneath you. And ask, every time, whether this particular model actually needs it or whether the flag got switched on once to silence an error and never switched back.
The strongest version of this control is organisational, not technical. A model that asks for code execution on load should go through the same review you would give any third-party code you were about to run with production access, because that is exactly what it is.
