Distribution and Typosquatting: Model-Hub Trust and Dependency Confusion

Every model download begins with a name: an organization and a model, typed into a config or a script. That name is a promise that resolving it yields the artifact you intend. But names are cheap, human, and ambiguous, and an attacker who controls a similar name controls what your resolution returns. The software world learned this painfully through package typosquatting and dependency confusion — attacks that never touch the victim's code, only the names it resolves — and model hubs, which distribute artifacts by name exactly like package registries, inherit the same class of attack. The most carefully verified loading pipeline is defeated if it verifies the wrong artifact, and it verifies the wrong artifact when it resolves the wrong name.

Names are the weak link

A model hub is a registry that maps names to artifacts. A consumer references a model by a name — typically a namespace (an organization or user) and a model identifier — and the hub resolves that name to a downloadable checkpoint. This indirection is convenient and necessary at scale, but it means the consumer's trust flows through the name: they trust that the name resolves to the artifact the name's legitimate owner published. Break that assumption and every downstream verification is verifying the wrong thing.

The attacks in this space do not exploit the artifact format or the loader; they exploit the resolution of names to artifacts. If an attacker can make a trusted-looking name resolve to their artifact — by registering a confusingly similar name, by impersonating a namespace, or by exploiting resolution precedence — the consumer downloads and, having verified the attacker's artifact's integrity, trusts it. Integrity verification confirms the artifact was not altered in transit; it does not confirm the name resolved to the right owner.

The defensive principle is that identity resolution must be explicit and verified: resolve to an exact, intended name in a trusted namespace, and verify that the artifact is signed by the identity you expected, not merely that it is intact. A name is a claim; trust requires binding that claim to a verified publisher identity.

Typosquatting and name confusion

Typosquatting registers a name that is easily confused with a legitimate one — a transposed letter, a plausible misspelling, a different but similar namespace — and waits for someone to reach it by mistake or by trusting the resemblance. In a model hub, an attacker might publish a checkpoint under a name one character off from a popular model, or under an organization name that mimics a well-known lab. A developer who mistypes, or who copies a name from an untrusted source, or who simply trusts that a similar-looking name is the real one, downloads the attacker's artifact.

Name confusion is broader than typos. Homoglyph attacks use visually identical characters from different alphabets; namespace impersonation registers an org name that looks official; and 'official-sounding' names exploit the absence of a verified link between a name and its real-world owner. All share the mechanism of exploiting the gap between what a name looks like and who actually controls it, and all route a trusting consumer to an attacker-controlled artifact.

The defense is to eliminate reliance on name resemblance. Pin exact, verified names and namespaces from a trusted source of truth rather than typing or copying them ad hoc; prefer publishers whose identity the hub has verified; and, decisively, verify a signature over the artifact against the expected publisher's key so that even a perfectly-confusing name fails when the artifact is not signed by the real owner. Resemblance is not identity; only a cryptographic binding is.

Dependency confusion for models

Dependency confusion is a subtler, more automated attack. It exploits resolution rules that, when a name could refer to either a private (internal) artifact or a public one, prefer or fall back to the public one. An attacker who learns the name of a private internal model publishes a public artifact with the same name; a resolver configured to check public sources — or to fall back to them — fetches the attacker's public artifact instead of the intended private one, with no typo and no human mistake. The victim's automation does the wrong thing by following its configured precedence.

This ported directly from package registries, where dependency confusion compromised many organizations by exploiting exactly this public-over-private precedence. Model pipelines that resolve names across a mix of internal and public hubs are vulnerable in the same way: an internal model name leaked or guessed, plus a resolver that consults public hubs, equals an attacker artifact loaded into an internal pipeline. It is especially dangerous because it is silent and automated — no one mistyped anything; the resolver simply preferred the public source.

The defense is explicit, unambiguous resolution: scope internal model names to internal sources only, never falling back to public hubs for names that should be private; use namespaces or prefixes that cannot collide with public names; and verify publisher identity so a same-named public artifact fails the signature check. The rule is that resolution precedence must never let a public artifact satisfy a reference that should resolve internally.

The whole reference, not just the model

Name confusion applies to everything a model reference pulls, not just the weights. A config can reference a tokenizer, a base model, or code by name, and each of those references is independently attackable by the same typosquatting and dependency-confusion techniques. A pipeline that carefully pins the main model but resolves its dependencies by loose names has simply moved the attack to the dependencies. The reference graph — model, config, tokenizer, base, and any code — must all resolve to verified identities.

This mirrors software dependency security, where pinning the top-level package but not its transitive dependencies leaves the door open. For models, the transitive references are the config-specified components, and they deserve the same pinning and verification as the model itself. An attacker who cannot squat the popular model may well be able to squat a less-scrutinized tokenizer or base that the model pulls, achieving the same compromise through a side door.

The defense is to pin and verify the whole reference graph: exact names, trusted namespaces, and signatures for every artifact the load resolves, transitively. Treat the config's references as dependencies to be locked, and verify each resolved artifact's publisher identity, so no loosely-named component becomes the weak link the main model's careful pinning tried to close.

Defending distribution and resolution

The controls compose into verified identity resolution. Pin exact model names and trusted namespaces from a controlled source of truth rather than ad-hoc entry. Scope internal names to internal sources with no public fallback, using collision-proof namespaces. Verify a signature over every resolved artifact against the expected publisher's key, so name confusion fails at the cryptographic check. Pin the whole reference graph transitively. And combine this with the format and integrity defenses from the rest of the series so that a correctly-resolved artifact is also safely loaded.

The unifying principle is that a name is not an identity. Resolution turns a name into an artifact, and unless that resolution is bound to a verified publisher identity, whoever can register a confusing or colliding name can substitute their artifact. Every distribution attack here — typosquatting, impersonation, dependency confusion — exploits the same gap between name and identity, and every defense closes it by making identity, not resemblance or precedence, the thing that decides what you load.

The synthesis, ported from well-understood package-registry attacks and consistent with NIST's supply-chain guidance and the model-supply-chain framing of Gu and colleagues, is that model references must resolve to pinned, verified identities. Exact names, trusted namespaces, no public fallback for private names, and signature verification over the whole reference graph convert name-based distribution from an attack surface into a verified channel. Otherwise, a supply chain that trusts a name trusts everyone who can register a similar one.

Why this matters for agents

Agent pipelines resolve many model names automatically — in configs, in CI, in dependency manifests — often across a mix of internal and public sources, which is exactly the condition dependency confusion exploits. A single internal model name that collides with an attacker's public artifact, or a mistyped popular model, routes an attacker's checkpoint into the agent's infrastructure, where the rest of the artifact and alignment attacks then apply. The distribution layer is the entry point that decides which artifact all the other defenses will be applied to.

The organizing lesson is that verified identity resolution is foundational agent supply-chain hygiene: pin exact names and namespaces, forbid public fallback for private names, and verify publisher signatures over the whole reference graph. The package-registry world's hard-won lessons — typosquatting and dependency confusion are real, automated, and low-cost — transfer directly to model hubs. For an agent team, the first question of model supply-chain security is not 'is this artifact safe?' but 'is this the artifact I meant?' — and only verified identity resolution answers it.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

model_resolution_policy:
  names:
    pinning: exact
    source_of_truth: controlled_manifest
  namespaces:
    internal_prefix: reserved
    public_fallback_for_internal: forbidden
    collision_proof: true
  verification:
    publisher_signature: required
    expected_identity_key: pinned
  reference_graph:
    pin_transitive: [config, tokenizer, base, code]
    verify_each: true

# DEFENSIVE PRE-CHECK — resolve to a verified identity, not a resemblance
function safe_resolve(ref):
    assert exact_match_in_manifest(ref), "name not pinned"
    if is_internal(ref):
        assert source_is_internal(ref), "public fallback for private name"
    for dep in reference_graph(ref):    # config, tokenizer, base, code
        assert verify_publisher_signature(dep, expected_key(dep)), "bad signer"
    return True   # only then fetch and load

Glossary

Model hub

A registry that distributes model checkpoints by name, resolving a name to a downloadable artifact.

Typosquatting

Registering a name easily confused with a legitimate one to catch consumers who reach it by mistake or resemblance.

Homoglyph attack

Using visually identical characters from different alphabets to create a name indistinguishable from a trusted one.

Namespace impersonation

Registering an organization or user name that mimics a trusted publisher.

Dependency confusion

Exploiting resolution rules that prefer a public artifact over an intended private one of the same name.

Reference graph

The set of names a model reference resolves transitively — model, config, tokenizer, base, and code.

Identity resolution

Binding a name to a verified publisher identity so trust depends on identity, not resemblance or precedence.

Publisher signature

A cryptographic signature over an artifact by its publisher, verified against the expected identity's key.

References

1. Gu et al., BadNets: Identifying Vulnerabilities in the Machine Learning Model Supply Chain (arXiv 1708.06733)
2. NIST SP 800-161r1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
3. NIST SP 800-218, Secure Software Development Framework (SSDF)
4. NIST AI 100-2 e2023, Adversarial Machine Learning: A Taxonomy and Terminology
5. safetensors format specification (Hugging Face)
6. MITRE ATLAS (Adversarial Threat Landscape for AI Systems)