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.
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 | Which exact model handled a specific historical call, once a provider silently routes between versions; few providers commit to version 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, 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 at connection time | Independent verification that the server does only what its advertised schema says, 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.
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.
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.
Related reading:
