AI Model Supply-Chain Poisoning & Provenance: An Evidence-Led Research Review

Executive Summary

AI systems often contain components and dependencies that were not produced by the team deploying them. A commercial model service may rely on an upstream developer, an application integrator, third-party libraries, changing datasets and platform infrastructure. Enterprises need to know what they received, what changed and which evidence supports the decision to use it. This report examines that problem through model-supply-chain poisoning and provenance, not through assumptions that any particular organization has suffered an attack.

NIST's 2025 adversarial machine learning taxonomy identifies poisoning and related attack families across model and data lifecycles. [1] OWASP's 2025 large language model risk guide separately identifies supply-chain and data/model poisoning issues. [2] Both are valuable classifications, not prevalence studies. Neither justifies reporting a percentage of compromised enterprise AI models without a separate measured dataset.

This is a secondary-research synthesis. It is not a survey, technical penetration test, benchmark of commercial vendors or disclosure of a customer incident. Findings are paired with explicit evidence boundaries and operational next steps. The report contributes seven thematic findings, an eight-stage decision framework, eleven assessment domains and a 12-month operating sequence.

The primary thesis is that origin evidence must be specific enough to change a decision. A document that says “the supplier follows best practices” is not a substitute for a versioned release record, just as a software signature is not a substitute for model-behavior evaluation. The right end state is not impossible completeness. It is an explainable acceptance decision backed by records, uncertainties, accountable owners and a response route.

Research Methodology and Source Selection

The Research Desk examined authoritative public standards, threat classifications, technical schema documentation and security development frameworks available as of October 21, 2026. Priority went to direct publisher materials that state what a particular framework or field can support. Sources were included when their scope could be identified without relying on marketing interpretation or an unreplicated third-party statistic.

SLSA version 1.2 supplies a current schema for considering artifact provenance and verification in software pipelines. [6] The methodology follows four steps. First, identify the risk claim being considered. Second, locate a source that directly explains that concept. Third, determine whether the source describes a possible technique, a technical capability, a voluntary practice or observed deployment evidence. Fourth, document the conclusion at the narrowest defensible level. For example, the existence of a poisoning technique supports testing for that scenario; it does not establish a company's probability of being attacked.

This report uses NIST AI 100-2e2025 as a taxonomy; the OWASP 2025 guide as an application risk classification; CycloneDX specification material as a data-structure reference; and NIST secure development guidance as a control framework. [1] [2] [3] [4] CTI Research Desk interpretation is labeled as such. Company-owned GTM content and services are treated as CTI descriptions, not independently verified campaign-outcome statistics.

Source recency was considered alongside authority and direct relevance. A newly released blog post was not preferred over a still-current final NIST publication when the latter more directly defined the claim. Similarly, a live technical specification can be current without a conventional news publication date. The research separates the publication date of a framework from the October 2026 date on which the source was inspected.

Search and selection were not conducted as a systematic academic literature review. The report therefore does not claim exhaustive coverage of peer-reviewed work or a statistically representative account of AI supply-chain incidents. It is an applied decision brief assembled from primary guidance and specifications. Where a control recommendation represents CTI interpretation rather than source text, it is identified as proposed practice.

Evidence Universe and Assessment Rules

The evidence universe includes model identity, ownership, model packaging, training and adaptation inputs, data rights, software dependencies, repository security, build and distribution history, evaluation methods, operations and acquisition controls. The framework addresses proprietary hosted systems and downloadable open-access models, recognizing that the buyer may receive different levels of information in each case.

Evidence Grade A means locally verified, version-specific documentation with retained test or verification records. Grade B means named publisher or supplier records whose content can be inspected, while acknowledging that they are self-reported. Grade C means independent standards, taxonomies or specifications that explain a risk or recommended practice but do not evaluate the target deployment. Grade D means hypotheses, estimates or operating assumptions developed by CTI; these can guide inquiry but must not be presented as measured facts.

