The Agent Supply Chain Problem Nobody Is Tracking Yet

Your agent depends on tool servers, prompt templates, models, and documents that your organisation did not write. That is a supply chain with none of the usual controls. This piece covers it, drawing on FISTA Solutions' AI agents engineering work.

What are the dependencies?

Six categories, most of them untracked.

Dependency	Risk if compromised or changed
Tool server	Executes with real privileges
Prompt template	Changes behaviour silently
Model version	Different outputs, no release
Embedding model	Retrieval quality shifts
Retrieved documents	Can carry instructions
Delegated agent	Acts with your authority

Why is this different from ordinary dependencies?

Because the controls do not exist yet and the privileges are higher.

Software dependencies have decades of infrastructure: lock files, signature verification, vulnerability databases, and automated scanning. None of that exists for tool servers or prompt libraries.

Meanwhile a tool server is not a library that might contain a flaw; it is a running service holding credentials to your systems. The privilege level is closer to an integration than to a package. See AI agent security risks.

What does the model version problem look like?

Behaviour changing without any change on your side.

A provider updates a model and your system's outputs shift. Prompts that worked degrade, formats that were reliable become inconsistent, and nothing in your repository changed.

The defences are pinning to specific versions where the provider supports it, running evaluation on every announced change, and logging which version produced which output so a regression can be traced. See how to set up AI change control.

Why are prompts a supply chain issue?

Because they determine behaviour and are frequently treated as configuration.

Templates copied from community collections, vendor examples, or internal wikis end up in production without review. They may contain instructions nobody examined, techniques that do not suit your context, or assumptions about a different model.

Treat them as source: version controlled, reviewed, tested, and owned. A prompt change should go through the same process as a code change, because its effect is the same. See prompt review checklist.

How does retrieved content become an input?

Through instructions embedded in documents the agent reads.

If an agent retrieves a document and acts on its contents, then anyone who can put a document where the agent will find it has a channel into its behaviour. That includes shared drives, ticket systems, email, and public web content.

The mitigation is structural: treat retrieved content as data, never as instruction, and require that any action be authorised by your own rules rather than by something the model read. See why agent security is different.

What controls should exist?

An inventory, pinning, review, and provenance logging.

The inventory is the missing piece almost everywhere: a list of every external dependency, what it can access, who owns it, and when it was last reviewed. Most teams cannot produce one.

Pinning where possible, review of tool servers as privileged code, and logging which versions of everything produced each action complete the set. None of this is difficult; it is simply not being done. See AI dependency review checklist.

What will develop?

The equivalent of the controls that software dependencies have.

Signed tool servers, attested provenance, version manifests, and scanning for known-bad prompt patterns are all plausible and some are being worked on. The ecosystem is young enough that none is standard.

Organisations that build the inventory and logging now will adopt those controls easily when they arrive. Those without will not know what they are running.

What is the counter-argument?

The counter is that this is theoretical risk and no significant incident has made it concrete. That was also true of software supply chain risk for a long time. The controls proposed here are cheap, and the inventory is useful for operational reasons regardless of whether an incident ever occurs.

What does this change for engineering teams?

It means treating tool servers with the same care as a service holding production credentials, because that is what they are.

It also means logging enough to answer what version of everything was in use when an action was taken, which is the question an incident will ask.

What does this change for buyers?

It means asking vendors what their agent depends on, how those dependencies are pinned and reviewed, and what happens when an upstream model changes.

A vendor who cannot enumerate their dependencies has the same problem you do, with less visibility.

What should leaders do about it now?

Require an inventory of external dependencies for every deployed agent, with owners and access scope. That single artefact is the foundation for everything else.

Then require that prompt changes go through code review, because they are changes to behaviour.

How does delegation compound this?

An agent that calls another agent inherits that agent's supply chain, and its own authority flows outward.

That makes the dependency graph considerably larger and harder to see, which is an argument for bounded delegation and for preferring one agent with more tools over several agents cooperating. See the coming agent interoperability standard.

How will you know if this is happening?

Watch for tool servers added without review, for prompts edited outside version control, and for behaviour changes nobody can explain. Each indicates the supply chain is unmanaged.

How FISTA Solutions reads this

FISTA Solutions builds and operates production AI systems through AI agents, AI enablement, and forward deployed engineering: a maintained inventory of every external dependency with its access scope and owner, and provenance logged so any action traces to the versions that produced it, decisions documented with their reasoning, and handover that leaves your team able to maintain what was delivered. The record is 150+ projects for 50+ companies across 12+ countries.

To discuss what this means for your roadmap, message FISTA on WhatsApp, or read why agent security is different.