AI supply chain security now spans models, prompts and plugins

At a glance

What this is: This is an analysis of how AI supply chain risk extends from traditional software dependencies into model, prompt, RAG and plugin layers, with the key finding that each layer adds a distinct attack surface.

Why it matters: It matters because IAM, NHI and AI governance teams must treat AI components as governed dependencies, with access, provenance and least-privilege controls enforced across the full lifecycle.

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.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 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.

👉 Read Straikerai's analysis of AI supply chain security across models, prompts and plugins

Context

AI supply chain security is no longer just a software composition problem. In AI systems, the attack surface includes model weights, fine-tuning datasets, prompt templates, RAG corpora, function calls and plugin ecosystems, which means provenance and access control now matter at every layer of the build and runtime chain.

That creates a direct identity governance issue. When models, pipelines and plugins can read data or invoke tools, the relevant control question becomes who or what is authorised to modify, retrieve, execute or delegate, and under what conditions. In that sense, AI supply chain risk is also NHI risk wherever workloads, tokens or agents are part of the path to execution.

Key questions

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. In practice, that can lead to code execution, data leakage, credential exposure or unsafe tool calls from systems that appeared legitimate.

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. An agent may need cloud runtime permissions, customer data access, and tool-level OAuth tokens at the same time, which means standing privilege and lifecycle assumptions break down fast. That is why one control model rarely covers the full path.

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. A healthy deployment leaves a clear audit trail of what the agent can do, what it actually did, and which credentials it used.

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.

Technical breakdown

Model repository compromise and deserialisation risk

AI model files are not always inert artifacts. Formats such as PyTorch .pth and ONNX can serialise objects in ways that create code execution risk when deserialised, so a poisoned model in a public repository can become a delivery mechanism rather than just a bad classifier. The trust problem is therefore upstream of inference: teams often validate model accuracy but not provenance, signature status or loading context. Secure model storage requires hardened registries, integrity verification, and restricted deserialisation so that model adoption does not become arbitrary code execution.

Practical implication: treat model registries as security boundaries and gate deployment on provenance and signature checks.

Prompt injection, transitive trust and agent misuse

Prompt injection works because language models process input and instructions in a shared token stream. In agentic systems, the failure is amplified by transitive trust: a model reads content, extracts intent and then uses tools or data sources on the user's behalf. That means a malicious email, document or message can steer the agent into exfiltration or unsafe action without exploiting the model itself. Input and output gating, strict task-scoped access and adversarial testing are the relevant controls because the weak point is not the model alone but the chain from content ingestion to tool execution.

Practical implication: isolate agent permissions from content trust and test tool use paths as attack paths.

MCP, function calling and plugin authorisation boundaries

Model Context Protocol and related function-calling patterns create a natural language interface to tool execution. The security issue is not that the model can call functions, but that the surrounding system may treat the call as implicitly authorised. That creates parameter injection, tool confusion and privilege escalation risks when the user is not permitted to perform the resulting action. SCA, sandboxing and explicit authentication and authorisation at each boundary are essential because the model's intent is not a substitute for policy enforcement.

Practical implication: enforce authorisation at the tool layer, not at the language layer.

Threat narrative

Attacker objective: The attacker aims to convert trusted AI dependencies into execution paths that leak data, expose credentials or trigger unauthorised actions at runtime.

1. Entry occurs when an attacker introduces poisoned model artifacts, malicious prompt content or compromised plugin dependencies into the AI supply chain.
2. Escalation occurs when the model, RAG pipeline or function-calling workflow trusts that content and turns it into code execution, tool misuse or data access.
3. Impact occurs when the AI system retrieves, exfiltrates or acts on information outside its intended authority, affecting production data, credentials or downstream decisions.

NHI Mgmt Group analysis

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.

Prompt injection is a trust-boundary failure, not a model defect. The article correctly frames injection as a property of token processing, which means defensive focus belongs on gating, isolation and workload permissioning rather than hoping the model will distinguish intent. In governance terms, this is closer to NHI boundary control than traditional application filtering, because the agent can act across systems once trust is misplaced. Practitioners should separate content ingestion from authority to act.