One claim can legitimately require several evidence types. A signature could validate an artifact under specified trust conditions, a model card could explain intended use and a repeatable evaluation could support a narrow performance statement. None alone can establish the entire supply chain as trustworthy. These limitations are recorded to protect purchasing and release decisions from false certainty.

An assurance review can fail through apparent precision. A source might enumerate model attributes, and a completed inventory might contain many fields, but field count says little about whether the important facts can be verified. This research judges records by their relationship to a decision: does the record identify an object, document a process, support a reproducible check or name an accountable approver?

The same discipline applies to negative findings. The absence of a training dataset inventory is not evidence that someone poisoned the model. It is evidence that the reviewer cannot presently verify the data origin from that record. A well-written issue statement maintains that distinction and specifies the next question or compensating assurance rather than escalating every documentation gap into a confirmed security event.

Evidence Grades and Interpretive Boundaries

Terminology and Scope

Model artifact means the versioned file or hosted model identification used to deliver an AI capability. Provenance means information about origin, transformations, creation, modification or distribution. Training provenance refers more specifically to the data and processes that contributed to a model. Software or build provenance may trace a package to its inputs without accounting for a complete training corpus.

Data poisoning concerns malicious or unauthorized interference with training, fine-tuning or related data that affects later model behavior. Model poisoning concerns manipulation of the model artifact or its learned parameters. Retrieval-content manipulation can influence an application at use time and should not automatically be described as evidence of altered model weights. “Supply chain” includes the parties, code, packages, datasets and services that affect the final application.

The term “control evidence” refers to a concrete record that supports a review decision, such as a versioned inventory, verification log, documented supplier assessment, completed evaluation or approved exception. The term does not mean any record proves a system is perfectly safe. The report makes no claim to expose undisclosed vulnerabilities in named cybersecurity companies.

Finding 1. The Unit of Review Must Be the Actual Deployed Version

A general model brand does not identify which artifact or hosted revision a company is using. Model versioning, application packaging and update practices can cause different teams to run materially different configurations under a common service name. For security review, the first requirement is a stable mapping between a business process, an approved model identifier and the deployed environment.

In practice, that mapping can be tested by matching release records to running configurations, recording provider version behavior and identifying local adapters or sidecar components. If the provider controls updates invisibly, the review should document how that limitation is managed rather than inventing a fixed artifact hash.

The board-level consequence is accountability: the organization should be able to determine which business service could be affected if an artifact or supplier is withdrawn. The record is useful for response even when no poisoning or compromise has been found.

An enterprise inventory also needs to answer whether an AI system is delivered as a service, a packaged artifact or an embedded feature of a broader application. That delivery mode affects which records the enterprise can collect itself. A hosted provider may offer a contractual version guarantee or named release channel; a downloaded model may expose a file digest; an embedded feature may only expose product release notes.

The scope should capture shadow or experimental services only when the evidence supports their inclusion. An incomplete discovery effort should not be described as a complete enterprise inventory. Management should know which business units and environments were included and when the mapping was last checked.

Finding 2. Training Origin and Distribution Integrity Are Different Claims

A build or distribution attestation can help show how an artifact was packaged or released. It does not independently enumerate every example that influenced training. For many third-party models, the acquiring organization cannot reproduce the original training process, and some data may be protected by intellectual property or privacy constraints.

CycloneDX includes structured fields for AI models, datasets and related component metadata. [3] Such structure improves the ability to exchange a record, but the quality of the record depends on source completeness and validation. A document can be well formed while containing omitted or outdated supplier information.

Organizations therefore need a disclosure hierarchy: required information for high-impact use, acceptable alternatives when full lineage is unavailable, and explicit rejection conditions. The decision should never transform “supplier declined to disclose” into “verified clean training history.”

A subtle risk is the use of a single word, “provenance,” to cover unrelated forms of history. Build provenance answers how a software artifact was produced. Data provenance concerns sources and transformations. Model provenance can include training, adaptation, parameters and lineage of released versions. If a vendor provides only one type, the enterprise should preserve its value without presenting it as all three.

