MCP Is Your New Software Supply Chain

The thing I keep coming back to is how quietly it happens. An engineer wants their coding agent to read from the internal ticketing system, so they add a line to a config file pointing at a Model Context Protocol server. The agent restarts. From that moment, code the engineer's organization never reviewed holds standing rights to read tickets, and depending on the server's implementation and the permissions it runs under, to write them, to shell out, to reach the network. No change request. No security review. No entry on any dashboard. The capability arrived through a settings file, and the settings file looked like a productivity tweak.

MCP server security is a software supply chain problem, not a bug-bounty problem. Connecting an MCP server is not enabling a feature. It is taking on a code dependency, external or locally installed, that may not have received organizational review and that holds code-execution and data-access rights through the authority the host delegates to it. Tool calling expands an agent's authority by design. The governance model you need already exists, because you already govern packages, container images, and third-party APIs as a supply chain. Your MCP fleet is the same category of risk under a new name. Connecting a server introduces three coupled risks: the provenance of the code or hosted service, the authority delegated to it, and the model-mediated path through which that authority is invoked. Supply-chain controls govern what enters; execution boundaries govern what it can reach; runtime authorization governs what the agent may ask it to do.

Most of the security commentary on MCP stops one level too shallow. It warns you about prompt injection, lists a few CVEs in specific servers, and tells you to patch. That framing treats each vulnerable server as a discrete bug to find and fix. The advice is not wrong, but it sits at the wrong altitude. You will never get ahead of an attacker by patching the next CVE, because the supply of next CVEs is unbounded. What you can get ahead of is the category. And the category, once you name it correctly, comes with a governance discipline you have funded for years.

A tool catalog describes capability. It does not bound authority.

Start with the mechanism, because the supply-chain analogy has to be earned, not asserted. An MCP server does not hand you a static permissions file when you connect it. The client discovers what the server can do dynamically, over the protocol: it initializes the connection and asks the server to enumerate its tools, resources, and prompts through operations like tools/list. (A static manifest.json exists only in the optional .mcpb bundle format; ordinary servers advertise their capabilities at runtime, not through a shipped manifest.) What comes back is a tool catalog, a declaration of the tools the server exposes, the resources it can read, and the actions it can take. The client wires those tools into the agent's action space, and from then on the model can call any of them as a step in its reasoning loop. Whether each call requires confirmation depends on the client and your policy, not the protocol.

This is the part that gets lost when MCP is described as "a plugin marketplace for AI." Some plugin systems ran inside a sandbox with permissions you reviewed at install time; many did not. An MCP server is closer to a service account: you point a program you did not write at your credentials and your resources, on the strength of a capability declaration you have not independently verified. The catalog says what the server advertises. It does not say what the server will do, and the protocol alone does not guarantee runtime enforcement of least privilege, that sits with the client, gateway, server, or surrounding platform controls.

Consider the concrete shape of it. A filesystem MCP server advertises a read_file and a write_file tool. The reasonable reading is "this lets the agent read and write files I point it at." The actual capability is "this lets the agent read and write files, and the boundary of which files is set by the server's code, its configured roots, and the filesystem permissions of the process it runs as, not by the catalog." A database MCP server advertises a query tool. The reasonable reading is "the agent can run the queries I expect." The actual capability is "the agent can run any query the connection's credentials permit, and prompt injection in the data the agent is reading can redirect what those queries are." The gap between the reasonable reading and the actual capability is the whole problem, and it is invisible at connection time, because connection time is a one-line edit to a config file.

So the first reframe is small and exact. The advertised tool catalog is not an authority boundary. It describes the callable interface; the connection config plus credentials, the OS process rights, the filesystem mounts or sandbox, the OAuth scopes, the database roles, and the network policy are what establish the effective grant.

Tool calling expands an agent's authority by design

Here is the claim the rest of the article rests on. Connecting a tool expands an agent's authority by design. Not as a bug, not as a misconfiguration, but as the intended behavior of the protocol working exactly as specified.

