TL;DR: Enterprise AI supply chains now expose reused models, shared prompts, internal apps and third-party dependencies to risks that traditional software controls miss, according to Pluto Security, while the company also reports $42 million in total funding. The governance gap is that AI artifacts behave like security-sensitive runtime assets, so inventory, integrity checks and prompt controls must move ahead of deployment scale.
At a glance
What this is: Pluto Security frames AI supply chain security as a governance problem created by reused models, shared prompts, internal apps and third-party dependencies that traditional software controls do not fully cover.
Why it matters: It matters because IAM, NHI and broader security teams now have to govern AI artifacts, prompts and API connections as controlled assets, not informal development inputs.
By the numbers:
- Pluto Security reported $42 million in total funding.
Context
AI supply chain security is the governance layer that covers models, prompts, datasets, dependencies and the internal apps built on top of them. In this article, Pluto Security argues that traditional software controls were not designed for these assets because they are more dynamic, less transparent and often reused across teams.
The practical problem is not only malicious model tampering. It is the way enterprise AI systems create hidden trust chains across external APIs, internal workflows and reused prompts, which makes the boundary between secure development and runtime behaviour much harder to enforce.
Key questions
Q: What should organisations do first to govern AI supply chain risk?
A: Start by building an AI inventory that lists models, agents, prompts, skills, MCP servers and the dependencies around them. Once that map exists, attach ownership, approval status and runtime reach so risk can be triaged, audited and enforced instead of guessed at from code alone.
Q: Why do reused prompts and shared AI artefacts create security risk?
A: Because prompts and related artefacts act like runtime policy, not harmless text. When they are copied between teams or apps, sensitive instructions, hidden assumptions and output constraints can spread with them, which may change what the system reveals or allows. The risk grows when prompts are not version-controlled, reviewed or separated from user input.
Q: How can organisations tell whether AI dependencies are becoming a supply chain problem?
A: Watch for opaque model provenance, frequent dependency drift, unmanaged external APIs and AI apps that connect to enterprise systems without clear ownership. Those signals show that the AI environment is accumulating hidden trust boundaries. When teams cannot trace what data, prompts or models a system depends on, the supply chain risk is already operational.
Q: How should teams govern AI and cryptographic inventory alongside software supply chains?
A: Treat AI models, cryptographic assets, and software dependencies as separate but linked governance domains. Give each domain an owner, map it to a specific BOM type, and connect the resulting data to release approval and runtime policy. That is how organisations avoid treating xBOM as a single spreadsheet exercise.
Technical breakdown
Why AI models and prompts do not fit traditional supply chain controls
AI supply chains differ from conventional software supply chains because the critical artefacts are not just source code and binaries. Models, prompts, embeddings and training data all shape runtime behaviour, but they are often opaque, non-deterministic and hard to inspect with standard scanning tools. A checksum can verify a file’s integrity, but it cannot prove the model’s behaviour is safe, the prompt is well-governed, or the training data is clean. That is why conventional SBOM thinking only partially applies here. See the AI supply chain security guide. See the AI Supply Chain Security and AI-BOM Guide.
Practical implication: Treat models and prompts as governed security artefacts, not informal project inputs.
How prompt reuse and shadow AI expand the attack surface
Prompt reuse turns a single prompt design decision into an enterprise-wide risk multiplier. When teams copy prompts between applications, embedded instructions, hidden assumptions and sensitive context can spread laterally, especially when shadow AI apps are deployed without central review. Because prompts shape system behaviour, they function more like runtime policy than ordinary text. That means a reused prompt can alter output boundaries, data exposure and tool execution paths in ways that are difficult to detect after deployment. See the AI coding agents security guide. See the AI Coding Agents Security Guide.
Practical implication: Control prompt libraries, not just model deployment, when assessing AI risk.
Why external APIs and data pipelines create hidden trust boundaries
External AI APIs and data pipelines expand the trust boundary of the system in ways many teams still underestimate. Once inference requests, training feeds or retrieval sources cross organisational boundaries, the organisation inherits risk from upstream content quality, provider changes and injected instructions. In practice, this can lead to credential leakage, policy bypass, malicious output or unauthorised API calls when an AI agent is allowed to act on untrusted inputs. The core control problem is therefore not just access, but trust validation at each handoff. See the CI/CD pipeline identity security guide. See the CI/CD Pipeline Identity Security Guide.
Practical implication: Map every inbound data and API path to its trust decision before letting AI agents act on it.
Threat narrative
Attacker objective: The attacker aims to manipulate AI behaviour, extract sensitive context and abuse connected systems through trusted AI workflows.
- Entry occurs when attackers place poisoned data, malicious prompts or compromised dependencies into model training, prompt reuse or third-party integration paths.
- Credential access or abuse follows when malicious prompts or compromised components trigger leakage of secrets, tokens or internal context from the AI system.
- Escalation occurs when altered model behaviour or injected instructions drive policy bypass, unauthorised API calls or downstream pipeline manipulation.
- Impact is enterprise-wide behavioural compromise, data exfiltration or code execution across systems that trust the AI workflow.
Breaches seen in the wild
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
- Ultralytics PyPI compromise 2024: A GitHub Actions injection and a leftover PyPI token let attackers publish four Ultralytics releases that installed a cryptominer.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
AI supply chain security is now a governance problem, not a tooling feature. The article is right to frame models, prompts and internal AI apps as security-sensitive assets because each one can change system behaviour without changing the surrounding application code. That shifts the control objective from scanning binaries to governing the full AI dependency graph, including the artefacts that shape runtime decisions. Practitioners should treat this as an identity and access problem for AI systems as much as a software assurance problem.
Prompt reuse creates a new form of policy drift. When a prompt is copied across teams or applications, its embedded instructions, output constraints and hidden assumptions are copied too. That means the security boundary is no longer the application alone but the prompt logic that governs what the system is allowed to reveal or do. AI coding agents security becomes relevant here because the same pattern appears wherever prompts are shared, modified and executed without review. Practitioners should govern prompts as controlled artefacts, not convenience text.
The hidden trust chain is the real exposure. External model APIs, internal repositories and data pipelines form a layered dependency graph that can fail quietly long before an incident becomes visible. This article surfaces the operational truth that AI systems inherit risk from upstream content, downstream automation and every unmanaged integration in between. That is why inventory, provenance and runtime monitoring belong in the same control plane. Practitioners should map trust boundaries before AI systems are allowed to consume or act on data.
Shadow AI is where AI governance debt becomes operational risk. When departments deploy AI assistants and workflow bots outside central oversight, security teams lose visibility into connections, embeddings, cached outputs and prompt sharing. The result is not just poor inventory hygiene but a fractured control environment where no one can reliably answer what the system is connected to or what it can influence. That makes discovery and ownership assignment the first governance step, not the last.
From our research library:
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
AI supply chain security debt is now a programme issue, not a project issue. As enterprises scale model reuse and internal AI app development, the governance burden shifts from one-off validation to repeatable control over ownership, provenance and runtime behaviour. Security teams should expect this to land in IAM, application governance and cloud control conversations at the same time.
Prompt governance will become a distinct control domain. Prompts are not just content artefacts; they are executable behaviour shapers that need review, change control and separation from user input. Once teams accept that premise, the control stack has to include prompt inventory, access boundaries and monitoring for override attempts.
Third-party exposure is the pressure point. According to the Ultimate Guide to NHI|Ultimate Guide to NHIs, 92% of organisations expose NHIs to third parties, raising concerns about supply chain security. The same pattern now appears in AI dependency chains, which means vendors, APIs and integrations will increasingly be evaluated as shared trust surfaces rather than isolated services.
For practitioners
- Build an enterprise AI asset inventory Register models, prompts, fine-tuned artefacts, internal AI apps and their owners so security teams can see what exists before they assess risk. See the AI Supply Chain Security and AI-BOM Guide.
- Treat prompts as controlled security artefacts Store prompts in version-controlled repositories, require peer review before deployment and separate system prompts from user input to limit hidden behavioural changes.
- Enforce model integrity checks at deployment Use cryptographic signing, checksum validation and restricted registry access to reduce the chance that altered model artefacts move into production.
- Secure AI data pipelines before model training Validate external training sources, restrict ingestion permissions and log fine-tuning activity so poisoned data is easier to detect and contain.
- Monitor runtime behaviour for prompt abuse Track output anomalies, prompt override attempts and unusual API calls initiated by AI agents so malicious instructions are visible during operation.
Key takeaways
- AI supply chains combine models, prompts, datasets and dependencies into a control problem that traditional software scanning does not fully cover.
- The main weakness is governance visibility, because reused prompts and shadow AI can spread risk across teams before security sees it.
- Practitioners need inventory, integrity checks, prompt governance and runtime monitoring to reduce exposure across AI development and deployment.
Related NHI Mgmt Group resources: AI Supply Chain Security and AI-BOM Guide · AI Coding Agents Security Guide · CI/CD Pipeline Identity Security Guide · tj-actions/changed-files compromise 2025
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI04 — Agentic Supply Chain Vulnerabilities | The article focuses on compromised AI dependencies and reused prompts that alter behaviour through the supply chain. |
| Recommendation — Map AI dependency risk to ASI04 and inventory all artefacts that can alter agent behaviour. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is fundamentally about governance for AI assets, dependencies and runtime behaviour. |
| Recommendation — Assign ownership, accountability and change control for AI artefacts under GOVERN. | ||
| MITRE ATLAS | TA0006;TA0008 — Credential Access; Lateral Movement | The attack paths described include credential leakage, API abuse and propagation across connected systems. |
| Recommendation — Trace AI abuse paths to TA0006 and TA0008 to prioritise controls around credential exposure and lateral spread. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article repeatedly points to overbroad access to AI apps, model registries and connected APIs. |
| Recommendation — Apply PR.AA-05 to constrain who can modify, deploy or call AI assets. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | AI supply chain exposure depends on governing identities that can access models, prompts and AI services. |
| Recommendation — Use IAM controls to manage access to model stores, prompt repositories and AI-integrated APIs. | ||
Key terms
- AI supply chain: The AI supply chain is the full chain of models, datasets, prompts, tools, and vendors that influence a deployed AI system. It matters because trust cannot be assigned to the application alone. Practitioners need provenance, ownership, and dependency visibility to govern risk.
- Prompt Governance: Prompt governance is the set of controls used to manage who can create, edit, approve, and roll back prompts in a live AI system. It treats prompts as change-controlled artefacts because small text changes can materially alter model behaviour, data exposure, and tool use.
- 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.
- Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
Deepen your knowledge
The NHI Foundation Level course covers NHI governance, machine identity security and secrets management, with practical coverage of the control patterns that underpin modern AI and identity programmes. It helps practitioners connect governance design to the operational controls their teams must enforce.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org