Supply Chain: Models, Prompts, Servers, Skills

Supply Chain: Models, Prompts, Servers, Skills is the chapter about what your agent is actually made of. It is assembled at runtime from parts with different owners, several of which can change without a deployment, and the security question is whether you can name the parts that were in place when a particular action was taken.

Key takeaways

• An agent is assembled at runtime, so the deployed artifact does not describe it. Model version, prompt revision, connected tool servers and loaded skills are all part of what ran.
• The Model Context Protocol specification requires hosts to obtain explicit user consent before invoking a tool and treats tool annotations from an untrusted server as untrusted input, which makes a connected server an injection surface as well as an execution surface.
• Prompts are code. They change behaviour, they can be changed without review in most teams, and they belong under the same version control and approval as anything else that decides what a system does.
• A tool server can offer different tools tomorrow than it offered today, so the inventory has to be generated from the running system rather than written by hand.
• Pin what can be pinned, verify what is loaded, and record which parts were in place per action, because that record is what makes an incident investigable.

Read this after Chapter 4, which listed the tools, and Chapter 10, which multiplied the problem by the number of agents. Chapter 12 turns the inventory this chapter produces into part of the evidence an auditor asks for.

An incident review asks a reasonable question. The agent behaved differently on Thursday than on Tuesday, and nobody deployed anything, so what changed.

The answer takes two days to find. The model provider moved the alias the team was pointing at, one of the connected tool servers added three tools, and somebody edited the system prompt in a dashboard on Wednesday afternoon.

Three changes. None in the deployment log, and all of them changing what the system does.

The deployed artifact does not describe the agent

Conventional software has a satisfying property: the artifact you deployed is the software that runs. Container digests, lockfiles and build provenance exist to make that property verifiable.

Agents break it in a specific way. The container may be identical while the behaviour changes, because the parts that decide behaviour are resolved at runtime. The model is a remote service behind a name. The prompts may be loaded from configuration, a database or a prompt-management tool. The tool servers announce their capabilities on connection. The skills or extensions are loaded at start-up from wherever they live.

So the honest description of an agent is not a build. It is an assembly. The assembly is re-formed every time the process starts, or in some designs every time a session begins.

The consequence for security is that the questions you can normally answer from a build system become unanswerable. What version ran. What changed since the last known-good state. What else is affected. Those all need a different mechanism here, and the mechanism is a runtime inventory rather than a build record.

The runtime bill of materials

The artifact to produce is a list, generated by the agent itself at start-up and recorded with each significant action, and it has six parts.

The model, meaning the provider, the specific version rather than an alias, and any inference parameters that materially change behaviour. The prompts, meaning every system prompt, tool description and template, each identified by a content hash or a commit. The tool servers, meaning each connection, whether it is internal or third party, and the exact tool list it advertised at connection time. The retrieval corpora, meaning which sources are indexed and when they were last ingested, which is Chapter 9's provenance requirement seen from the inventory side. The skills or extensions loaded, with their origin and version. And the credentials in scope, by identity rather than by value, which ties back to Chapter 5.

Generate it rather than writing it. A hand-maintained document describes what somebody believed at the time, and the gap between that and the running system is exactly where incidents live.

Then log a reference to it with each action, so the inventory becomes an answer to a question about the past rather than a description of the present.

Models: versions, aliases and the silent update

Model changes are the least controllable part of the supply chain and the easiest to manage badly.

The common mistake is pointing at a floating alias, meaning a name that resolves to whatever the provider currently considers the latest version of a family. It is convenient, it picks up improvements automatically, and it means the component that makes every decision in your system can change without anybody's approval. A behaviour change in that component is a change to your product's behaviour, arriving on the provider's schedule.

Pin the specific version. Treat moving the pin as a change that goes through whatever process you use for changes that matter. That includes running the evaluation suite, which is the entire argument of Proof Before Production and the reason to have built one before you needed it.

Two adjacent details are worth recording alongside the version. Where inference happens, since a self-hosted weight file and a hosted API have completely different threat models and different data-residency consequences. And, for any weights you host yourself, provenance and integrity, meaning the source they came from and a checksum verified before loading, because a weight file is an opaque binary that no review will read.

Deprecation deserves a note as an operational risk rather than a security one. A pinned version will eventually be retired, so pinning without a scheduled review produces an outage on somebody else's timetable.

Prompts are code

Prompts decide what a system does. In most organisations they are the only such artifact with no change control at all.

The pattern is consistent and understandable. Prompts started as text, text feels like configuration, and iteration speed matters early, so they end up editable in a dashboard by whoever has access. Then a prompt edit changes which tools the agent reaches for, or removes a constraint somebody added after an incident, and it happened without a diff, a review or a record.

Treat them as source. Version control, a diff on every change, an approver who is not always the author, and a deployment path that produces a record. Chapter 5 made the point that whoever writes the prompts should not also be the person who grants permissions, and this is the other half of that separation.

There is a subtlety specific to tool descriptions. A tool's description is a prompt fragment, since it is text that reaches the model and shapes what it calls, so a change to a description is a behaviour change even when the implementation is untouched. Put descriptions under the same control as the code beside them.

Prompts that are assembled at runtime from templates and retrieved content need the same treatment applied to the templates, plus Chapter 9's provenance on whatever gets interpolated.

Tool servers are the widest new surface

Connecting an agent to tool servers you did not write is the most consequential supply chain decision in an agentic system, and the specification for the common protocol is unusually direct about it.

The Model Context Protocol specification, at version 2025-11-25, states two things worth quoting in a design review. Hosts must obtain explicit user consent before invoking a tool. And tool behaviour descriptions, including annotations, should be considered untrusted unless they come from a trusted server.

