Model Context Protocol (MCP) servers were introduced to help AI systems interact safely with enterprise tools and data. But as organizations adopt third-party MCP components at speed, they are discovering that these servers create powerful new supply-chain risks. A new secure-usage guide from OWASP outlines three core principles for mitigating those risks: understanding server privileges, restricting and validating behavior, and continuously monitoring runtime activity.Two recent MCP-related security incidents illustrate why those principles are urgently needed. In both cases, attackers gained access to sensitive systems not by breaching AI models, but by exploiting weaknesses in the MCP servers connected to them.Related reading:
Understanding privilege: The first line of defense
The guide’s first takeaway stresses the importance of recognizing just how much power an MCP server holds. Many are granted direct access to email systems, document repositories, development environments, and internal APIs. They function as automation engines, not passive plugins.This level of privilege was central to an incident involving a malicious open-source MCP server package discovered exfiltrating emails from organizations that installed it. Because the package behaved like a legitimate automation module, its outbound forwarding activity blended with expected server operations. The breach highlighted a common pattern: MCP servers are often treated as low-risk developer utilities when, in reality, they occupy high-trust positions in enterprise workflows.The Smithery.ai incident demonstrated another facet of the privilege problem. A path traversal flaw in its MCP server hosting pipeline let attackers escape the build directory and read arbitrary files on the underlying VM — including a sensitive authentication token with broad control over more than 3,000 hosted MCP servers. Investigators noted that if exploited, the token could have enabled attackers to deploy rogue servers or exfiltrate customer data across thousands of environments.Both events underscore that the privileges of an MCP server include not only its runtime capabilities but also the trust placed in the systems that build and host it.
Restrict and validate behavior: Implicit trust fails
The secure-usage guide advises organizations to tightly restrict the actions MCP servers can perform and validate their behavior at every step. Without such guardrails, the server’s permissions become the attacker’s playbook.The email-exfiltration case showed how easily a server can abuse its nominal functionality. Because forwarding messages was within the tool’s stated purpose, a malicious implementation could operate without raising immediate suspicion. Without behavioral controls — such as restricting outbound network destinations or enforcing allowlists — nothing prevented the server from silently exporting sensitive information.The Smithery.ai flaw, meanwhile, revealed the dangers of trusting third-party build processes. The platform accepted arbitrary file paths during Docker builds, enabling attackers to pull secrets out of the build environment itself. This is a classic supply-chain risk: the server behaved precisely as the automation pipeline allowed it to.Together, these cases reinforce a clear lesson for practitioners: privilege without restriction is exploitation waiting to happen.
Continuous monitoring: The only way to catch abuse in real time
The guide’s final takeaway emphasizes continuous runtime monitoring and auditing. MCP servers issue commands, move data, and interact autonomously with enterprise systems — yet many organizations lack visibility into what these servers actually do.In the email-stealing incident, simple traffic monitoring could have flagged suspicious outbound behavior. But because MCP servers often operate behind the scenes, their traffic is rarely scrutinized with the same rigor applied to user accounts or core APIs.The Smithery.ai case demonstrated a different monitoring gap: lack of oversight of the build environment itself. A single stolen token could have enabled widespread deployments of malicious MCP servers, and without runtime governance, the resulting activity would have been nearly impossible to attribute.As MCP adoption grows — and as AI agents increasingly rely on them to execute autonomous workflows — lack of monitoring becomes a systemic exposure.
The path forward
The real-world incidents validate the secure-usage guide’s core message: MCP servers must be treated as high-trust, high-risk components of the AI supply chain. Understanding their privileges, restricting their behavior, and continuously monitoring their actions are not optional.For cybersecurity teams, MCP security now sits alongside CI/CD hardening, plugin vetting, identity governance, and open-source software assurance. Organizations that fail to apply these practices risk handing attackers control of the automated systems powering their AI-driven operations.Produced in partnership with the OWASP Generative AI Security Project.
Stephen Weigand is managing editor and production manager for SC Media. He has worked for news media in Washington, D.C., covering military and defense issues, as well as federal IT. He is based in the Seattle area.
