AI supply chain security now spans models, MCP servers and skills

At a glance

What this is: This article argues that AI supply chain security has become a distinct control problem because models, agents, MCP servers, and configuration files can reshape AI behaviour outside traditional code-scanning coverage.

Why it matters: It matters because IAM, NHI, and security teams now have to govern what AI systems are allowed to reach, which tools they can invoke, and which hidden instructions can change those permissions.

👉 Read Xygeni's analysis of AI supply chain security across models, agents and MCP servers

Context

AI supply chain security fails when teams treat AI artefacts as documentation rather than governed inputs. A skill file, rules file, or MCP server configuration can change behaviour without looking like executable code, which leaves conventional AppSec blind to the control plane that now sits around AI assistants and agents.

The core governance gap is inventory and trust. Organisations may know the code they scan, but not the models, tools, prompts, or agent endpoints already connected to developer workflows. That creates a shadow AI problem, and where AI systems can invoke external tools, the identity and authorisation question becomes as important as the model itself.

Key questions

Q: How should security teams govern AI agents that can choose tools at runtime?

A: Security teams should govern runtime agent choice as an access event, not as a simple application action. That means scoping permissions to the task, limiting token lifetime, logging every tool decision, and blocking the agent from reaching systems outside its approved context. Static roles alone are not enough when the execution path changes on each run.

Q: Why do traditional AppSec tools miss AI supply chain risk?

A: Traditional AppSec tools are built to inspect code and dependencies, not the behavioural layer created by models, prompts, skill files, and agent connectors. Those artefacts can change what an assistant can see or do without changing the application code path. The result is a blind spot in both inventory and enforcement.

Q: What breaks when AI artefacts are treated like documentation instead of controls?

A: When teams treat AI artefacts as documentation, they stop reviewing the very files that can redirect tool use, data access, and execution. That creates shadow AI, excessive privilege, and inconsistent ownership. The control failure is not just lack of visibility, but lack of governance over the artefacts that define runtime behaviour.

Q: Who is accountable when an AI agent takes action through an MCP server?

A: The accountable party is the human or team that authorised the agent's access, but only if the organisation can prove that chain. Without immutable logs that connect the initiating identity to the tool call and final action, accountability becomes weak, and legal or compliance teams lose the evidence they need.

Technical breakdown

Why AI supply chain artefacts change system behaviour

AI systems extend the software supply chain beyond source code into configuration, instructions, and runtime connectivity. A skill file, prompt template, or MCP server definition can redirect an assistant’s tool use, data access, and output generation without touching application logic. That is why AI supply chain security is not just about malicious code, but about unreviewed instructions and delegated capability. The security boundary moves from scanning files to governing what AI components can influence at runtime.

Practical implication: inventory AI artefacts as governed assets, not documentation, and review any file that can alter agent behaviour or tool access.

How MCP and agent tool access create new trust paths

MCP gives agents a standard way to connect to tools and data sources, which is useful, but it also concentrates trust in server descriptions and permissions. If an untrusted MCP server is connected, the assistant may inherit capabilities the developer never intended, including command execution or data exposure through tool calls. In identity terms, the agent becomes a delegated actor with a changing privilege set, so the governance problem is how to scope and verify that delegation continuously.

Practical implication: approve MCP servers like privileged integrations and restrict agent tool access to the minimum trusted scope.

Why discovery, detection, and enforcement must operate together

AI supply chain security breaks if discovery, detection, and enforcement are split across different tools with different coverage. Discovery builds the inventory of models, agents, datasets, prompts, and configurations. Detection identifies issues such as prompt injection, poisoned skills, excessive agency, and secret exposure. Enforcement blocks unsanctioned installs or server connections before execution. The technical point is that each layer addresses a different stage of the attack path, and leaving any one of them out creates a gap attackers can use.

Practical implication: map AI controls to one lifecycle view so inventory, risk detection, and runtime blocking are aligned.

Threat narrative

Attacker objective: The attacker wants to turn trusted AI tooling into a delivery mechanism for data theft, unsafe execution, or supply chain propagation.

1. Entry happens when attackers plant or poison AI supply chain artefacts such as skills, rules files, package dependencies, or untrusted MCP server configurations.
2. Credential access and tool abuse follow when the AI assistant or agent consumes those artefacts and inherits access to data, commands, or external services it should not reach.
3. Impact occurs when the manipulated assistant leaks data, executes unsafe actions, or propagates tainted behaviour into developer workflows and downstream systems.