Read the second one carefully. It establishes a category most teams have not accounted for. A tool description is text that reaches the model, so a third-party server supplies input to your agent's reasoning as well as executing actions on its behalf. That is an injection surface, and it is one that renews itself on every connection.

Three properties of a connected server therefore need to be inventoried and watched. What tools it advertises, since the list can differ between connections. What its descriptions say, since the text is an input. And what network destinations it reaches on your behalf, which is a hole in Chapter 8's egress control if the server runs outside your boundary.

The controls that fit are the ordinary ones applied deliberately. Prefer servers you run yourself, pinned to a version you chose. Diff the advertised tool list on every connection and fail rather than adapt when it changes unexpectedly. And treat consent granted for a session as consent for that session, not as a standing grant, which is Chapter 6's point about approvals restated at the protocol layer.

Skills, extensions and dynamic loading

Anything an agent loads at start-up to extend itself is a supply chain component, and the convenience of dynamic loading is exactly what makes it a risk.

The shape recurs under many names. Skills, extensions, plugins, tool packs, prompt libraries, sub-agent definitions. Each is a bundle of instructions and sometimes code, fetched from a repository, a registry or a shared drive, and loaded without the review a dependency in a lockfile would receive.

Two failure modes are worth planning for. A loaded bundle that contains instructions which alter the agent's behaviour, which is injection with a delivery mechanism you built deliberately. And a bundle that expands the tool surface, undoing Chapter 4 quietly by adding capability that never appeared in a review.

The mechanics are familiar from package management, and they work here. Load from a location you control rather than resolving names at runtime. Pin versions and verify integrity before loading. Review bundles as code, since that is what they are. And make the loaded set part of the runtime inventory, so a change shows up as a change.

The agentic risk list OWASP published on 9 December 2025 covers tool misuse and identity abuse among its categories, which is the same territory approached from the attack side. An extension mechanism is the cheapest available route to both.

A worked example, composited and labelled

The details are composited from ordinary production shapes rather than one system, and the shape is exact.

An engineering assistant answers questions about a codebase and opens pull requests. It points at a model alias, loads its system prompt from a management dashboard, connects to two MCP servers, one internal and one third party for issue tracking, and loads four skills from a shared repository at start-up.

Before the work, the answer to what ran on Thursday is unavailable. Nobody knows which model version served the request, the prompt has no history, the third-party server's tool list was never recorded, and the skills repository is a branch anyone can push to.

After the work, the agent writes an inventory at start-up and logs its hash with every action. The model is pinned to a version, with a scheduled review before its deprecation. The prompt lives in the repository, deploys through the pipeline, and the dashboard is read-only. The third-party server's advertised tool list is captured on connection and compared against a recorded baseline, failing the start-up on an unexpected diff. Skills are pinned by commit and verified before loading.

The behaviour change on Thursday would now be a single query, and the answer would name which of the six parts moved.

The objection: we cannot pin a hosted model

The objection is often true in part, and the useful response is to separate what cannot be controlled from what merely was not.

What is genuinely outside your control is the provider's infrastructure, their serving stack, and the retirement schedule for any version. You cannot audit the weights behind a hosted endpoint, and no amount of process changes that.

What is within your control is more than it first appears. Which version identifier you request rather than an alias. Which parameters you send. Whether you notice a change, which is what a small standing evaluation run against a fixed set of cases gives you for very little money. Whether an incident can tell you what was in place, which is the inventory. And every other component in the assembly, since prompts, tool servers, skills and corpora are all yours to pin.

There is a residual risk after all of that, and the honest position is to name it rather than to imply it has been eliminated. You depend on a component you cannot inspect, which is also true of the operating systems and hardware everyone already ships on. Document the dependency, monitor for behaviour change, and keep the containment from Chapters 4 through 8 doing the work, because those controls do not care why the model's output changed.

Chapter summary

An agent is assembled at runtime rather than built, so the deployed artifact does not describe what ran, and the parts that decide behaviour are a model resolved behind a name, prompts loaded from configuration, tool servers that advertise their capabilities on connection, corpora, and skills loaded at start-up. The artifact to produce is a runtime bill of materials covering model version and parameters, every prompt and tool description by hash, each tool server with the exact list it advertised, the retrieval corpora and their ingest dates, the loaded extensions with origins, and the credential identities in scope, generated by the agent rather than maintained by hand and referenced from each logged action. Models should be pinned to specific versions rather than floating aliases, with a moved pin treated as a reviewed change that reruns the evaluation suite, with self-hosted weights checksummed before loading and with pinned versions given a deprecation review so the pin does not become an outage. Prompts are code, including tool descriptions, and need version control, diffs, an approver who is not the author and a deployment record, which is also the separation of duties between whoever writes prompts and whoever grants permissions. Third-party tool servers are the widest new surface, and the Model Context Protocol specification at version 2025-11-25 requires explicit user consent before tool invocation and treats annotations from untrusted servers as untrusted input, which makes an advertised tool list something to diff on every connection. Skills and extensions are dependencies loaded without lockfile discipline, so pin them, verify integrity, review them as code and put the loaded set in the inventory. And where a hosted model genuinely cannot be pinned or inspected, name the residual risk, watch for behaviour change with a standing evaluation, and rely on containment that does not care why the output changed.

The inventory, the identity records, the policy decisions, the egress logs and the memory provenance are now all being produced. Chapter 12 is what to do with them, because for some teams these stopped being good practice and became artifacts somebody will ask to see.