You Don't Know What Code You're Running: The Hidden Risks of the AI Agent Supply Chain

When you ask a developer "which AI model are you using?" the answer is usually ChatGPT, Claude, or some newly released name. But the question itself oversimplifies what an AI system is. What an AI agent actually runs is far more than just that model.

The Model Is Only the Tip of the Iceberg

People habitually equate the "AI supply chain" with "model choice" — do you use ChatGPT or Mythos? Do you use Astra or something else? This way of asking only touches the most visible sliver of the entire system.

The reality is that an AI agent is a constellation assembled from a large number of components. The model is just the brightest star among them, and around it orbit MCP servers, the A2A (agent-to-agent) communication layer, plugins, skills, and more. Each component has its own version, its own source, and its own update cadence.

When you focus only on the model, all these other components are running out of sight.

The Agent Constellation: A More Accurate Metaphor

The term "agent constellation" captures the structural characteristic of AI systems: it is not a single artifact but a whole composed of interdependent parts.

This constellation includes at least:

• The foundation model — the LLM you selected
• MCP servers — the interface layer connecting external tools and data
• The A2A protocol — the communication mechanism between agents
• Plugins — third-party modules that extend capabilities
• Skills — prepackaged units of behavior

Each additional component means one more version number to track and one more dependency that could quietly change. The larger the constellation, the greater your ignorance of your system's actual state.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic and gradually adopted by multiple vendors, designed to let models connect to external tools, data sources, and services in a standardized way. Before MCP, every application had to write its own dedicated adapter code to connect to a given database or API; MCP abstracts these connections into a uniform "server" role, with the model side acting as a client that initiates calls according to the protocol. An MCP server can expose capabilities such as tool invocation, resource reading, and prompt templates, and can be released and updated independently. This brings convenience, but also the problem this article focuses on: an agent may mount multiple MCP servers from different sources at the same time, each backed by code you may not have audited and a remote endpoint that may change.

The A2A (Agent-to-Agent) protocol refers to the communication layer through which agents discover each other, delegate tasks, and exchange messages. A single agent has limited capabilities, so complex tasks are often split among multiple specialized agents working together — for example, one agent handles retrieval, another executes code, and a third summarizes. The A2A protocol specifies how these agents describe their own capabilities (usually through some kind of capability card or manifest), how they authenticate, and how they pass context. Unlike MCP's "model connects to tools," A2A is "agent connects to agent," and the call chain may cross multiple organizational boundaries. This means the components your agent actually depends on may include third-party agents you never directly configured, whose versions and behavior are entirely outside your control.

Where Version Locking Breaks Down

Traditional software engineering has mature dependency management tools: lock files, semantic versioning, and hash verification. You can know exactly which version of which package was used at build time.

The AI agent supply chain breaks this certainty. Even if you pin a plugin's version in your configuration, the code actually loaded may still differ from what you expect — the plugin itself may pull remote configuration, an MCP server may point to an endpoint that changes, and model behavior may drift due to server-side updates.

"If I think I'm getting the expected code because I locked the version, but what's actually running is a different piece of code — that's a big problem." This is not a theoretical concern. When you cannot confirm the exact identity of each component, you also cannot determine: which one changed, which one was updated, and which one is no longer what you thought it was.

The difference between lock files and integrity verification is worth distinguishing. A lock file (such as package-lock.json or poetry.lock) pins the dependency resolution result — that is, "which version gets installed" — whereas hash verification pins "what the content is," so even if the version number is the same, replaced content will be detected. The trouble in the AI agent scenario is that many components fetch content dynamically at runtime: plugins may load configuration or scripts remotely, MCP servers may forward requests to mutable cloud endpoints, and the model itself is entirely controlled by the provider. For these links, version numbers provide almost no guarantee; you must rely on runtime manifests, content hashes, or signature verification to answer "what is actually executing right now."

Why This Is More Serious Than It Sounds

Not knowing what code you're running amplifies into three categories of risk in the AI agent scenario.

Security boundaries fail. The premise of supply chain security is that you can enumerate all components and verify their integrity. The constellation model makes enumeration itself difficult — your agent may call third-party services through MCP that you never audited at all.

Behavioral drift cannot be attributed. When an agent's output degrades or exhibits abnormal behavior, you need to determine whether it's a model update, a plugin change, or a problem at the A2A protocol layer. Without component-level visibility, troubleshooting becomes guesswork.

Compliance and audit gaps. When regulators require you to state "which software the system uses," an answer like "we use a certain model" is far from sufficient.

Draw the Constellation

The response is not to reject complexity but to make it visible. At a minimum, you need to: record the source and version of each component; perform integrity verification on critical dependencies rather than relying solely on version numbers; and maintain a runtime component manifest so that "what was actually loaded" can be queried.

An AI agent's capabilities come from the collaboration of the constellation, and its risks likewise come from the collaboration of the constellation. Recognizing this is the prerequisite for managing it.

One-line Summary

An AI agent is not just a model but a "constellation" of multiple components, and its supply chain visibility is far more complex than choosing a model.

Paragraph Summary

The article points out that equating the AI supply chain with "which model you use" is a common cognitive bias. An AI agent is actually composed of a foundation model, MCP servers, the A2A communication layer, plugins, skills, and other components, which the author calls an "agent constellation." Each component has its own version, source, and update cadence, and the larger the constellation, the greater the ignorance of the system's true state. Traditional dependency management relies on lock files, semantic versioning, and hash verification for certainty, but in the AI agent scenario, version locking may fail — plugins pull remote configuration, MCP points to mutable endpoints, and model behavior drifts due to server-side updates. This lack of component-level visibility amplifies into three categories of risk: failed security boundaries, behavioral drift that is hard to attribute, and compliance and audit gaps. The response is to make complexity visible: record sources and versions, perform integrity verification, and maintain a runtime component manifest.