cd /news/ai-safety/the-u-s-vs-china-ai-trap-an-incomple… · home topics ai-safety article
[ARTICLE · art-113036] src=blogs.cisco.com ↗ pub= topic=ai-safety verified=true sentiment=· neutral

The “U.S. vs. China” AI Trap: An Incomplete Proxy for AI Security

New research from Cisco and VAIL found that geographic labels such as 'U.S. model' or 'Chinese model' are an incomplete proxy for AI security risk, as modern models inherit weights and dependencies across borders—a condition called 'provenance entanglement.' Using two fingerprinting methods, the study showed that upstream lineage remains detectable even after post-training and re-release under a different publisher, urging enterprises, regulators, and industry to consider technical lineage, not just origin, in due diligence and policy.

read11 min views2 publishedAug 27, 2026
The “U.S. vs. China” AI Trap: An Incomplete Proxy for AI Security
Image: Blogs (auto-discovered)

With research support from Manish Shah (VAIL), Jonah Leshin (VAIL), and Ankit Garg

When you look at an AI model’s repository page, you see the name of the model and an associated publisher. In policy and industry conversations, the publisher often gets collapsed into a country label—a “U.S. model” or a “Chinese model”—used as shorthand for where a model, and alleged risk, comes from. New research from Cisco and VAIL tested that shorthand directly and found that geographic labels are an incomplete proxy for real-world AI risk. Solely relying on that label to assess the model’s security or technical independence can lead to significant blind spots in an organization’s AI security strategy.

That label isn’t meaningless, it can provide insight into who is the accountable developer, what jurisdiction applies, and what a procurement process should consider. What it doesn’t establish is technical independence. Modern AI models are rarely built in isolation: they inherit weights, training data, and other dependencies that cross organizational and geographic boundaries, a condition Cisco and VAIL call **provenance entanglement. **The name on the finished product reflects the last step in that chain, not necessarily an accurate understanding of the model’s true technical lineage.

**Putting the label to the test **

Our research asked a simple question: do a model’s publisher and country of origin reliably predict its technical lineage? Using two independent model fingerprinting methods—one analyzing model weights and the other tracking behavioral patterns—the answer is no. Signals associated with provenance entanglement remain detectable from upstream sources, even after the model has been post-trained and released under a different publisher’s family name. That matters for enterprise due diligence, incident response, and policy discussions that treat “origin” as a proxy for risk. Such persistence helps explain why a label that only identifies the final publisher and its country of origin may not tell the full story when it comes to understanding, assessing, managing, and mitigating risk.

A new publisher’s name doesn’t erase what came before it. Prior research has shown that specific inherited traits (such as a backdoor, bias, or specific behavior) can survive post-training and re-release. This study shows that the underlying relationship to an upstream model can remain statistically detectable after the name on the model card has changed.

Read the full report for detailed methodology and results here: Models Don’t Have Passports.

**Why this matters **

This research adds specific, testable findings to an AI governance and security debate that has mostly been conducted in generalities.

For enterprises: treat publisher identity as one piece of the puzzle. Model due diligence should include technical lineage, training dependencies, behavior analysis, and operational control. Just as you would audit software for its underlying dependencies, it is important to verify the “DNA” of the AI models you deploy.For regulators: vendor origin may be part of the equation for government risk assessments and associated policy decisions but it is insufficient on its own. Regulators need a better understanding of a model’s upstream dependencies to build a true picture regarding vulnerabilities, biases and restrictions stemming from model lineage.For industry: lineage disclosure should be routine, not optional. Transparency is the best way for users to understand upstream dependencies before they integrate a model into their tech stack.

**The bottom line: **technical fingerprints provide evidence for further inquiry, not automatic proof of risk. But they’re a real check on labels that have started doing more work in security and policy conversations than they were ever built to represent. As AI supply chains get more interconnected, the industry needs a stronger standard of verifiable technical transparency, not just better-branded labels.

**A model’s publisher is not its entire history **

Security teams have already worked through a version of this problem with software. Knowing which company distributes an application says little about the libraries, services, and upstream dependencies compiled into it, which is why supply chain security exists as its own discipline rather than something vendor trust can substitute for.