NHI Mgmt Group analysis

AI supply chain security is now an identity governance problem as much as an AppSec problem. Once models, MCP servers, and agents can reach tools and data, the key question is not only whether code is safe, but whether delegated AI capability is bounded and reviewed. That makes inventory, approval, and lifecycle control central to governance. Practitioners should treat AI artefacts as identities with reach, not just as software components.

Unreviewed AI instructions create a hidden control plane. Skill files, rules files, and MCP configurations can alter what an assistant is permitted to do while remaining invisible to traditional scanning. That is a governance failure because the organisation thinks it is controlling code when it is really controlling behaviour through artefacts no one owns. The practical conclusion is that AI policy must cover the artefact layer, not just the model layer.

Named concept: AI delegation drift. This is the gap between intended and actual AI capability when tool access, prompts, and server connections change faster than governance can track them. It explains why mature engineering teams still end up with shadow AI and excessive agency. The control lesson is to manage AI delegation as a living entitlement, not a one-time configuration.

Conventional AppSec stops too early for AI systems. SAST and SCA remain necessary, but they do not understand what a model, agent, or MCP server is allowed to do at runtime. That creates a blind spot where the highest-risk decisions happen outside the scanner’s worldview. Security leaders should align AI governance with both software supply chain controls and identity controls for delegated access.

The category is moving toward governed AI inventories, not point tools. The strongest signal in this article is that AI security is becoming a lifecycle discipline spanning discovery, detection, prioritisation, and enforcement. That direction will favour programmes that can prove what AI exists, what it can access, and what was blocked. Practitioners should plan for auditability as a design requirement, not a reporting add-on.

What this signals

AI supply chain security is likely to converge with identity governance because the real question is no longer whether an artefact exists, but what it can authorise at runtime. The more AI systems can call tools and inherit permissions, the more programmes will need entitlement-style review for models, agents, and connectors, not just vulnerability scanning.

AI delegation drift: expect this to become the operational failure mode that explains most AI governance misses. When assistants, prompts, and MCP connections change faster than approval workflows, the security team loses the ability to say who or what had reach at a given point in time.

Organisations that already struggle with secret sprawl will feel this acutely because AI workflows often inherit the same gaps in ownership and rotation discipline. The practical next step is to connect AI inventory work to secret discovery, access review, and policy enforcement rather than running them as separate programmes.

For practitioners

• Inventory every AI artefact with delegated reach Track models, agents, prompts, skill files, rules files, datasets, and MCP server configurations in one governed inventory so hidden capability does not sit outside ownership.
• Treat MCP servers as privileged integrations Require approval, scope review, and periodic recertification for each MCP server connection, especially where the server can expose tools, commands, or sensitive data.
• Block unsanctioned AI installs and connections Use endpoint enforcement to prevent unapproved models, packages, and MCP servers from executing on developer machines before they can influence code or workflows.
• Map AI findings to identity and supply chain controls Link AI artefact exposure to access reviews, secret handling, and software supply chain governance so each risk has an owner and a remediation path.

Key takeaways

• AI supply chain risk now sits at the intersection of software provenance, runtime behaviour, and delegated access.
• Traditional scanners still miss the artefacts that can change what an assistant is allowed to do.
• Programmes that inventory AI assets, restrict tool reach, and enforce policy at the endpoint will have the clearest governance path.

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.
• 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.
• 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.
• AI Delegation Drift: The gradual gap between the capability an organisation intended an AI system to have and the capability it actually accumulates through new prompts, tools, connectors, and configurations. It is a governance failure mode because permissions change faster than review and approval processes.

What's in the full article

Xygeni's full article covers the operational detail this post intentionally leaves for the source:

• How its AI inventory maps models, agents, prompts, datasets, and MCP servers into a single AI graph
• How detection logic flags prompt injection, tool injection, poisoned skills, and secret exposure at the file level
• How the prioritisation funnel separates reachable, exploitable, and actively developed risks for triage
• How endpoint enforcement blocks unapproved models and MCP servers before execution

👉 The full Xygeni article covers AI inventory, detection, prioritisation, and endpoint enforcement in more implementation detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and agentic AI identity. It helps security and identity teams connect access control thinking to emerging AI and machine identity risks.