Your AI dependency chain is longer than your vendor list. It runs eight hops: the model provider, the model, the packages your developers install, the plugins and extensions layered on top, the MCP servers that connect models to tools, the agentic skills those tools expose, the identities each hop runs as, and the knowledge sources they read from. Most security teams can name the provider. Few can list all eight hops, and fewer still can say what evidence exists at each one. The OWASP Top 10 for LLM Applications makes the same point in its supply chain entry: in machine learning "the risks also extend to third-party pre-trained models and data", not only to code and dependencies.
Why the map has eight hops, not one
When people say "AI supply chain," they usually mean one thing: which model provider does this run on. That is hop one of eight. A single AI-assisted workflow, for example a developer using a coding assistant that calls an MCP server to read a ticketing system, touches every layer below before it produces an output you can act on.
Treat each hop as a separate question, because each one fails in a different way and leaves a different kind of evidence, or none.
The eight-hop dependency map
Read each row as a standalone answer: what evidence exists here, and what does its absence mean.
| Hop | What it is | Typical evidence available | Where evidence does not exist |
|---|---|---|---|
| 1. Model provider | The company hosting or serving the model (a cloud AI vendor, a self-hosted open-weights deployment) | Contractual terms, a status page, a published data-processing agreement, sometimes a subprocessor list | Real-time proof the provider is running the model version and region you were told, absent your own request-response logging |
| 2. Model | The specific model and version answering a given call | Model name and version string returned in API responses, provider changelogs, model cards; some providers document pinning, for example Anthropic states that every Claude model ID is a pinned snapshot | Which exact model handled a specific historical call, once a provider routes an alias between versions; check whether your provider commits to pinning in writing |
| 3. Package | The library or SDK your developers install to call the model or build an agent | A package manifest, a lockfile, a software bill of materials if one is generated (CISA describes an SBOM as "a nested inventory, a list of ingredients that make up software components"), a registry publish record | Whether the installed package matches the audited source, absent your own hash verification; most teams do not verify this per install |
| 4. Plugin or extension | Add-ons that extend an assistant's or IDE's behaviour, often installed by an individual developer | An extension marketplace listing, a permissions manifest at install time | A central inventory of which extensions are actually installed across your developer estate, unless you run device management that captures it |
| 5. MCP server | A server exposing tools, resources, or data to a model over the Model Context Protocol | The server's own advertised tool list and schema, returned in response to a tools/list request under the MCP specification | Independent verification that the server does only what its advertised schema says (the specification itself says clients "MUST consider tool annotations to be untrusted unless they come from trusted servers"), or a central registry of which MCP servers your organisation has connected, unless you built one yourself |
| 6. Agentic skill | A packaged capability or workflow a model can invoke, often community- or vendor-authored | The skill's published source, if it is open, and its declared inputs and outputs | Proof the skill's declared behaviour matches its actual behaviour on a given run, absent your own execution logging |
| 7. Identity | The credential or service account each hop above runs as when it reads or writes your data | Your own identity provider logs: which credential authenticated, when, with what scope | A cross-hop view tying one identity's actions back through the model, package, and MCP call that triggered them, unless those systems are correlated deliberately |
| 8. Knowledge source | The documents, repositories, or data stores a model or agent is allowed to read for context | Your own access-control logs on the source system | Confirmation that a model only read what it was permitted to read, versus what it was technically able to reach, absent your own read-path logging |
What the empty cells mean
Read the Where evidence does not exist column again. At every hop, the evidence that exists comes largely from what the provider chooses to publish, at hops 1 through 6, or from what your own logging already captures, at hops 7 and 8. Nobody hands you a single, cross-hop chain of evidence by default. Where a cell says evidence does not exist without your own instrumentation, that is a gap to close.
The frameworks already expect you to do this. The NIST AI Risk Management Framework warns that technologies acquired from third parties "may be complex or opaque, and risk tolerances may not align with the deploying or operating organization", and its MANAGE 3.1 outcome asks that risks from third-party resources "are regularly monitored, and risk controls are applied and documented". The NCSC guidelines for secure AI system development put supply chain security and asset documentation in the development stage, and logging and monitoring in the operation stage. The eight-hop table is a way of turning those expectations into a checklist you can fill in.
This is not a claim that any single tool, including SenseOn's, sees across all eight hops. It is a map of where you can currently get evidence and where you cannot, so you know which gaps to close first and which questions to ask a vendor before you extend trust further along the chain.
The one hop proof-points connects to
One question this map raises, where the data itself lives, connects to how SenseOn's own platform can be deployed: in SenseOn's cloud, in a customer-hosted container, on-premise, or via API. That is a fact about where SenseOn's processing runs, not a claim about visibility into the eight hops of your AI supply chain.
Where to start
Pick one AI-assisted workflow already running in production, for example a coding assistant connected to an MCP server. Walk it through all eight hops using the table above. Where you find an evidence gap, that is your priority, not the hop where evidence already exists. Expect the gaps to cluster at MCP servers and agentic skills, the two newest and least inventoried hops, rather than at the model provider you have been watching all along. For hop 5, the MCP specification gives you a lever: it says clients should "log tool usage for audit purposes" and keep "a human in the loop with the ability to deny tool invocations", so ask whether your MCP client does both.
This article is part of The CISO's AI Accountability Playbook. For how provider-side logs alone fall short of proving what an agent did further down this chain, see Provider Logs Can't Prove What Your AI Agent Did. Hop 6, agentic skills, is also where AI pentesting tools sit; Does AI pentesting work? gives the four measures to check before you trust one of those runs.
Sources
- OWASP GenAI Security Project, LLM03:2025 Supply Chain, accessed 20 September 2026
- Model Context Protocol, Tools, specification 2025-06-18, accessed 20 September 2026
- Anthropic, Models overview, accessed 20 September 2026
- CISA, Software Bill of Materials (SBOM), accessed 20 September 2026
- NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, January 2023, accessed 20 September 2026
- NCSC, Guidelines for secure AI system development, 27 November 2023, accessed 20 September 2026
Related reading:
- The CISO's AI Accountability Playbook
- Provider Logs Can't Prove What Your AI Agent Did
- Does AI pentesting work? What to measure before you buy
How SenseOn writes, checks and corrects its content: editorial standards.