Walk the boundary. Before you connect an MCP server, your agent is a text generator. It can produce strings. Whatever harm a pure text generator can do is bounded by the fact that a human or a downstream system has to act on those strings. Connecting a tool moves the model from proposing actions to requesting actions through authority delegated by the host, and that action runs with the privileges of the server, not the privileges of the conversation. A model that was reasoning about your codebase a second ago can now request a write to it, a commit, or a call out to a service with the server's credentials. That is not privilege escalation by itself, the host granted the authority deliberately. The escalation risk appears when malicious input, a compromised server, or an authorization flaw lets the system exercise more authority than the user intended. OWASP catalogs the underlying concern as LLM06 "Excessive Agency": an agent acquiring the ability to take consequential actions through the tools it has been granted.

The reason this is easy to miss is that it does not feel like delegating authority. It feels like enabling a convenience. The vocabulary of the ecosystem is the vocabulary of features: "add a tool," "connect a server," "give your agent access to X." Every word in that sentence is soft. None of them sound like "delegate standing code-execution authority to a dependency that may not have been reviewed, mediated by a model that can be steered by the text it reads." But that is the operation. The softness of the language is doing real work, and the work it is doing is hiding an authority grant inside a feature toggle.

Now add the second-order risk, the one that makes MCP genuinely different from a service account. The agent that holds these tools is also reading untrusted input. It reads the ticket, the email, the web page, the file. Prompt injection, which OWASP catalogs as LLM01, the top entry in its list of large-language-model risks, is the technique of hiding instructions inside that input so the model treats attacker text as its own intent. Prompt injection is already a problem without MCP: it can expose context the model holds or corrupt the decisions it feeds downstream. Combined with tool access, it becomes more direct, injection can make a model do things it should not, using the standing authority of every server it has loaded. The injection is the trigger. The standing tool grant defines the blast radius. MCP is the mechanism that connects them, and unless the client or platform inserts a checkpoint, it connects them with no separate authorization step.

This is why "watch out for prompt injection" is necessary but insufficient advice. Prompt injection is the exploit technique. The standing tool grant is the attack surface. You can harden the model against injection all you like, and you should, but you have not changed the size of the surface. The surface is every privilege every connected server holds, available to be triggered by any untrusted text the agent reads. Reducing that surface is a governance problem, not a model problem.

The evidence is not the argument, but it is the alarm

If tool-calling escalates privilege by design, the next question a careful reader asks is whether the servers being connected are actually unsafe, or whether the risk is theoretical. The evidence we have says it is not theoretical.