The reporting implication is straightforward. A supplier evidence schedule should indicate required fields, fields offered voluntarily, and fields unavailable under the service model. The decision register can link compensating evaluations or restrictions to those gaps. This gives the next review team an accurate starting point instead of a simplified compliance mark.

Finding 3. Poisoning Must Be Investigated at the Correct Lifecycle Stage

NIST documents attacks across the machine-learning lifecycle and distinguishes attacker objectives and capabilities. [1] For an enterprise buyer, this means different evidence is needed for a suspicious training dataset, an unexplained model file change or contaminated retrieval content. A single generic scanner cannot be assumed to cover all three.

For training and fine-tuning, a practical review looks for input provenance, data selection rules, anomalous updates and behavior changes against a versioned baseline. For model files, integrity and repository identity matter. For retrieval systems, update rights, source approval and content-change logs are central. Misleading answers should trigger investigation but not an unsupported declaration of adversarial poisoning.

The operating benefit is more accurate triage. By naming the stage, security teams can route the question to the people with relevant records rather than creating an enterprise-wide incident classification before verifying the facts.

When an unexpected output is reported, investigation should first preserve the request, context, model or service version, relevant retrieval results and timing. Those records can help establish whether the answer was influenced by a newly changed external source, an authorized configuration update, an ordinary statistical failure or possible malicious interference.

The risk taxonomy provides useful scenarios for testing, but test design still needs a plausible attacker pathway and defined access. A team without control over original training inputs should not claim to have performed a complete training-poisoning assessment. It may nonetheless evaluate the deployed application, supplier assurances and observable update behavior within a stated boundary.

Finding 4. Third-Party Software Remains Part of AI Assurance

An AI system still depends on conventional software. Packages, containers, loaders, orchestration services and plugins can introduce implementation risks unrelated to poisoned training examples. NIST SP 800-218 provides foundational secure software development practices for these components. [4] Its guidance does not replace AI-specific evidence requirements, but it should not be discarded simply because the application includes a model.

An engineering inventory should identify material libraries and services, ownership of each dependency, known vulnerability management routes and expected update behavior. A separate model inventory should capture model files, adapters and relevant data lineage. The two records need a shared service identifier so remediation can find affected deployments.

Security vendors can communicate more credibly by stating whether their product addresses packages, model artifacts, data-source integrity, runtime behavior or a defined combination. The phrase “full AI supply-chain security” should be reserved for a genuinely demonstrated scope, not inferred from category placement.

Traditional software hygiene includes dependency tracking, secure build practices and vulnerability response. AI supply-chain management extends that hygiene; it does not exempt teams from it. A vulnerable loader, excessive repository privilege or untracked container update can change risk even when the machine-learning model is identical. Conversely, a secure container cannot repair improper training consent or hidden behavioral manipulation.

This division of responsibilities is important for product comparison. Buyers should ask a tool provider to demonstrate the specific layer it monitors and disclose prerequisites for broader coverage. Integrations, account permissions and deployment modes can limit results. A proof-of-concept should check the buyer’s actual environment rather than extrapolate from a generic marketing diagram.

Finding 5. Model Documentation Is Necessary but Not Self-Authenticating

Model cards and supplier statements can make intended use, data context and limitations more accessible. They are especially useful when cross-functional reviewers must interpret specialized system details. However, the documents are as reliable as their authorship, version alignment and completeness.

A purchaser should verify that documentation pertains to the exact model or service version under review. Where a supplier provides only a broad foundation-model statement, the purchaser should distinguish that information from local deployment testing. The absence of disclosure may be an accepted commercial limitation, but acceptance must be owned and bounded.

The right review question is not simply whether documentation exists. It is whether the documentation answers the material question for this use case and whether there is a mechanism for receiving corrections or material-change notices.

A practical evaluation may combine a model card, provider security statement, dataset disclosure, license terms and local test result. The records may differ in format and authorship. The reviewer should not conceal those differences under a single approved-document checkbox. A supplier declaration is useful evidence of what the supplier says; its accuracy and completeness require separate consideration.