AI models raise the same issue with an added wrinkle: the dependencies aren’t listed in a manifest file, they’re embedded in the learned weights themselves.

A model can be fine-tuned from an existing checkpoint rather than trained from scratch, distilled from a more capable teacher, trained on data that another model generated, or merged, quantized, and pruned before release. These processes can preserve characteristics of upstream systems even after a model’s publisher, name, and model card change.

Publisher identity remains relevant, but it answers a different question than technical lineage does. Who operates a service, receives prompts, controls updates, or is subject to a government’s legal process is a question about hosting and operational control. Whether a model inherits vulnerabilities, biases, or restrictions from an upstream system is a question about weights, training dependencies, and behavior. One category of evidence cannot substitute for the other.

**Testing a documented cross-family relationship **

To examine this issue, we studied models released in NVIDIA’s Nemotron family and compared them with Alibaba’s Qwen family. This is a particularly useful case because NVIDIA publicly documents that some Nemotron models use Qwen base weights, while other Nemotron models use NVIDIA-developed or Meta Llama base weights instead.

That documentation gives us a known ordering to test. If technical lineage remains detectable, Nemotron models built from Qwen base weights should appear more Qwen-like than Nemotron models built from NVIDIA or Llama base weights.

We used two independently developed methods that look at different surfaces of a model. Cisco’s Model Provenance Kit examines the released model artifact directly, using weight-derived identity signals to place models into similarity neighborhoods based on properties of their learned parameters. VAIL approaches the question from the outside, fingerprinting how models behave during inference and grouping models with similar behavioral patterns.

The methods are not interchangeable, and their raw scores are not directly comparable. That is also what makes agreement between these methods useful: one examines the artifact, while the other examines inference behavior. We tested whether both recover the same directional relationship. They did.

**What the data showed **

Both methods found that Qwen appeared more frequently among the nearest neighbors of Qwen-based Nemotron models than its share of each catalog would suggest.

In Cisco’s 184-model catalog, Qwen models represented 12.0% of the overall comparison pool, but 20.9% of the closest neighbors of Nemotron models with documented Qwen ancestry, or 1.74 times the base rate. VAIL’s larger 1,159-model catalog told the same story: Qwen represented 14.9% of the catalog but 28.1% of the nearest neighbors of Qwen-based Nemotron models, or 1.89 times the base rate.

*Figure 1. Qwen’s share of Nemotron–Qwen nearest neighbors versus its share of each full catalog, across both fingerprinting methods. *

Both methods also recovered the documented ordering of the Qwen-, NVIDIA-, and Llama-based Nemotron groups: models built on Qwen weights had the highest share of Qwen neighbors, models built on NVIDIA weights came next, and models built on Llama weights had the lowest share of all.

We also examined comparison families with no documented direct Qwen-weight relationship. Google and Meta models were compared against Qwen, NVIDIA, and each other. This analysis did not show the same consistent enrichment: Qwen was not overrepresented in Google model neighborhoods relative to the VAIL or MPK base rates, while the Meta comparisons were depleted or statistically compatible with their base rates. The controls do not prove that coincidence is impossible; they show that Qwen’s prevalence in the catalogs does not, by itself, produce the Nemotron–Qwen pattern.

Figure 2. Base-rate-normalized neighborhood enrichment under both methods; horizontal lines show 95% confidence intervals. The comparison families do not show the same consistent enrichment, making catalog prevalence an unlikely sole explanation for the Nemotron–Qwen result.

That convergence is the real finding here: two independently built methods, each reading a different surface of the model, detected the same cross-family pattern consistent with NVIDIA’s published lineage documentation.

This does not independently prove every model’s complete training history. Similarity is evidence, not causal proof. Behavioral resemblance can result from shared data, teacher models, training objectives, tokenizers, or other influences in addition to inherited weights. Under the Cisco Model Provenance Constitution, a formal provenance claim requires evidence of a causal weight-derivation relationship.

The narrower conclusion is still consequential: post-training and a new publisher name do not necessarily erase detectable relationships to an upstream model family.

