Mitigating AI Supply Chain Risk Through Model Origin Visibility
CISO Circle Lauren Stemler Security Researcher at Cisco Talos, Alie Fordyce Product Manager at CiscoWith more than two million AI models now available on platforms like Hugging Face, most organizations can tell you which models they use. Far fewer can tell you where those models came from, and that gap is becoming a governance liability.
Organizations and policymakers increasingly treat model origin (i.e., who built it, on what data it was trained, and from what upstream sources) as a distinct risk category. But regulatory attention alone won’t solve the practical problem; AI models routinely obscure their lineage through routine development practices. And the consequences run the gamut from operational inefficiencies and security risks to murky auditing trails and compliance violations. Closing that gap requires more than awareness; it requires systematic provenance tracking embedded into the same workflows organizations already use to manage AI deployment.
This piece examines why that happens, what it means for governance, and how visibility into provenance can be translated into enforceable policy.
Solving the hidden lineage problem
Unlike traditional software, where component origins are typically documented in dependency manifests, AI models lose their lineage trail through the very practices that make the open-source ecosystem productive: fine-tuning a model for a specific task, distilling it into a smaller version, or merging it with other components and releasing it under a new name. Not because it is deliberately hidden, but because of how the open-source AI ecosystem works.
The way this happens is surprisingly ordinary: a team selects a high-performing base model and fine-tunes it for a specific task. Another team distills that model into a smaller, faster version. A third organization combines it with other components, relabels it, and deploys it under a permissive open-source license such as MIT or Apache 2.0. The ecosystem encourages and supports each of these steps. Yet each step distances the resulting model from its original lineage.
This creates a practical challenge: developers may unknowingly build upon models based on their performance characteristics without visibility into their full lineage. For organizations with governance requirements around model origins, this hidden lineage creates compliance uncertainty and direct security risk.
Identifying new categories of governance risk
Policymakers have begun treating model origin as a distinct governance consideration. The rapid proliferation of open-source AI across global development ecosystems made clear that model origin carries supply chain and compliance implications that standard procurement and security reviews were not designed to catch. Two frameworks illustrate the direction regulation could be heading:
In the United States, the Pentagon's Supply Chain Risk Management (SCRM) Taxonomy identifies "Foreign Ownership, Control or Influence (FOCI) Risk" as a category requiring specific attention from organizations in defense and regulated sectors. And, most recently, the General Services Administration (GSA) proposed a new AI clause (in draft form as of March 2026) to be included in government-wide contracts with GSA, requiring all AI be developed in the U.S. while banning any non-U.S. AI components.
Bipartisan legislative efforts have also increasingly sought to establish clearer guidelines for how agencies evaluate AI systems based on their origins. For example, the National Defense Authorization Act for Fiscal Year 2026 explicitly prohibits the use of DeepSeek models on intelligence community systems. The EU AI Act requires transparency about training data, model architecture, and origins for certain categories of AI systems, making provenance a compliance requirement, not just a best practice.
These frameworks signal a structural shift in AI governance: origin is no longer something organizations can simply document after the fact. Instead, governments and legislative bodies recognize it as an input to procurement decisions, deployment approvals, and ongoing risk assessments.
Turning visibility into enforceable policy
Understanding provenance allows governance and organizations to better mitigate security risks. But the real value emerges when organizations can translate visibility into enforceable policy.
Consider an organization operating in a regulated sector with requirements around supply chain risk management. Their policy might specify that AI models used in production systems must document provenance, with models originating from certain jurisdictions requiring additional security review before deployment.
Without origin visibility, this policy is unenforceable; the organization cannot systematically identify which models require additional review. When provenance data is available, however, those same policies become operational. Provenance tooling automatically flags models based on geography or manufacturer, routes them through appropriate review workflows, and documents them for audit purposes.
Origin visibility allows the same policy to become operational, with provenance enabling policy definition: Organizations articulate their own rules based on their risk tolerance, regulatory requirements, and operational context. These might involve geographic considerations, licensing terms, origins of training data, security assessments, or lineage depth.
- Automated detection: Provenance tooling surfaces the data needed to evaluate models against policies, including origin information that may not be apparent from a model's current presentation.
- Workflow routing: Organizations can flag models against policy and automatically route them to the appropriate review process rather than requiring analysts to manually inspect every deployment.
- Audit documentation: Teams record decisions creating a compliance trail required by regulators and internal stakeholders.
Transforming visibility into policy does not embed prescriptive judgements about which models organizations should or should not use. Different organizations operate under different requirements. A defense contractor may have foreign ownership, control, or influence (FOCI)-related obligations that a startup does not. A European enterprise may face different regulatory considerations than one based in Asia. A company in financial services may prioritize licensing clarity over geographic origin.
An organization that reviews requirements and concludes that model origin lacks materiality to their risk profile still benefits from the visibility that allowed them to make that determination intentionally.
Establishing an AI governance action layer
For security and compliance teams looking to establish origin visibility in their AI governance programs, three starting points are worth prioritizing:
- Inventory your deployed models. Some organizations don't have a complete picture of which models are running in production, let alone where those models came from. A model inventory is the prerequisite for everything else. This means cataloguing not just model names and versions, but source repositories, upstream base models where known, deployment locations, and the business functions they support.
- Assess your policy requirements. Identify which regulatory frameworks, contractual obligations, or internal risk standards reference model provenance, and determine whether those requirements are currently enforceable given your visibility posture.
- Evaluate provenance tooling. Technical similarity analysis, model lineage tracking systems, and AI supply chain provenance platforms can surface relationships and inherited dependencies that are not apparent through standard model documentation alone. Organizations should evaluate these tools against their specific operational and compliance requirements.
AI supply chain remains global, dynamic, and deliberately composable. Models flow across borders, through development pipelines, and into production systems in ways that can obscure their origins, not due to deliberate deception, but through irregularities in routine practice. Organizations that build origin visibility into their governance programs now will be better positioned to meet the growing list of AI compliance requirements that already exist, are currently emerging, and those that are still ahead.
To learn more about the evolution of AI provenance, please subscribe to the Perspectives by Splunk monthly newsletter.