The fastest-growing part of most organisations' AI supply chain is not on any architecture diagram. It lives in developers' home directories.
Coding agents have become extensible. A developer who wants their agent to draw better diagrams, follow the team's commit conventions or query the issue tracker installs a skill or connects an MCP server. Many come from public repositories, installed with a single command. Some are a page of instructions. Some include scripts the agent will run. Some are servers that hold a token for a real system. All of them shape what an agent with access to source code, terminals and credentials will do next.
Langeberg Software is fictional, and its systems and figures are illustrative. After the incident in Part 3, Langeberg's platform team asked engineers to list the skills and MCP servers they had installed. Across 22 machines the answer was 31 distinct skills and 9 MCP servers. Four of the servers held credentials: a Git hosting token with write access, an issue tracker token, a read-only cloud role and a connection string for a staging database. Nobody had a record of which versions were installed, or where most of them came from.
CloudNala's view is that anything that can steer an agent or give it new abilities is an executable dependency, and should be treated with the same discipline as a package: a source, a version, an owner and a review proportional to its reach.
Instructions are not harmless
It is tempting to separate "just text" from "code". A skill that contains only instructions does not execute anything itself.
But an agent with terminal access and a write token executes plenty, and instructions are how it decides what to do. A skill that tells the agent to fetch a script from a URL and run it, to add a dependency, to send diagnostic output somewhere, or to skip a check, achieves through the agent what a malicious package would achieve directly. Prompt injection inside a skill's reference files works the same way. The text is the payload; the agent is the runtime.
That does not make every instruction-only skill dangerous. It means "it is only text" is not a review outcome.
A ladder of reach
Langeberg found it useful to place each item on a ladder, because the review it needs depends on the rung.
Instructions only. A skill made of guidance and reference material. Its risk is the agent's existing authority, steered. Review: read it, check where it came from, pin the version.
Skill with scripts. Instructions plus code the agent will execute on the developer's machine. Its risk is whatever that machine can reach, which for most developers includes source code, cloud credentials and SSH keys. Review: read the scripts as you would a package, check network calls and file access.
Local MCP server. A process that exposes tools to the agent, usually started from a package. It has the developer's local permissions and whatever credentials it is configured with. Review: as a package, plus the permissions and tokens it is given.
Remote MCP server with credentials. A server that holds tokens for real systems and acts on the agent's behalf. Its risk is the authority of those tokens. Review: as a production integration, which is what it is. The MCP security review sets out nine questions for this rung.
The review gate
Langeberg's gate has six checks. It takes a few minutes for an instruction-only skill and longer for a server that holds credentials.
- Publisher and source. Who published it, from which repository, and is that repository what it claims to be? A fork with a similar name is a classic trap.
- Pinned version or hash. Install a specific commit, tag or package version, and record it. "Latest from the main branch" is the unpinned install from Part 2 in a new form.
- Permissions requested. Which tools, files, commands and scopes does it need? Does a diagram skill really need shell access? Does an issue-tracker server really need write scopes?
- Network destinations. Where does it call out to, and why? Anything that sends data to a host other than the service it integrates with needs a reason.
- Secrets it touches. Which tokens does it hold, how are they stored, and could they be scoped down? A personal access token with organisation-wide write access is the most common over-grant.
- Update policy. Who decides when it is upgraded, and does an upgrade go through the same checks? Skills and servers that auto-update are unpinned by design.
What passes goes into an internal registry with a named owner. What fails is not banned. It runs in a sandbox, with no production credentials, until someone takes ownership of it and its risk.
The approved registry
The registry is the important part, because a gate without a destination just slows people down.
Langeberg's registry is a small repository: one entry per approved skill or server, with its source, pinned version, rung on the ladder, the permissions and secrets it uses, the owner, and the date of its last review. The team's agent configuration installs only from it. Developers can still experiment freely in a sandbox environment; what they cannot do is connect an unreviewed server to production credentials.
Within a month the registry held 14 skills and 5 servers. The rest had either been replaced by an approved equivalent or quietly abandoned once someone looked at them. Two of the four credentialed servers were reconfigured with narrower tokens. One was removed: it was a fork of a popular project, a few commits behind, published by an account nobody could identify.
This is the same argument made about MCP servers as products in Design an MCP server as a product, not a wrapper and about gateways in The enterprise MCP gateway. Ownership is what turns a convenient install into a governed dependency. Building Organisational AI Engineering Capability covers the registry as an organisational question.
What not to do
Two failure modes are common when organisations first notice this.
Banning everything. Agents become less useful, developers install things anyway on personal machines, and the organisation loses visibility it had. A light gate with a sandbox path gets more items into the registry than a ban does.
Trusting popularity. A skill or server with many stars or downloads is more likely to have been looked at, and more attractive to compromise. Popularity is a reason to check the publisher carefully, not a substitute for doing so. Part 9 returns to this.
The test
For every skill and MCP server connected to an agent that can reach production credentials, can you name its source, its version, its owner and the date someone last reviewed it? If those answers live only on developers' machines, they are not answers yet.
Next: Part 6, An AI bill of materials must include more than packages. All parts are on the series page.
How CloudNala can help
We help engineering teams inventory the skills and MCP servers their agents use, set up a proportionate review gate and an internal registry, and scope down the credentials those tools hold. The work is designed to keep agents useful while making it possible to answer "what can our agents reach, and through what?"
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Supply Chain Review or write to us at consult@cloudnala.co.za