**Why this matters for enterprise security **

Security teams already know that dependencies and supply chains matter; they may run scans, review bills of materials, conduct risk assessments. Model lineage creates a comparable investigative problem.

Before deployment, organizations can ask vendors for evidence about base checkpoints, derivation methods, major training datasets, distillation teachers, reward models, licenses, and post-release access. When those records are incomplete or inconsistent, artifact and behavioral fingerprints can provide additional signals for deeper review—particularly for sensitive deployments. They are not proof, but they can help prioritize investigation.

The same logic applies after an incident. If an upstream model is later found to contain a backdoor, systematic bias, or exploitable behavior, organizations would need to know which downstream models may warrant review. Publisher-based inventories may miss relationships that cross company or model-family boundaries.

No single signal answers every security question. Weight-level evidence informs artifact lineage, and behavioral evidence can show that related patterns persist in deployment. Hosting architecture, network access, telemetry, and update authority determine whether an external party maintains operational control. A mature risk assessment process keeps these questions separate before considering them holistically.

**Country of origin is an insufficient risk proxy **

Country-of-origin discussions often compress several policy objectives into one geographic label. Cisco and VAIL research does not determine which restrictions governments or organizations should adopt, but it does make clear that the underlying policy or regulatory objectives require different evidence.

A rule designed to address remote access, data exposure, service interruption, or legal compulsion could examine who hosts the model, who receives data, and who can update or disable the system. A rule designed to address inherited vulnerabilities or behavioral traits could look more closely at model weights, training dependencies, artifact analysis, and behavioral evaluation. Sanctions, procurement preferences, and industrial policy may use organizational or jurisdictional criteria directly, but that is analytically different from concluding that a model is technically independent.

A “country-of-origin” label can produce both blind spots and false equivalences. It may miss a model released by an organization in an allowed jurisdiction that directly descends from restricted weights or depends materially on restricted training artifacts. In this case, the same country label can present materially different risk profiles.

These distinctions are compatible with existing governance approaches. NIST’s generative AI profile (NIST AI 600-1) treats models and datasets as part of the AI value chain, while the European Union AI Act imposes documentation duties on general-purpose model providers. The open question is how lineage-specific records and proportionate technical verification could fit within those broader regimes.

**What better lineage disclosure could add **

This case study is possible because NVIDIA documented the base-weight ancestry of Nemotron models examined. Comparable disclosure is not yet consistent across the open-weight ecosystem, which is why technical detection can complement (not duplicate) published records.

Model cards and datasheets have established a norm of publishing information about how models were built. A model bill of materials could extend responsible AI adoption by recording base checkpoints, derivation methods, major datasets, synthetic-data generators, teacher and reward models, licenses, and entities with post-deployment access. Technical fingerprints can corroborate those disclosures or identify relationships that may warrant further review. The industry doesn’t need to wait for regulation to make that routine.

**Augmenting country labels with supply chain visibility **

Open-weight AI gives organizations more choice and control over deployment, while making the ecosystem harder to untangle. Models move across repositories, organizations, and jurisdictions and are adapted, distilled, merged, quantized, and renamed along the way.

A fingerprint match is not proof of causal lineage, and technical lineage does not answer who hosts a deployment or controls its updates. This research doesn’t determine which models should face which restrictions, doesn’t reconstruct a complete training history, and says nothing about who currently hosts a given deployment or holds update authority over it. Those remain separate questions requiring separate evidence. It establishes a narrower point: a new publisher label does not necessarily erase detectable ties to an upstream model family, and those ties can inform enterprise review, policy analysis, and industry disclosure.

Governance needs language and evidence that reflect this reality. Publisher domicile and labels like “U.S.” or “Chinese” models may be relevant facts, but they cannot capture a model’s technical lineage on their own.

Models do not have passports. They have supply chains.

Read the full study, including the complete methodology and per-model results here.

── more in #ai-safety 4 stories · sorted by recency
── more on @cisco 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/the-u-s-vs-china-ai-…] indexed:0 read:11min 2026-08-27 ·