TL;DR: AI supply chain security now spans model weights, datasets, prompt pipelines, function-calling and plugin ecosystems, with attacker paths that include poisoned model repositories, prompt injection and retrieval poisoning, according to Straiker. The governance problem is not model quality alone but the trust boundary around every AI dependency, including identity and access controls.
NHIMG editorial — based on content published by Straikerai: Inside the AI Supply Chain: Securing Models, Prompts, and Plugin Ecosystems
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
Questions worth separating out
Q: What breaks when AI supply chains are not protected with provenance and access controls?
A: Teams lose the ability to tell trusted models, datasets and plugins from poisoned or unapproved ones, which turns routine deployment into a hidden execution path.
Q: Why do AI agents complicate existing IAM and NHI governance models?
A: AI agents complicate governance because access is no longer confined to a single environment or a single identity type.
Q: How do security teams know if an AI agent has too much access?
A: Look for agents that can reach multiple systems without task-specific limits, use persistent tokens, or touch high-value services such as email, chat, cloud consoles, and file stores.
Practitioner guidance
- Implement provenance checks for model artifacts Require signature validation, approved registries and immutable metadata before any model, dataset or prompt template is promoted into production.
- Separate content trust from execution authority Treat emails, documents, retrieved passages and user prompts as untrusted input even when they are relevant to the task.
- Enforce least privilege on agent and plugin credentials Scope every API key, token and service account used by AI workflows to one task, one environment and one data domain.
What's in the full article
Straikerai's full article covers the operational detail this post intentionally leaves for the source:
- Model-layer attack examples that show how poisoned .pth and ONNX artefacts can trigger code execution on load.
- Prompt-layer testing scenarios for input and output gating in agentic workflows.
- MCP and plugin boundary controls, including authorisation checks, sandboxing and resource constraints.
- RAG pipeline safeguards such as provenance tracking, temporal metadata and ABAC at retrieval time.
👉 Read Straikerai's analysis of AI supply chain security across models, prompts and plugins →
AI supply chain security: where model, prompt and plugin risk meet?
Explore further
AI supply chain risk is now an identity problem as much as a software problem. Once models, prompts and plugins can trigger actions, the governing question becomes which identities are allowed to modify artifacts, retrieve data or call tools. That pushes AI security into the same control space as IAM and PAM, where provenance, least privilege and lifecycle controls are the difference between safe delegation and unauthorised execution. Practitioners should manage AI dependencies as governed identities, not static code assets.
A question worth separating out:
Q: What should teams do when a model or plugin dependency is compromised?
A: Contain the affected registry, revoke any credentials or tokens tied to the workflow, and block further promotion until provenance is verified. Then review the execution path for tool misuse, data access and downstream exposure, because a compromised dependency can behave like a live identity with delegated authority.
👉 Read our full editorial: AI supply chain security now spans models, prompts and plugins