The AI Supply Chain Problem: Securing AI-Generated Code and MCP Servers

Every team that adopts AI quietly takes on two new supply chains. The first is the code that AI tools now write for them. The second is the growing web of agent tools and MCP servers their systems connect to. Both are easy to wave through, and both are exactly the kind of blind spot that turns into an incident later.

We have spent years learning to treat third-party dependencies with suspicion: pinning versions, scanning for vulnerabilities, watching for the next Log4Shell. AI introduces new versions of the same risk, and most teams have not yet extended that discipline to cover them.

AI-generated code is a supply chain

When a model writes a chunk of your application, it is contributing to your codebase as surely as any library you imported. But it does so without the implicit review that comes from a human author thinking it through. The result can look polished and still carry real weaknesses: unvalidated input, secrets hard-coded or logged, missing authorisation checks, subtle logic errors on the paths nobody tested.

None of this means AI-generated code is bad. It means it is unreviewed code until a human reviews it. The mistake is treating fluent, working-looking output as if it had already passed the bar you would hold a colleague's pull request to.

It helps to picture the model as a fast, confident junior developer who never tires and never asks questions. You would not merge that developer's work unread, however good it usually is. The same standard, applied calmly and consistently, is most of what safe adoption of AI coding actually requires.

MCP servers are the new dependency surface

Model Context Protocol servers and agent tools are how modern AI systems reach the outside world: they read files, call APIs, query databases, trigger actions. Every one you connect is a dependency, and collectively they are a supply-chain surface that behaves a lot like your package tree. A compromised, misconfigured or over-permissioned MCP server is a way into your systems, and right now it is the kind of surface few teams are inventorying at all.

The Log4Shell comparison is apt. The danger there was not a tool anyone chose recklessly; it was a dependency buried so deep that nobody knew where it ran. MCP endpoints can become exactly that sort of blind spot if you add them casually and never track them afterwards.

Treat agent configuration as production software

An agent's configuration, its tools, its permissions, its connected servers, its prompts, is not a settings file to be edited on a whim. It determines what your system can do and who it trusts. That makes it production software, and it deserves the same rigour: version control, review, testing, and a clear record of what changed and why.

The practical test is simple: if a change to an agent's tools or permissions could affect customers or data, it belongs in the same pipeline as your application code, with the same review and the same paper trail. Configuration that lives only in someone's head, or in a console nobody audits, is exactly where quiet and expensive mistakes are made.

Practices that contain the risk

You do not need an exotic toolchain to manage this well. You need to apply familiar supply-chain discipline to these new surfaces.

• Inventory every MCP endpoint and tool your agents can reach, so nothing is invisible.
• Pin versions and validate provenance, the same way you would any critical dependency.
• Human-review manifests, configs and permissions before they go live.
• Scan AI-generated code for vulnerabilities and leaked secrets as part of your pipeline.
• Never assume a valid token means safe code: authentication is not authorisation, and neither is correctness.
• Treat agent configuration as production software, with version control and review.

Read that list as a checklist you grow into, not a wall you must scale all at once. Each item shrinks the surface a little and makes the next incident less likely and less severe. The teams that get breached through this path are rarely the ones doing four of these imperfectly; they are the ones doing none of them, because nobody ever owned the problem.

Authentication is not safety

One trap deserves calling out on its own. A tool presenting a valid token tells you who it claims to be, not that what it does is safe. An authenticated MCP server can still be misconfigured, over-scoped or outright malicious. Trust has to be earned through provenance and review, not granted automatically because a credential happened to check out.

The same caution applies to convenience. It is tempting to grant an MCP server broad access so it just works, and to skip reading the manifest because the integration is popular. Popularity is not provenance, and breadth of access is not a feature. A few minutes spent narrowing scope and confirming where a tool actually came from is far cheaper than the incident it quietly prevents.

Building the habit

The teams that handle this well are not the ones with the most tools; they are the ones who made AI code and agent configuration part of their existing security process rather than an exception to it. Once inventorying endpoints, reviewing configs and scanning generated code are simply how you work, the new supply chain stops being a blind spot and becomes just another thing you manage.

Start small if you have to. Even a single shared document listing every MCP endpoint, who owns it, and what it can reach is a meaningful improvement over nothing at all. From there you can add version pinning, automated scanning and review gates as the surface grows. The goal is not perfection on day one; it is simply to stop the supply chain being invisible.

Bringing this kind of supply-chain discipline to AI code and agent tooling is squarely software engineering work, and it is increasingly part of how we build and review systems for clients who want the speed of AI without inheriting its blind spots.