On 30 July 2026, Cisco published something enterprise AI has been missing: a public lookup for the question "where did this model actually come from?". It is called the AI Supply Chain Provenance Explorer, it currently holds nearly 900 open models, and it stands on two things Cisco shipped three months earlier — an open-source toolkit that fingerprints models at the weight level, and a written standard for when two models count as being in a derivation relationship. This article reads the three primary Cisco documents, quotes the load-bearing parts verbatim, and maps them onto a practical question for smaller companies running AI in-house: when you pull an open model onto your own servers, what are you actually bringing in? Figures checked on 31 July 2026.
TL;DR
- What happened: on 30 July 2026 Cisco launched the AI Supply Chain Provenance Explorer — a free public database with "almost 900 open models catalogued to date".
- What it answers: per model, the distribution source, the publishing organisation and its headquarters, lineage to prior models, licence restrictions, and the results of a security scan of the model repository.
- Why it exists: Cisco states plainly that provenance "cannot rely on naming conventions or self-reported metadata alone".
- The technical base: Model Provenance Kit (30 April 2026, Apache 2.0) matches models at the weight level; on a 111-pair benchmark, only 4 pairs were misclassified.
- For companies in Vietnam: this is a check to run before an open model enters an internal system — the same logic as the traceability duties in Personal Data Protection Law No. 91/2025/QH15, in force since 01/01/2026.
- nearly 900 open models — size of the AI Supply Chain Provenance Explorer catalogue at launch (Cisco, 30 July 2026).
- ~150 base models · 45+ families · 20+ publishers — the fingerprint database shipped with Model Provenance Kit, spanning 135M to 70B+ parameters (Cisco, 30 April 2026).
- 4 of 111 pairs wrong — misclassifications on the 111-pair benchmark at a 0.70 threshold (Cisco, 30 April 2026).
- more than 2 million public models — size of the Hugging Face Hub as of end-2025 (Hugging Face).
- 01/01/2026 — date Personal Data Protection Law No. 91/2025/QH15 took effect in Vietnam (Ministry of Public Security).
What did Cisco actually open?
Cisco opened a public lookup that pulls into one place the facts you previously had to gather from scattered sources: who published this open model, where they are based, what it was derived from, what the licence restricts, and whether its repository has known security findings.
In the launch post of 30 July 2026, the authors — Amy Chang (Head of AI Threat Intelligence and Security Research), Ankit Garg (AI Researcher) and Sanket Mendapara (Security Research Engineer) — frame the problem in one sentence: "The harder question begins after download: when you bring a model into your environment, what exactly are you bringing in?"
The tool sits at provenance.aidefense.cisco.com, is free, and needs no installation. The post describes it as follows: "With almost 900 open models catalogued to date, the Provenance Explorer brings model details, provider context, provenance, security findings, licensing information, and usage restrictions into one place." Translated into procurement language, those five buckets are the five questions any board asks before signing off on a technology item: what is it, who sells it, where did it come from, what does the contract bind us to, and has anyone checked it is safe.
The most interesting detail is in the lineage field. Cisco is explicit that it does not take the uploader's word for it: "Rather than relying solely on self-reported lineages, we ground model relationships in similarity scores powered by Cisco Model Provenance Kit static fingerprinting and Project VAIL run-time behavioral fingerprinting." Relationships are anchored to measured similarity, not to a line of text in a model card. The security section is specific down to the scanner used — "ClamAV-based scanning of model repository files" — together with the number of files scanned and the vulnerabilities reported.
Why "the model card says so" is no longer enough
Because in open repositories a model can be fine-tuned, distilled, merged, quantised, repackaged and re-released under a different name many times over — and at each step the note about where it came from can be shortened, mislabelled, or deliberately removed.
Cisco puts the situation in one line in the launch post: "Models are fine-tuned, distilled, merged, quantized, re-released, and repackaged, often many times over." The scale of the problem comes from the size of the open ecosystem. According to Hugging Face's state-of-open-source report: "In 2025, Hugging Face grew to 13 million users, more than 2 million public models, and over 500,000 public datasets." Over two million public models, most of whose lineage claims nobody has verified.
In the Model Provenance Kit introduction of 30 April 2026, Cisco is blunter: "Documentation on open model repositories can be faked, and important details in the metadata can be removed or changed." And: "a model card can claim to be 'trained from scratch,' but it may actually be a modified copy of another model. Without technical verification of provenance, organizations are trusting claims that no one has validated." Cisco cites a real case as illustration — Cursor's Composer 2, which in Cisco's wording was "partly built on Kimi 2.5" — to show how tangled today's model supply chain is across proprietary systems, open models and third-party components.
What makes this technically hard is that modern model families share identical scaffolding. Cisco lists it out: "Models from Meta, Alibaba, DeepSeek, and Mistral use the same building blocks such as grouped-query attention, rotary positional embeddings, and Root Mean Square Normalization (RMSNorm). A config file can describe the architecture but it cannot tell whether the weights were copied from another model or trained independently." Read a config file and every model looks alike — and that resemblance says nothing about the real relationship.
| Risk category | How Cisco describes it | How it shows up in a small company |
|---|---|---|
| Security | A model may already be poisoned or carry vulnerabilities; "Without provenance, organizations have no easy way to trace an incident back to its root cause" | The internal assistant answers off-target and nobody can tell whether it is the prompt, the ingested documents, or the model itself |
| Compliance | The EU AI Act "mandates documentation of training data, characteristics of training methodology, and risk assessments for 'high-risk systems'" | You cannot answer a large customer's vendor-assessment questionnaire |
| Licensing and legal | A model may turn out to be a derivative of one with restrictive licensing — restrictions by jurisdiction, by company size, or by prohibited use case | Commercial use of a model whose upstream licence forbids it, discovered after it is already in production |
| Incident response | Without lineage you cannot tell whether the fault sits in the deployed model, its parent, or the fine-tuning step | The same incident recurs because the fix was applied in the wrong place |
A "constitution" for the word derived: what counts and what does not
Before building a measuring tool, Cisco had to fix a definition — and the one they chose is deliberately narrow: two models are in a derivation relationship only when a causal chain at the weight level connects them, not when they merely share an architecture, a training corpus, a tokenizer, or a benchmark score.
The document is called the Model Provenance Constitution, published on the same day, 30 April 2026. The introductory post opens with exactly the end user's question: "When it comes to AI models, one of the hardest questions to answer is deceptively simple: where did this model actually come from?" The problem, Cisco says, is that the industry has no consistent answer: "The same pair of models can be labeled as 'related' by one reviewed and 'independent' by another, with both citing defensible reasoning."
The definition itself is tight: "the verifiable derivation history of a model's trained weights. Two models share provenance if, and only if, a causal chain of weight derivation connects them, whether directly, indirectly through distillation, or mechanically through a non-training transformation like quantization." The exclusion list is the part worth reading, because it is precisely the set of traps a non-specialist walks into.
| Case | Cisco's example | Why it does not count |
|---|---|---|
| Independent reproduction | Llama-2 vs Open LLaMA — same architecture and tokenizer, trained from scratch | No chain of weight derivation |
| Same family, different size | Llama-2-7B vs Llama-2-13B | Same house, but neither was built from the other |
| Same family, different corpus | T5 vs MT5 — shared name root, separate from-scratch training | A name is not evidence |
| Shared tokenizer | StableLM and Pythia both use the GPT-NeoX tokenizer | "a tokenizer is a tool, not a weight" |
| Shared random seed | Independent runs under a shared seed | A shared seed does not constitute shared weights |
| Architectural convergence | Different teams independently arriving at similar designs | Similar design, unrelated origin |
| Dimensional coincidence | Two models that happen to share the same size or shape | Neither was built from the other |
| Shared training objective | Same training objective | Sharing an objective does not link weights |
Cisco also states a tie-breaking rule worth borrowing for any internal compliance policy: under ambiguity, default to labelling the pair as independent. The reasoning is given directly: "A false positive in provenance carries immediate consequences: a licensing accusation, an IP claim, a supply-chain incident notification." Getting it wrong in the "related" direction has immediate legal consequences; getting it wrong the other way is still caught by manual review and audit. That is a conservative design a small organisation should copy when writing its own rules.
How well it measures: 111 model pairs, 4 wrong
Model Provenance Kit reads the learned weights rather than the description, extracts five independent signals and combines them into a single score; on Cisco's own 111-pair benchmark, only 4 pairs were misclassified.
The method runs in two tiers. Tier one is a fast screen on architecture metadata, before any weights are loaded. When metadata is ambiguous — which is common, because families share scaffolding — the pipeline drops to tier two and analyses the weights themselves. The code is on GitHub under Apache 2.0, needs Python 3.12 or newer, and streams models over 20 GB to limit memory use.
| Signal | What it measures | Why it is hard to fake |
|---|---|---|
| EAS — Embedding Anchor Similarity | Geometric relationships between token embeddings | "This structure is unique to a training run and survives fine-tuning" |
| END — Embedding Norm Distribution | Distribution of embedding magnitudes | Encodes word-frequency patterns learned during training |
| NLF — Norm Layer Fingerprint | The small normalization layers | "they remain stable across fine-tuning" |
| LEP — Layer Energy Profile | Energy curves across network depth | Different training runs produce different distributions even with identical architecture |
| WVC — Weight-Value Cosine | Direct comparison of weight values in corresponding layers | Independently trained models show essentially zero correlation |
| Benchmark result over 111 pairs (55 similar, 56 dissimilar): standard derivatives (fine-tuning, quantization, alignment) — 100% recall; cross-organization derivatives — 100% recall; same-tokenizer traps — 100% specificity; independent reproductions — correctly identified as unrelated. Only 4 of 111 pairs wrong, all involving extreme architectural transformations. | ||
Note: this benchmark was built and evaluated by Cisco itself; it is not an independent assessment. We quote the figures verbatim and cite the source so you can check them, and draw no further conclusions about accuracy in other environments.
Cisco is also open about the limits. Two tokenizer signals are computed but do not feed the verdict, because "Many independently trained models share tokenizers... and including them would create false positives". And the four wrong pairs all involve heavy deformation — distilling a 12-layer model down to 4 layers while halving the hidden dimensions, or rebuilding an entire vocabulary for domain-specific continued pre-training. Cisco calls these "fundamental limits of pairwise weight comparison", not implementation bugs. In other words: the tool is strong against ordinary transformations, and weakest exactly where someone deliberately transforms a model enough to erase the trail.
What companies in Vietnam should do with this
The action here is not to buy another tool, but to add one step to a process you already have: before an open model is loaded into an internal system, check its provenance and licence, then keep the evidence that you checked.
The step is cheap. The Explorer is free in a browser; Model Provenance Kit is Apache 2.0 and runs on your own engineer's machine. What is expensive is skipping it: a model chosen for its benchmark score and "open" licence turns out to be a derivative of one with restrictive terms, discovered once it is already inside a product sold to customers.
This connects directly to local legal duties. According to the Ministry of Public Security portal: "Ngày 01/01/2026, Luật Bảo vệ dữ liệu cá nhân (Luật số 91/2025/QH15) chính thức có hiệu lực thi hành. Trong đó, đã xác lập rõ các quyền dữ liệu cơ bản của công dân, bao gồm quyền được biết, quyền đồng ý, quyền truy cập, chỉnh sửa và yêu cầu xóa dữ liệu." — the law took effect on 1 January 2026 and establishes citizens' rights to be informed, to consent, and to access, correct and request deletion of their data. The law is about data rather than models, but the mechanism is the same family: you cannot answer "where is this data and what has it passed through" if you cannot answer "what is processing it, and where did that come from". We unpacked those duties in our piece on Decree 142/2026 on AI, and described how to build a security layer around an internal AI system in a security architecture for in-house AI.
In fairness, open models remain the right call for most companies that want to keep data in-house — the point is to choose with evidence instead of choosing off a leaderboard. We compared selection criteria in building in-house AI: choosing a model, looked at one specific open model in GLM-5.2, and broke down the true cost of self-hosting in the real cost of running an LLM on-premise. This article only adds one line to all three checklists: origin.
| Step | What to do | Cost (estimate) |
|---|---|---|
| 1. Look it up | Find the model in the Provenance Explorer; read publisher, headquarters, lineage, licence | Minutes, free |
| 2. Read the licence terms | Check the common restrictions Cisco lists: attribution requirements, non-commercial terms, geographic restrictions, modification constraints, prohibited use cases | Half a day; may need legal review |
| 3. Cross-check unfamiliar models | If the model is not catalogued or its lineage is unclear, run Model Provenance Kit in scan mode | One engineering session; needs disk space for weights |
| 4. Keep the evidence | Save the lookup result with the date checked, attached to the system record — so you can answer a customer or a regulator later | Near zero, if done at the time |
| 5. Re-check on upgrade | Repeat steps 1–4 whenever you move to a new version or a different model, because lineage may differ | Repeats on your upgrade cycle |
A downloaded open model is not a file but a link in a supply chain — and until 30 July 2026, most organisations were accepting that link with no way to verify where it actually came from.
Frequently asked questions
Is the Provenance Explorer free, or only for Cisco customers?
The launch post of 30 July 2026 describes it as "a public resource" at provenance.aidefense.cisco.com. Cisco attaches a clear disclaimer: the data is "provided 'as-is' without warranties of any kind", Cisco does not guarantee the information is current or accurate, and "Users are solely responsible for conducting their own independent assessment". So it is usable immediately, but it is a reference, not a certification.
What if the model we use is not among those nearly 900?
The catalogue holds nearly 900 models while Hugging Face hosts more than 2 million public ones, so not finding yours is normal. Two paths remain: run Model Provenance Kit in scan mode against its fingerprint database of roughly 150 base models, or accept that you are trusting the uploader's claim and record that fact in your risk register.
If two models share an architecture, is one a copy of the other?
Not necessarily, and this is exactly the trap the Model Provenance Constitution was written to avoid. Shared architecture, shared training data, shared tokenizer and shared benchmark performance all fail to count as derivation. Only a causal chain at the weight level counts. Cisco's example: Llama-2 and Open LLaMA share both architecture and tokenizer but were trained independently.
Does this detect models with malware in them?
Those are two different jobs. The Explorer includes security assessments based on ClamAV scanning of the model repository files, reporting the number of files scanned and the vulnerabilities found — but its core purpose is provenance, not malware detection. Its biggest value is in incident response: when one model is compromised, lineage tells you which other models in your stack are affected too.
Does a 50-person company need this, or only large groups?
It does, and at that size it is fastest, because the inventory of models in use is usually just a handful. The first four steps in Table 4 fit into a single session and cost almost nothing. The lasting value is in keeping the evidence with the date checked, so that a year later you can still answer a large customer's vendor-assessment questionnaire.
Review the AI models running inside your company
Namtech helps you inventory the AI models and components in use, check their provenance and licence obligations, and design an approval step before any new model enters an internal system.
Book a free consultationNote: compiled from public sources, checked on 31 July 2026. Quoted passages are verbatim from Cisco's technical blog, Hugging Face's report and the Vietnamese Ministry of Public Security portal. Benchmark results are self-published by Cisco and have not been independently verified. Table 4 is Namtech's recommendation. For information only; not legal advice.
- Cisco Blogs — "AI Supply Chain Provenance Explorer for Responsible AI Governance" (Amy Chang, Ankit Garg, Sanket Mendapara, 30 July 2026): "almost 900 open models catalogued to date"; "The harder question begins after download: when you bring a model into your environment, what exactly are you bringing in?"; "provenance cannot rely on naming conventions or self-reported metadata alone"
- Cisco Blogs — "Introducing Model Provenance Kit: Know Where Your AI Models Come From" (30 April 2026): "When organizations don't know where their AI models actually come from, they're flying blind on security, compliance, and liability"; 111-pair benchmark at a 0.70 threshold; "Only 4 out of 111 pairs were misclassified"
- Cisco Blogs — "Defining Model Provenance: A Constitution for AI Supply Chain Safety and Security" (30 April 2026): "the verifiable derivation history of a model's trained weights"; exclusion list (independent reproduction, same-family different-size, shared vocabulary without weight transfer…)
- GitHub — cisco-ai-defense/model-provenance-kit (Apache 2.0, Python 3.12+): "The bundled reference database contains fingerprints for ~150 base models spanning 45+ model families from 20+ publishers, ranging from 135M to 70B+ parameters"
- Cisco AI Supply Chain Provenance Explorer — the public lookup tool (accessed 31 July 2026, HTTP 200)
- Hugging Face — state of open source report: "In 2025, Hugging Face grew to 13 million users, more than 2 million public models, and over 500,000 public datasets"
- Help Net Security — "Cisco releases open-source toolkit for verifying AI model lineage" (30 April 2026): "Determines whether two transformer models share a common origin by examining architecture metadata, tokenizer structure, and the learned weights themselves"
- Ministry of Public Security (Vietnam) — "Ngày 01/01/2026, Luật Bảo vệ dữ liệu cá nhân (Luật số 91/2025/QH15) chính thức có hiệu lực thi hành"