There is also a freshness issue. A model card prepared at initial publication may not reflect a later hosted revision or enterprise adaptation. The release owner should define which documents must be refreshed or reconfirmed after material changes and which can remain as historical references. This is a concrete governance improvement that does not require claims about observed attacker activity.

Finding 6. Control Evidence Must Survive Handoffs

A procurement questionnaire may contain useful supplier answers that never reach operations. Engineering may verify a release without giving risk management an interpretable record. A security team may complete an evaluation without linking it to the precise model now deployed. Each disconnect reduces the value of the original evidence.

An evidence register can connect those activities through a common service and version identifier. It should contain the claim, source, evidence type, check date, reviewer, applicable scope, known limitations and decision. Exception records should include an expiry or trigger for reconsideration. The register must be auditable but need not impose a single tool across all functions.

NIST secure development practices reinforce the importance of repeatable processes, records and responsible ownership. [4] The CTI operating recommendation is to preserve the link between evidence and an actual release decision, not to multiply documents for their own sake.

The lifecycle handoff may cross multiple approval systems. Procurement records supplier identity, engineering records software revisions, AI assurance records test cases and operations records deployment changes. Without a shared identifier, a technically valid artifact check may have no traceable connection to the running customer service. That is a failure of record linkage rather than necessarily a failure of cryptography or testing.

A practical solution is a minimum evidence envelope carried with each material release. It names the business service, supplier, model version, relevant data or adaptation change, verification performed, exceptions and release authorizer. Each function retains its detailed evidence in the system it already uses. The envelope is the shared index, not another repository of confidential information.

Finding 7. Buyer Education Should Follow Decision Rights

Cybersecurity buyers approach model provenance from different responsibilities. A CISO owns business risk and accountability. AI engineering owns integration details and evaluations. Supplier risk management owns diligence and contracting. Operations owns deployment continuity. Product managers decide which user outcomes the model is allowed to support. A single technical message rarely resolves every one of those questions.

CyberTech Intelligence describes research-led content programs designed around buyer questions and credible editorial production. [5] For security vendors, buyer intelligence can help prioritize the roles and questions emerging in account conversations. Managed demand generation can distribute role-specific educational assets; pipeline activation becomes appropriate when a buyer confirms a need and accepts a next action.

No supplied source quantifies the conversion rate of provenance content or proves a specific model risk is driving an account's purchase. The relationship between editorial engagement and opportunity creation must be measured during execution instead of assumed in the research findings.

For cyber vendors, the specific buying trigger may be a policy review, a supplier acquisition, a deployment expansion or an audit question. These triggers are hypotheses until account-level evidence supports them. A company building models is not automatically shopping for a provenance tool; a CISO speaking publicly about AI risk is not automatically in-market. CTI messaging should make that distinction explicit.

Programs can measure the proportion of responses that identify an actual use case, the count of qualified buying roles reached and whether a next meeting was mutually accepted. These are defined process metrics. They do not demonstrate pipeline outcomes until campaign activity and CRM records exist. The research and execution evidence should remain separate.

CyberTech Intelligence Research Framework: Eight Decisions

The CTI Model Trust-to-Decision Framework is a proposed operating synthesis. It is not a formal industry standard, certified methodology or demonstrated customer deployment. The purpose is to connect model lineage, technical controls and accountable decisions in a sequence executives can supervise.

1. Define use and consequences. Start with a real business service and its permissible model behavior.
2. Identify the artifact. Record supplier, revision and production mapping. 
3. Map inputs. Distinguish training, adaptation, retrieval and runtime data. 
4. Trace components. Capture code, libraries, model containers and hosted dependencies.
5. Verify what can be verified. Use appropriate signatures, hashes and test records with stated scope.
6. Decide exceptions. Record unknowns and who accepts them.
7. Exercise change response. Test notification, quarantine or rollback against a version.
8. Measure and govern. Revisit decisions on meaningful changes and retain proof of review.

