MCP is not just agent plumbing anymore. It is a supply chain.
That is the security shift developers are starting to learn the hard way. Model Context Protocol servers do not merely expose convenient connectors. They inject tool descriptions, schemas, responses and runtime capabilities into an agent’s working environment. The agent then reasons across that material and decides what to call.
In ordinary software, dependency risk means code, packages, build scripts, container images and transitive libraries. In agent systems, dependency risk also includes text that the model treats as operational instruction.
That sounds weird until it breaks.
OWASP defines MCP tool poisoning as an indirect prompt-injection attack that targets AI agents through external tool servers. A malicious or compromised server can embed hidden instructions in a tool description, and those instructions can influence the agent’s behavior or trigger calls to other tools. OWASP’s write-up says a response from an untrusted external server can trigger calls to trusted internal tools, which is exactly the kind of cross-boundary failure traditional connector reviews were not built to catch cleanly.
The security model has to change. MCP servers need to be treated less like harmless plugins and more like executable dependencies with runtime access to context.
Metadata Is Not Passive
The uncomfortable part of MCP security is that the dangerous thing may not look like code.
A tool description tells the agent what a tool does and how to use it. In a normal API review, that is documentation. In an LLM agent loop, it is closer to instruction surface. The model reads the description, mixes it with user prompts, system instructions, retrieved data and memory, then selects an action.
That means a tool description can compete with other instructions. It can shape routing. It can bias the model toward a malicious tool. It can steer the agent to leak data through another tool. It can make the attack indirect enough that a human reviewer misses it.
This is why MCP security is not only a prompt-injection issue. It is a trust-boundary issue.
The agent may trust one server enough to read from it and another server enough to write to it. If the model combines both in the same reasoning context, the read side can influence the write side. That is cross-tool contamination. It looks like a feature until it looks like an incident.
The same applies to memory. If agent memory preserves attacker-supplied instructions or poisoned observations, the compromise can persist beyond one tool call. If a tool response includes adversarial text, the response itself becomes part of the next planning step. The risky object is not just the package. It is the sequence.
Control Planes Are Arriving
Microsoft’s April security post is a useful marker because it treats MCP as a runtime governance problem, not just a protocol enthusiasm problem.
Microsoft says MCP is quickly becoming a common way for AI agents to discover and use tools, and argues for controls at every layer, including a governance layer between clients and tool servers. Its Agent Governance Toolkit is described as a runtime layer that can sit between an MCP client and connected tool servers, scanning tool descriptions for hidden instructions, typosquatting and adversarial patterns before the agent sees them at all.
That architecture is directionally right.
Do not hand the model a raw tool universe and hope policy text wins. Put an enforcement layer in front of the tool universe. Inspect descriptions. Pin known servers. Detect lookalikes. Monitor tool-call sequences. Require approval for sensitive actions. Log the full chain. Sandbox server execution where possible.
This is normal security thinking applied to a strange interface.
The runtime piece matters because install-time review is insufficient. A tool server can change descriptions. A registry can be poisoned. A dependency can be updated. A remote server can return adversarial content after a benign setup. A local server can expose filesystem or shell capabilities wider than expected.
Agents make supply chains dynamic. Security controls have to follow them into runtime.
Sandboxing Is Not Optional Decoration
The deeper question is whether MCP servers should run with direct access to useful local resources.
Many do, because useful agents need files, browsers, terminals, repositories, calendars, databases and internal systems. That is the whole point. But once an MCP server can touch sensitive context, the server is part of the trusted computing base. If the organization installs community servers casually, it has recreated browser-extension risk inside a tool-calling model.
Security teams already know this pattern. Browser extensions, npm packages, CI actions and SaaS integrations all began as productivity shortcuts. Then they became supply-chain risk surfaces. MCP is following the same route, except the dependency can also steer an agent through natural-language instructions.
That combination is new enough to confuse teams. The control language is not.
Allowlist servers. Pin versions. Prefer signed or internally built connectors. Separate high-risk tools from low-risk context. Minimize what each server can read and write. Run untrusted servers in containers or stronger sandboxes. Require human confirmation for actions that cross security boundaries. Capture audit logs that include the prompt, tool description, tool response, selected tool, arguments and downstream effects.
If that sounds like work, yes. That is what happens when agents get hands.
The Enterprise Problem
The enterprise risk is not that one developer installs a strange MCP server. That will happen. The bigger risk is that MCP spreads as invisible infrastructure before governance catches up.
Developer tools adopt it. Security tools adopt it. Internal automation teams build connectors. Business units wire agents into ticketing, documents and data warehouses. Suddenly the organization has an agent tool supply chain, but the inventory is a wiki page and good intentions.
That is not enough.
MCP inventory should become part of AI governance and software supply-chain management. Which servers are approved? Which data can each server access? Which tools can write? Which ones call external networks? Which ones can execute code? Which descriptions changed since approval? Which agents can combine which tools?
Those questions sound tedious because they are the questions that prevent obvious failures.
The useful analogy is not “app store for agents.” It is “runtime package manager with a permission model and a suggestible operator in the middle.” The operator is the model. It is powerful. It is also not a security boundary.
The Implication
The next MCP security phase will be boring and necessary: registries, signing, policy engines, runtime proxies, sandboxed servers, provenance, logs and sequence-aware detections.
That is a good sign. Technologies become real when they acquire unpleasant controls.
The prior MCP story was adoption. The next one is containment. If MCP becomes the standard way agents reach tools, then tool metadata, responses and server processes become part of the application attack surface. Treating them as documentation is negligence with better typography.
For developers, the immediate rule is simple: do not connect an agent to a tool server you would not trust as code running near your data. For security teams, the rule is harsher: assume developers already have.
MCP made agents useful by giving them tools. Now it has to make those tools governable.
Discussion
Sign in to join the discussion.
No comments yet. Be the first to share your thoughts.