Should organisations treat AI poisoning as a model issue or a supply chain issue?

Why AI Poisoning Belongs in Supply Chain Governance

AI poisoning is often introduced through dependencies rather than through the model alone. Third-party datasets, model hubs, APIs, shared retrieval sources, and reused training or prompt assets can all become entry points, which means the real security boundary is wider than the ML pipeline. Nx s1ngularity attack 2025 shows how a poisoned upstream component can cascade into downstream compromise, while Secrets in VS Code extensions 2025 illustrates how exposed credentials in a widely used ecosystem can create the same kind of trust failure.

The practical implication is that ownership should not sit only with the team building or tuning the model. If the input path can be altered, the retrieval source can be poisoned, or a vendor dependency can be abused, then the issue is also a supply chain control problem. That is why provenance, approval, and traceability matter as much as model quality checks.

Which Parts of the Control Surface Need to Be Trusted?

Start with the data path. The most important question is not whether the model is “good enough”, but whether the data that feeds it is sourced, vetted, versioned, and monitored in a way that makes tampering visible. This includes training data, fine-tuning corpora, retrieval indexes, tool outputs, and any third-party enrichment layer that can influence model behaviour.

Then define trust boundaries for external systems. If a vendor, plugin, API, or hosted repository can change what the model sees, that dependency needs the same scrutiny you would apply to any other upstream software component. SLSA is a useful anchor here because AI poisoning often behaves like software supply chain compromise: the integrity of what enters the system matters as much as the behaviour of the system itself. NIST SSDF (SP 800-218) reinforces the need to control source integrity, dependencies, and release handling rather than treating AI assets as isolated artifacts.

Why Runtime Monitoring Still Matters After Provenance Controls

Even good upstream controls will not eliminate poisoning risk, because some contaminated inputs will still enter production. That is why runtime monitoring must watch for sudden shifts in model outputs, retrieval patterns, tool use, or prompt behaviour that suggest a poisoned input has started to influence decisions. Monitoring should look for drift, unexpected policy bypass, and abnormal cross-reference to low-trust sources, not just system uptime.

This is also where governance becomes continuous rather than one-time. The control objective is to catch compromise early enough to limit blast radius, isolate the affected source, and decide whether a model rollback, data quarantine, or retraining cycle is needed. OWASP Non-Human Identity Top 10 is relevant where poisoned data or tools can be reached through service credentials, overprivileged integrations, or unmanaged access paths, because those pathways often determine how far a poisoned dependency can spread.

Risk and Threat Considerations

AI poisoning creates both integrity risk and supply chain risk. The danger is not only that a model produces the wrong answer, but that an attacker can influence trusted outputs through a dependency the organisation does not fully own or observe. That makes third-party provenance, access boundaries, and monitoring part of the same threat picture.

Failure mechanism: A poisoned dataset, connector, plugin, or retrieval source changes the model’s behaviour while appearing legitimate, which can propagate bad recommendations, hidden backdoors, or unsafe actions into production workflows.

Impact: Organisations can inherit compromised outputs at scale, mislead downstream users or agents, and lose confidence in model decisions until the contaminated source is isolated and replaced.

Practitioner Guidance

What to prioritise: Treat every input pathway as an upstream dependency register, not just a data science asset list. Prioritise sources that can change model behaviour without a human approval step, especially third-party corpora, shared retrieval systems, plugins, and vendor APIs.

What to verify: Confirm that each high-value source has an owner, an approval path, version history, and an incident response decision point for quarantine or rollback. If you cannot show who can alter the source and how that change is detected, the control is incomplete.

Common mistake: Teams often over-focus on model weights and under-focus on the trustworthiness of the surrounding ecosystem. A model can be internally sound and still be operationally unsafe if its inputs are exposed to silent tampering.

Practitioner takeaway: The most defensible operating model is to manage AI poisoning as a supply chain integrity problem with model-specific effects, not as a model-only defect that can be solved inside the ML team.

Related resources from NHI Mgmt Group

• Should organisations treat Shadow AI and SaaS supply chain risk as a third-party access problem?
• Should organisations treat AI-enabled attacks as a separate risk category from supply chain security?
• Should organisations treat AI code generators as developer tools or software supply chain risk?
• Should organisations treat AI poisoning as an IAM issue or a content-security issue?