Weights are numbers. They do not contain URLs. When a model file does, it is because someone wants it to talk to a server, and that is worth knowing before you load it.
This is the simplest class to explain and one of the most telling, because it is less an exploit than a confession.
A model's weights are numbers. A tokenizer is a vocabulary. A config is settings. None of these things has any legitimate need to contain a hardcoded web address pointing at a server out on the internet. So when a model file does carry one, it is usually because the file was built to reach that server, and there are only a few reasons to build a model that phones home.
Why a model calls out
The first reason is exfiltration. A payload elsewhere in the file, the kind we covered in the load-time and inference-time posts, does its work and then sends the loot somewhere: environment variables, credentials, the contents of a file it managed to read. The web address is the drop point.
The second is command and control. Rather than hardcode everything, the payload contacts a server to ask what to do next. This makes an attack flexible and lets the operator change behaviour after the model is already deployed across many victims. The address is the mailbox.
The third is the canary. Attackers, especially during the development and spraying of a campaign, want to know when their payload fires and on whose machine. So the model makes a single quiet request to a service that simply records that the request happened, along with the victim's address and a timestamp. No data is stolen in that moment. The attacker is just counting hits.
That third case is why we treat certain kinds of destinations as much louder signals than others. There is a whole category of services that exist specifically to receive out-of-band callbacks during security testing and intrusions: request collectors, tunneling endpoints, interaction loggers. They are useful to legitimate testers and indispensable to attackers, and they have essentially no business being referenced inside a saved model. A file that points at one is not ambiguous.
The judgement call in the middle
The clean cases are the two ends. A reference to one of those callback services is almost always bad. A reference to a well-known machine-learning host, the place the model legitimately came from, is almost always fine, because models do sometimes carry a pointer back to their own home repository or a standard framework domain.
The interesting work is the middle: an unfamiliar domain, in a file that has no obvious reason to reach it. One stray address might be a leftover from training, a documentation link, a comment. Several addresses to unknown destinations start to tell a different story. We will not publish the exact way we weigh that, because the moment you publish a threshold you hand attackers the recipe for staying just under it. What we will say is that the question is never simply "is there a URL." It is "does this file have a reason to talk to this place, and how hard is someone working to look innocent."
What to do about it
At the platform level, the strongest control is not detection at all, it is the network. A model serving environment that cannot make arbitrary outbound connections defeats most of this class outright, because a beacon that cannot leave the building is just a string. Egress filtering is unglamorous and extremely effective.
At the file level, treat an outbound reference in a model as something to explain before you deploy, not after you are breached. A clean model does not need to phone anyone. If yours wants to, find out why.