Model provenance is the named concept practitioners need to operationalise. In this context, provenance means being able to prove where a model, dataset, prompt template or plugin came from, who changed it and whether it was approved for use. Without that lineage, the organisation cannot distinguish legitimate artefacts from poisoned ones, especially in fast-moving AI supply chains. That makes provenance a core control for secure deployment, not a documentation exercise.

MCP-style tool ecosystems will force organisations to re-evaluate authorisation granularity. The article's discussion of parameter injection and privilege escalation shows that language-driven tool invocation collapses old assumptions about who initiated an action and who approved it. If the system can call tools on behalf of a user, policy must evaluate identity, context, data sensitivity and operational risk at the moment of execution. Practitioners should expect stronger separation between model intent and policy decisioning.

AI supply chain governance will increasingly converge with NHI governance. As AI systems adopt persistent credentials, plugin permissions and retrieval rights, they begin to behave like distributed non-human identities with delegated authority. That means the operational controls already used for service accounts, secrets and machine identity become highly relevant to AI runtimes. Practitioners should plan for shared governance across AI, IAM and secrets management rather than separate control stacks.

What this signals

AI supply chain security will increasingly be judged by whether organisations can enforce identity-aware controls at the model, prompt and plugin boundary. That includes provenance, least privilege and explicit authorisation for any workflow that can read, retrieve or execute on behalf of a user.

Provenance trust gap: the practical failure mode here is assuming a model or plugin is safe because it is popular, public or technically functional. Security teams should treat every external AI dependency as a governed asset with lifecycle ownership, verification and revocation paths, especially where [OWASP Agentic AI Top 10](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) risks include tool misuse and prompt injection.

The strongest programmes will connect AI governance to secrets management and workload identity, because the moment a plugin or agent can authenticate to something, it has become an identity problem. For teams building controls, the next step is to align model provenance checks with existing identity governance and zero trust policy enforcement.

For practitioners

• 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. This is especially important where model weights or serialized objects can trigger code execution on load.
• 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. Only the policy layer should decide whether an agent may read, transform or act on that content.
• 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. Remove broad permissions from retrieval tools, calendar assistants and document plugins because those are common escalation paths.
• Add authorisation gates to function-calling workflows Make every external tool call pass through identity, sensitivity and context checks before execution. A model initiating a call is not evidence of permission, so policy should evaluate the user, the requested action and the target resource separately.
• Red team RAG and plugin paths as attack surfaces Test how poisoned documents, stale corpus content, malicious parameters and confused tool selection affect downstream behaviour. Include scenarios where the system appears to answer correctly but silently leaks restricted data or performs an unauthorised action.

Key takeaways

• AI supply chain risk now spans models, prompts, retrieval corpora and plugins, so the control boundary has to move with the workflow.
• The article's core lesson is that trusted AI dependencies can become execution paths, which makes provenance and authorisation decisive controls.
• Practitioners should manage AI workflows like governed identities, with least privilege, verification and runtime policy enforcement at every boundary.

Key terms

• AI supply chain: The AI supply chain is the set of components, services and dependencies used to build, train, deploy and operate an AI system. It includes models, datasets, prompts, retrieval sources, plugins and infrastructure, all of which can introduce trust and security risk.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Model Provenance: Model provenance is the evidence chain showing where an AI artefact came from, how it was modified, and whether the version in use is the one that was approved. For AI security teams, provenance is the control that turns trust from assumption into verification.
• Retrieval-augmented Generation: Retrieval-augmented generation is a pattern where an AI model pulls external information before generating output. The security challenge is that access rules can weaken when data is chunked, embedded, cached, or reused, so source permissions may not automatically follow the content into the model's context.

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.

👉 Straikerai's full post covers the model, prompt, MCP and RAG controls in operational detail

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners build the access, lifecycle and assurance controls that underpin secure identity programmes.