The stages are not designed as a waterfall that prevents iterative engineering. A supplier disclosure may arrive after testing begins; a model adaptation may require renewed source checks; an incident may prompt reassessment of an earlier exception. The framework works when the organization can follow the evidence in both directions, from a deployed service back to origins and from a new supplier notice forward to affected applications.

At each stage, define an exit test. The input map passes when material categories are recorded or explicitly unknown. The verification stage passes only for the precise checks executed. The governance stage passes when an authorized person documents a decision. This guards against claiming readiness from the presence of documents without proof they were reviewed.

Eight-Decision Governance Architecture

Board-Level Evidence and Decision Metrics

A board should not be offered a fabricated market-wide percentage of poisoned models. It can instead receive internally measurable process indicators that relate directly to risk decisions. Define each denominator so progress is not inflated by excluding hard-to-review systems.

• Metric 1: percentage of in-scope production AI services with a named business and technical owner.
• Metric 2: percentage with a traceable model version or documented hosted-version limitation.
• Metric 3: percentage with a current material dependency record.
• Metric 4: percentage of material changes with version-specific evaluation evidence.
• Metric 5: percentage of critical exceptions with an assigned owner and review date.
• Metric 6: time required in a tabletop exercise to identify affected services after a simulated supplier withdrawal.
• Metric 7: share of supplier disclosures reviewed at the last material update.
• Metric 8: share of executive AI-risk claims that can be mapped to a concrete record. These are suggested management metrics, not figures measured by this report.

A numerator and denominator are essential. If an organization reports “90% model inventory coverage,” the board should know whether the denominator includes only centrally registered services or all in-scope production services, and when that universe was established. Similarly, a high exception freshness rate is meaningful only if the team actively discovers and records material exceptions.

Qualitative evidence can accompany these measures: a sample release package, a completed supplier question set, an example of a restricted deployment decision and a learning report from a rollback exercise. Those artifacts help executives see whether the metrics reflect responsible operation rather than administrative completion.

Management Metrics

Eleven-Domain Readiness Index

The proposed index grades eleven dimensions on a 0–4 evidence scale: business ownership, artifact identification, supplier disclosure, data origin, third-party software, model adaptation, version-specific evaluation, identity and data access, change approval, rollback readiness and buyer-facing evidence. Zero signifies no verified owner or record; one an informal description; two a controlled document; three current reviewed evidence; four an exercised or independently checked control within its specified scope.

A total of 44 represents the highest possible self-assessment score, not 44 units of safety. Scores must cite records and dates; an unknown field scores zero rather than receiving assumed credit. Readers should not compare scores across enterprises unless use-case scope, sampling and review methods are consistent, which this secondary-research report does not establish.

The most practical use is sequencing improvements. A company with strong model evaluation but unknown release ownership may first need to close the operational decision gap. Another with solid signing but poor dataset records may need more supplier dialogue. The index should identify the next defensible action, not produce a reassuring badge.

Twelve-Month Implementation Roadmap

Quarter 1, months 1–3: name the risk owner, choose a representative AI service and record business use, production model, supplier and known dependencies. Identify which records are locally verifiable and which remain supplier assertions. Establish a concise exception format and one rollback contact.

Quarter 2, months 4–6: extend the inventory to material use cases, test release evidence, align supplier diligence with approved deployment decisions and document data and adaptation lineage where available. Set minimum version-specific evaluation criteria for changes. Revisit purchasing language when source visibility is limited.

Quarter 3, months 7–9: run a controlled supplier withdrawal or integrity-failure exercise and review whether the organization could find affected deployments promptly. Test how exceptions are escalated across security, engineering, legal, procurement and the service owner. Make buyer-facing evidence packages concise and explicit about scope.

Quarter 4, months 10–12: integrate recurring review into change management, measure coverage using defined denominators and identify which records are most often missing. Update audience education and vendor conversations only when new buyer evidence supports a change in focus. Do not label program completion a guarantee that the next attack is preventable.

