TL;DR: AI supply chain security now includes models, agents, MCP servers, skill files, and prompt-driven configuration, according to Xygeni, because hidden instructions and unreviewed integrations can alter what assistants can do and reach. Conventional AppSec and endpoint tools miss this layer, so inventory, detection, and enforcement need to move together.
At a glance
What this is: This article argues that AI supply chain security now covers models, MCP servers, skill files and agent configurations, not just code and dependencies.
Why it matters: IAM, IAM-adjacent governance and NHI teams need to treat AI assets as governed software components because unreviewed instructions and integrations can alter privilege, reach and execution paths.
Context
AI supply chain security is the governance problem created when AI components are treated as documentation or infrastructure instead of controlled software assets. In practice, the risk is not only malicious code but hidden instructions, unreviewed connectors and agent configurations that can change what an assistant is allowed to do. That makes discovery, review and enforcement necessary across the full AI estate, especially where models and tools connect to sensitive systems.
The identity angle is material because AI agents, MCP servers and skill files can act like non-human identities with delegated reach. If teams cannot inventory which assistants can invoke which tools, or which prompts and skills influence those actions, they cannot govern privilege or prove containment. That is why this topic sits at the intersection of AI security, software supply chain control and NHI governance.
Key questions
Q: What breaks when AI assistants can read unreviewed skill files or MCP configs?
A: The trust model breaks because the assistant may treat plain text instructions as authoritative policy and then invoke tools, endpoints or data sources that no reviewer intended. That creates a governance failure at runtime, where the control boundary is no longer code alone but every artefact the assistant can ingest and act on.
Q: When do AI supply chain risks become a governance problem rather than a data science issue?
A: They become a governance problem as soon as a model depends on external data, embedded components, hosted infrastructure, or supplier-operated services. At that point, accountability shifts beyond model quality alone. Security, compliance, and procurement teams should jointly evaluate provenance, vendor assurance, and operational resilience before the AI system is allowed into production.
Q: How should security teams control assistant access to tools and data?
A: Teams should set explicit allowlists for tools, endpoints and data sources, then review every AI artefact that can influence execution. The goal is to ensure the assistant can only reach what has been approved, with each connector, prompt and skill tied to an owner and a policy decision.
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.
Technical breakdown
Why AI supply chain security now includes MCP servers and skill files
Traditional software supply chain controls focus on code, build artefacts and package dependencies. AI changes the unit of risk because a model can be paired with prompts, skills, rules files and MCP servers that shape behaviour at runtime. Those artefacts are often committed as plain text, which makes them look low risk even when they redefine what the assistant can access or execute. The governance failure is treating instruction files as documentation instead of security-relevant control points.
Practical implication: classify AI instructions and connector files as governed assets, then review them with the same change control used for code and build inputs.
How hidden instructions and tool injection alter assistant behaviour
Prompt injection and tool injection work because the assistant is expected to follow instructions from multiple sources, including retrieved content and tool metadata. A malicious or poisoned instruction can redirect tool choice, widen data access or induce unsafe actions without changing the visible application code. MCP makes this more important because the server description and tool surface become part of the trust boundary. If the assistant cannot distinguish policy from content, the attacker can.
Practical implication: constrain tool invocation with explicit allowlists, inspect instruction sources and treat retrieved text as untrusted input.
Why discovery and AI-BOMs matter in AI governance
An AI-BOM is an inventory of the AI components that actually exist in a software estate, including models, datasets, agents, prompts, skills and connectors. Without that inventory, security teams cannot answer basic governance questions about ownership, exposure or control coverage. The point is not visibility for its own sake. It is traceability, so that findings can be tied back to the exact AI artefact that introduced risk and to the team responsible for it.
Practical implication: build an AI inventory that maps assets to owners, dependencies and runtime reach before trying to govern risk at scale.
Threat narrative
Attacker objective: The attacker wants to steer AI systems into unsafe actions, wider reach or data exposure by exploiting the trust placed in AI supply chain artefacts.
- Entry occurs when a hidden instruction, poisoned skill or untrusted MCP server is introduced into the AI software supply chain.
- Credential or tool abuse follows when the assistant trusts that artefact and invokes a broader set of tools or data sources than intended.
- Impact occurs when the altered assistant behaviour exposes data, executes unsafe actions or propagates malicious behaviour through developer workflows.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- 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 has become an identity governance problem, not just an AppSec problem. Once models, agents, MCP servers and skill files can influence execution, the question is no longer only whether code is safe. It is also which non-human actors are authorised to invoke which tools, under what conditions, and with what review path. That makes the trust boundary around AI systems a governance object in its own right, not an implementation detail.
Shadow AI now includes hidden instruction layers, not just unsanctioned models. The article shows how ordinary-looking text files can change assistant behaviour without standing out in code review. That creates governance debt because teams may think they have inventories of applications while the actual control plane sits in prompts, rules and MCP descriptions. Practitioners need to treat these artefacts as first-class security objects.
AI-BOM is the named concept that makes this risk auditable. The practical value is not inventory alone, but traceability from each AI artefact to an owner, a runtime dependency and a policy decision. In AI governance terms, that is the difference between claiming oversight and being able to prove it. Teams should build AI-BOM workflows into change control and assurance reporting.
Controls must move from post-build scanning to issuance-time enforcement. If an assistant can load a skill, connect to a server or adopt a prompt at runtime, then later detection is too late to be the primary control. Governance has to assume the artefact may be used immediately and must therefore prevent unauthorised behaviour before execution begins. Practitioners should align policy with runtime guardrails, not with after-the-fact review.
The market signal is clear: AI security is converging with supply chain integrity and NHI governance. The vendors that stay useful will be the ones that can connect discovery, detection and enforcement across code, prompts, agents and connectors. For security leaders, that means re-evaluating whether their current tools can actually see AI trust boundaries or only the surrounding infrastructure.
From our research library:
- Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.
- Read next: AI Supply Chain Security and AI-BOM Guide
What this signals
AI-BOM is becoming the practical control plane for AI governance. Security teams cannot govern what they cannot enumerate, and AI artefacts are now scattered across repositories, build systems and developer tooling. The immediate programme change is to make AI inventory part of change management, not a one-off assessment.
The NHI lesson is straightforward: delegated machine behaviour needs a control boundary. If an agent can load instructions, call tools and inherit permissions, then identity governance has to focus on what can be issued, not just what can be logged after the fact. That shifts the programme from review-centric to enforcement-centric design.
For practitioners
- Inventory all AI artefacts as governed assets Map models, agents, prompts, skills, rules files and MCP servers to owners, approvals and runtime reach so the team can answer what exists and who controls it.
- Review instruction files with change control Require code-review style approval for skill files, rules files and MCP descriptions because plain text can still alter assistant behaviour and tool access.
- Constrain assistant tool reach with allowlists Limit which tools, endpoints and data sources an assistant can invoke, and block unapproved MCP servers or connectors before they execute.
- Add AI-BOM evidence to governance reporting Keep a machine-readable record of AI components, dependencies and owners so audits, risk reviews and compliance requests can be answered without manual reconstruction.
- Extend supply chain controls into AI pipelines Apply provenance, signing and secrets review to models and packages, then feed the results into existing AppSec and risk workflows instead of running a separate silo.
Key takeaways
- AI supply chain security now extends to instruction files, connectors and agent configs, which means the control problem reaches well beyond conventional code scanning.
- The key risk is delegated machine behaviour that can change tool reach and data access without obvious code changes, creating a governance gap that standard AppSec and EDR do not close.
- Practitioners need an AI inventory, runtime allowlists and enforcement before execution, otherwise they will be unable to prove which AI artefacts were trusted or why.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Untrusted AI connectors and servers behave like third-party identity risk in the supply chain. |
| NHI-05 — Overprivileged NHI | The article centers on assistants and servers gaining more reach than intended. | |
| Recommendation — Review third-party AI connectors and server dependencies for trust and access exposure before approval. Restrict AI assistants to the minimum tool and data reach needed for each task. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Delegated assistant access can be misused when identity and privilege are too loosely governed. |
| Recommendation — Bind agent identities to explicit privileges and verify every tool invocation against policy. | ||
| MITRE ATT&CK | TA0006;TA0011 — Credential Access; Command and Control | The article describes supply chain artefacts used to influence execution and reach data. |
| Recommendation — Map AI supply chain abuse to credential access and command paths when triaging AI-related detections. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | AI artefacts change what can be accessed and authorised at runtime. |
| Recommendation — Apply entitlement governance to AI tools, connectors and agent permissions before deployment. | ||
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.
- AI-BOM: An AI bill of materials is a structured inventory of the components that define an AI agent, including the model, prompt, tools, retrieval sources, and dependencies. In practice, it is the evidence base for review, change control, and risk assessment when the agent evolves after deployment.
- MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
- 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
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is suitable for teams that need to govern delegated access, machine identities and emerging AI control planes.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org