Help Net Security reported on May 5 that one in four MCP servers expose AI agents to remote code execution. If that sentence had been about Apache, or Log4j, or any traditional piece of software, the response would have been an emergency patch cycle.
Instead, many teams running AI agents have never heard the term MCP server. Which is the problem.
Banks, SMBs, and mid-market companies are deploying AI agents faster than they deployed cloud. The first question everyone asks is “what will this agent do for us.” Almost nobody is asking the second one: what is this agent connected to, and who wrote the code that connects it.
That second question is where your supply chain lives. And right now, one in four of those connections is exploitable.
What an MCP Server Actually Is
In plain English: MCP stands for Model Context Protocol. It is the wire between your AI agent and the systems it touches. Your CRM, your file storage, your databases, your ticketing system, your email, your code repositories. When you plug in an integration to Claude or Copilot or whatever agent your team is using, you are almost always talking to an MCP server on the other end.
The MCP server is a small piece of software. It accepts instructions from the agent, translates them into actions against the connected system, and returns results. It runs somewhere, with some level of access, holding some set of credentials.
In other words: it is exactly the kind of component your vendor risk program would have screamed about if a salesperson had walked it through procurement five years ago. It just did not come through procurement. It came through a checkbox in a settings panel.
The Supply Chain You Didn’t Budget For
Like any software dependency, MCP servers were written by someone. Sometimes a major vendor. Sometimes an open source project with three maintainers. Sometimes a contractor who left the company in March. They live somewhere, often on a developer’s laptop, sometimes on a shared server, occasionally on infrastructure that nobody on the security team has ever seen.
They have permissions. They have to. The whole point is that they can act on data inside your systems.
And one in four of them are configured in a way that lets a remote attacker run arbitrary code on whatever box they live on. That is the headline from Help Net Security’s reporting. The follow-on question is “do we have any of those in our environment.”
For most organizations, the honest answer is “I don’t know,” followed by “and I am not sure who would know.”
Why This Is Different from a Normal Vendor Problem
Traditional vendor risk had two things going for it. The vendor went through procurement, so somebody at least wrote a name down. And the vendor’s software did one thing, so you could scope its blast radius.
AI agents through MCP break both of those.
First, the procurement step is often skipped. A product team or a sales ops manager turns on an agent integration in a UI. No contract, no diligence, no vendor record. The MCP server appeared in your environment and nobody filed paperwork.
Second, agents do many things, by design. The whole point of an agent is to take a goal and figure out which actions to chain together. That makes the blast radius hard to predict in advance. A traditional vendor tool gets read access to a folder. An agent connected through an MCP server might end up reading, writing, deleting, exfiltrating, or triggering automated workflows that touch four other systems, depending on what it decides to do.
Agents are useful. The supply chain question just matters more here than it did with the last generation of SaaS tools.
Three Questions Before Any Agent Goes Live
You do not need a research project to start managing this. You need three answers for every agent that is already running in your environment.
Who wrote this MCP server. If the answer is “a vendor,” you can put it through normal vendor diligence. If the answer is “an open source project,” you can check the maintainer activity, the issue tracker, and the publish frequency. If the answer is “I think one of our engineers built it last quarter,” you have an internal software component that needs to live in your application inventory. If the answer is “I don’t know,” that is your finding.
Where does it run. On a developer laptop is the worst answer and the most common. On a shared dev server is also bad. On a properly hardened internal host with logging is acceptable. In a vendor managed environment with documented controls is good. The location determines who can attack it and how fast you would find out.
What permissions does it have. Read only on a specific resource is your goal. Read-write on a specific resource is sometimes necessary. Admin on a system is rarely necessary and almost never reviewed once granted. If you cannot enumerate the permissions the MCP server is using, you cannot manage the risk it introduces.
What to Do This Week
Inventory first. Ask every team using AI agents to list every integration, not at the agent level but at the MCP server level. You want the actual list of connections, not “we use Copilot.” That list is the start of your supply chain map.
Then map ownership. Every MCP server gets an owner inside your organization. The owner is responsible for knowing whether the server is current, whether its permissions are right, and whether it is logging. If you cannot assign an owner, the server should be turned off until you can.
Then look at the permissions on the top five most permissive servers. Most environments will find at least one that has admin level access to a system that nobody intended to be in the agent’s reach. Reduce those scopes. The agent will still work. The exploit path will not.
Tie the inventory back to your incident response plan. Your IR playbook probably does not have an entry for “MCP server compromise.” It should. The detection signals are different from a traditional breach, and the containment steps include things like rotating credentials in systems your security team did not know the agent was touching.
The Wider Point
AI is the new thing. The supply chain question is not. Software has dependencies, and those dependencies need inventory and review. That has been true for thirty years and it is true now. The “AI” label does not exempt the work.
What is new is the speed. AI agents deploy in a week. The audit cycle that came with traditional software took quarters. If you wait for your standard vendor process to catch up to your agent rollout, you are going to be auditing things that have already been in production for six months.
The MCP server is the new vendor in your stack. It got in without paperwork. It is running on something. It has credentials. One in four of them are exploitable today.
You would not have let a vendor inside your environment under those conditions. The agent is in there anyway. The diligence still has to happen. It is just happening in the wrong order, and you are the one who has to fix that.
If your team is rolling out AI agents and you want help auditing the MCP layer before something exploits it, book a call.