The roadmap is deliberately adaptive. Teams with few production AI services may complete initial mapping quickly but discover hard supplier limitations. Teams with numerous embedded AI features may need a staged discovery and ownership process before evaluating model details. Management should choose milestones based on consequence and controllability, not a requirement to score every low-impact use case equally.

Quarterly reviews should retain a concise change log. Which requirements changed? Which supplier provided new evidence? Which unknowns were accepted or retired? Which previous approvals no longer apply because the deployment changed? Recording these answers makes the program auditable and protects future reviewers from mistaking a historical sign-off for a current assurance statement.

Twelve-Month Sequence

Governance and Decision Rights

The business sponsor owns acceptable use and consequences; engineering owns deployment records; AI assurance owns defined tests; information security owns security risk review; supplier risk and legal own relevant disclosures and contract questions; operations owns safe suspension and restoration. A steering group may coordinate the evidence, but it should not replace the specific function authorized to make each decision.

A claim that a supplier is secure requires evidence beyond this report. A claim that a model was poisoned requires observations beyond a theoretical technique. A claim that a GTM program produced pipeline requires CRM and accepted-opportunity records. The same evidence discipline should govern technical, editorial and revenue narratives.

Implications for Cybersecurity Vendors and Buyer Intelligence

The market opportunity is an educational and qualification hypothesis, not a forecast demonstrated by the cited sources. Vendors serving model security, software supply chains, AI governance, cloud controls, data security or risk teams may use a provenance framework to make their specific relevance easier to understand.

CTI can structure buyer intelligence around questions such as “Which model version is deployed?”, “What disclosure is required from the supplier?” and “Which owner accepts an exception?” A managed demand-generation program can test which buyer roles engage with the education, distinguish superficial clicks from explicit replies and create structured content handoffs. Pipeline activation should require the buyer's stated need, qualified account fit and an agreed next step. [5]

Internal goals such as form fills, marketing-qualified leads, sales-accepted leads and meetings belong in a separate campaign forecast and live tracker. This research report contains no proprietary conversion dataset establishing any such outcomes. That separation improves both editorial credibility and downstream accountability.

Research Limitations

This report did not interview AI suppliers, inspect model binaries, observe production systems or measure enterprise incident rates. It does not certify any individual vendor, measure a product's ability to detect poisoning or establish that a particular account is buying. The primary sources include frameworks, general threat classifications, technical formats and CTI service descriptions, each with different evidentiary weight.

A technical specification can change after publication; a guidance document may be voluntary; a hosted AI provider may limit disclosure. All implementation examples are illustrative. Organizations should reconcile the suggestions with applicable laws, contracts, privacy obligations and their own risk tolerance. Source URLs reflect materials inspected for the October 21, 2026 editorial cut.

References and Source Boundaries

Numbered citations identify the primary source used for the nearby factual statement. A standard, threat taxonomy or supplier description does not establish the condition of any named enterprise or predict campaign results. Source review date: October 21, 2026.

1. NIST. AI 100-2e2025, Full Publication. Use in this asset: Authoritative adversarial ML taxonomy, including poisoning and model attack paths.  URL: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf
2. OWASP. Top 10 for LLM Applications, v2025, PDF. Use in this asset: Supply-chain and data/model-poisoning threat categories.  URL: https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf 
3. CycloneDX v1.7 JSON Specification. Use in this asset: Model and dataset objects, dependency references and BOM structure.  URL: https://cyclonedx.org/docs/1.7/json/ 
4. NIST. SP 800-218 Secure Software Development Framework. Use in this asset: Underlying software development lifecycle security framework.  URL: https://csrc.nist.gov/pubs/sp/800/218/final 
5. CyberTech Intelligence. Research-Led Targeted Content. Use in this asset: CTI describes buyer-centric research, content production and editorial safeguards.  URL: https://cybertechintelligence.com/services/targeted-content 
6. SLSA. Specification v1.2. Use in this asset: Current approved software supply-chain artifact provenance and verification structure.  URL: https://slsa.dev/spec/v1.2/