Security researchers who have begun analyzing the growing population of public MCP servers keep landing on the same shape of finding, and the most useful way to read the numbers is to notice they are measuring different things. A rigorous academic review (Queen's University, 2025) of roughly 1,900 open-source servers found single-digit percentages carrying MCP-specific flaws, on the order of 5.5% with tool-poisoning weaknesses and 7.2% with general vulnerabilities. A broad scan by AgentSeal of around 1,800 servers that counted any security finding at all ran much higher, to roughly two-thirds of the population. Those two figures are not comparable: one counts a narrow, severe class of MCP-specific exploit, the other counts any finding of any severity. What they share is the direction. Whether the real rate in your fleet is a few percent of severe flaws or a majority of minor ones, the rate is not zero, and it climbs with every server you add, which is why the unit of governance is the fleet, not the individual server.

Treat these numbers the way you would treat a vulnerability rate in any package ecosystem you depend on: supporting evidence, not the load-bearing claim. Even as the precise fractions shift with more review, the structural fact holds. A young ecosystem, growing fast, with low barriers to publishing and no mandatory security review, will carry a high enough baseline that once you connect a handful of servers, the odds that one of them is a liability stop being hypothetical. That is the normal early state of every package registry that ever existed. The same pattern played out in npm, in PyPI, in container registries. The lesson from those ecosystems is not "wait for the vulnerability rate to drop on its own." The lesson is that the rate drops only where someone installs governance: provenance signals, scanning, allow-listing, and least-privilege defaults.

The reason Model Context Protocol vulnerabilities feel different from npm vulnerabilities, even when the underlying flaw is the same class of bug, is the privilege model. A vulnerable npm package can do damage when it runs. A vulnerable MCP server holds standing tool access the entire time it is connected, and that access is reachable by prompt injection through any untrusted input the agent reads. The blast radius is larger and the trigger is easier. So the compounding fleet risk in MCP servers is not "the same as npm." It is npm's failure mode with a wider blast radius and a remote trigger built into normal operation, and it scales with every server you add.

An MCP fleet is a software supply chain

Now the reframe earns its keep. Once you see that installing a server is taking on an unaudited dependency with standing privileges, the whole problem snaps into a shape you already know how to manage. MCP supply chain security is not a new discipline you have to invent. It is the supply-chain discipline you already run for code, applied to a new kind of dependency.

A software supply chain has five governance moves that mature organizations already fund. Each one maps directly onto MCP, and the mapping is exact, not metaphorical.

The value of the table is not that it is clever. It is that every row on the right is a thing your security organization already knows how to do on the left. You are not being asked to learn a new craft. You are being asked to recognize that the craft you have applies to a dependency you have not been treating as one. That recognition is the entire move from an unbounded "patch the next MCP CVE" problem to a bounded "govern the MCP fleet like a supply chain" problem. The first has no end. The second has a design.

The control plane is layered, and no single layer is enough

Naming the category is the reframe. Building the control plane is the work. The mistake to avoid is hoping one control does it all, the gateway is necessary, not sufficient; the allow-list governs what connects, not what a connected server can reach. The three coupled risks from the opening, provenance, delegated authority, and the model-mediated path, map onto five control layers, and each layer enforces a boundary the others cannot.

Read top to bottom, the layers answer the three coupled risks in order: Acquisition and Connection govern what enters, Execution governs what it can reach, Invocation governs what the agent may ask it to do, and Operations keeps all of it honest as the fleet changes. Build it as three artifacts and a recurring practice, mapped onto those layers.

The first artifact is the auth gateway, which carries the Invocation layer. Today, the default MCP topology is direct: an agent connects to each server it needs, point to point, and the connections live in scattered config files on developer machines and in service deployments. You cannot see that topology, which means you cannot govern it. The auth gateway is the single chokepoint that fixes visibility at the call boundary. Every agent-to-tool call routes through it. It authenticates the agent, authorizes the specific tool call against policy, validates arguments, logs it, and can cut a server's access in one place without chasing config files across the fleet. The gateway need not be bespoke, it can be an enterprise API gateway, a service-mesh policy layer, a managed MCP gateway, or a client-side broker. What it cannot do is enforce the boundary beneath the call: which tables a generic query tool reaches, what a local server reads directly off disk, or an undeclared network call a server makes on its own. The gateway enforces call-level policy; database roles, filesystem mounts, sandboxes, network egress policy, and scoped credentials enforce the underlying resource boundary. That is the Execution layer, and it is why the gateway is necessary but not sufficient.

The second artifact is the capability scope configuration, applied per server, spanning the Execution and Invocation layers. The advertised tool catalog describes the callable interface; it is not a reliable upper bound on what the server can reach. The capability scope declares the minimum you will allow, bound to the workflow the server actually serves. Least-privilege capability scoping is the difference between "the database server can run any query the credentials permit" and "the database server's credentials only grant read access to these three tables, and the gateway only permits read queries against them." Note that this takes two enforcement points, not one: you write the call-level policy at the gateway, and you back it with a database role, a sandbox, or a scoped credential so the underlying resource boundary holds even if a call slips the policy. The cost is that you have to know what each server is actually for, which is a feature, not a bug, because not knowing what a connected server is for is exactly the condition you are trying to end.

The third artifact is the allow-list, which carries the Acquisition and Connection layers, and this is where the discipline connects to something most security organizations already have: a provisioning policy. You almost certainly already maintain approved-tool lanes for software, with an exception workflow for anything off the list. The method that governs which IDE plugins, which SaaS apps, and which package sources are approved is the same method that should govern which MCP servers may be connected. An effective provisioning approach declares a default-deny posture, an approved set with documented scopes, and a lightweight exception path so the policy bends instead of breaking. For hosted MCP servers, fold in the same vendor due diligence you run on any third-party data processor, DPA and SOC 2 review, logging retention, subprocessor exposure, because a hosted server is a supply-chain dependency that also moves your data. Bolting MCP onto that existing policy is cheaper than inventing a parallel one, and it puts MCP servers in the same lane as every other piece of software your organization adopts, which is precisely where they belong.

The recurring practice is the trust-graph audit, the Operations layer. Even with acquisition checks, a gateway, scopes, and an allow-list, the fleet drifts. New servers get approved. Scopes get widened for a deadline and never narrowed back. An agent inherits tools from a template nobody remembers writing. The trust-graph audit is the pass that maps the current reality: which agents hold which tools, at which scopes, reachable by which inputs. Pair continuous discovery, telemetry that surfaces a new connection as it happens, with periodic access recertification, and treat the diff between audits as a finding. The audit is the supply-chain re-scan applied to the agent-tool graph, and like every re-scan, its value is not the snapshot. Its value is the diff, because the diff is where the quiet authority creep shows up before it becomes an incident.

"We don't run MCP" is a claim about your inventory, not your reality

There is a version of this article that a reader dismisses with one sentence: "We don't run MCP, so this is not our problem yet." I want to take that sentence seriously, because it is the most dangerous response, and it is wrong in a specific and predictable way: an approved inventory of zero does not prove actual use is zero.

The reason is that MCP fleet governance failures do not start at the org level. They start at the individual developer's machine. An engineer experimenting with a coding agent connects a filesystem server, a GitHub server, and a database server to get their work done, because the agent is more useful that way and nobody told them not to. None of that shows up in a procurement record or a security review. It is shadow MCP, the same shape as the shadow IT and shadow AI patterns that preceded it: a useful capability adopted faster than the governance for it, invisible because it never crossed a controlled path.

This is the governed-path failure, and it is worth naming precisely because the instinct it provokes is the wrong fix. The instinct is to block. Ban MCP servers, lock down config files, forbid the agents. But policy-only blocking tends not to remove the risk so much as your visibility into it, because the capability is useful enough that motivated engineers route around the block, and now you have the same standing tool grants with none of the logging. Policy alone trades a governance problem for a blindness problem. Enforceable controls, the allow-list, the gateway, the scopes, can actually reduce risk, where a policy memo only relocates it. The fix is not a wall. It is a governed path: an approved set of servers, with documented scopes, reachable through the gateway, easy enough to use that the sanctioned path is the path of least resistance. You do not stop AI agent security failures by forbidding the agents. You stop them by making the safe way to connect a tool the easy way to connect a tool.

So the honest version of "this org doesn't run MCP" is "this org doesn't know whether it runs MCP, because nobody has looked." The first move for any organization that has put coding agents or AI assistants in front of engineers is not to write a policy. It is to run the first trust-graph audit and find out what is already connected. For any team with active coding-agent usage, discovery should precede policy, because you cannot govern a fleet you have not yet counted.

What this changes about your security posture

The thing I keep coming back to, the reason this reframe matters more than another CVE list, is what it does to the size of the problem. Framed as a bug-hunt, MCP security is unbounded and reactive: every new server is a new thing to scan, every new exploit a new fire. Framed as a supply chain, it is bounded and designable: a chokepoint to build, a scope discipline to enforce, an allow-list to maintain, an audit to run. The second framing does not make the threat smaller. It makes the response ownable.

For a CTO, a CISO, or whoever funds the AI program, the practical implication is a single line you can act on without a budget cycle. You already have a software supply chain governance function. Extend its scope to the MCP fleet across all five layers. The auth gateway is a service your platform team can stand up with patterns they already know, or an enterprise gateway, mesh policy, or broker you already run. The execution boundaries, sandboxes, scoped credentials, narrow database roles, are least-privilege controls your security organization already applies elsewhere. The allow-list is a lane you almost certainly already maintain for other software, with vendor due diligence for hosted servers. The trust-graph audit is a re-scan on a cadence, the same shape as the dependency re-scans you already schedule. None of it is new craft. All of it is existing craft pointed at a dependency you have been treating as a feature.

MCP is not a plugin marketplace, and it is not the next attack-surface checklist item to dread. It is a software supply chain that arrived inside your AI program through config files, faster than the governance for it. The protocol is genuinely powerful, and the right posture is not to fear it or ban it. The right posture is to govern it like the supply chain it already is, with the discipline you already own, before the first headline-grade exploit turns a design decision into a board conversation. Tool calling will keep expanding what your agents can do, because that is what it is for. Your job is to decide, deliberately and visibly, what authority each grant carries and what it is allowed to reach.

Frequently Asked Questions