Council Post: Preventing The MCP Layer From Becoming A Cyber Threat
Kris Lahiri is Co-founder and Chief Security Officer at Egnyte, responsible for the company’s security, compliance and core infrastructure.

getty
Enterprise security discussions today are centered around the instructions an agent reads, as they have become as much of an attack surface as the code they run and the models they protect. This is because of the model context protocol (MCP), which has become the connective layer between AI agents and everything they touch in a company’s data architecture.
Most existing security programs are designed around software integrity to verify signed code, monitor vulnerabilities, enforce identity controls and inspect network traffic. These remain essential, but they provide limited visibility into semantic attacks.
What Is Tool Poisoning?
Tool poisoning is an apt example of a semantic attack. Every MCP-enabled tool contains metadata that describes its purpose, capabilities, parameters and usage guidance. AI agents rely on this metadata to determine which tool to invoke and how to invoke it. An attacker who inserts hidden instructions into this metadata can influence an AI agent’s behavior without exploiting the underlying model. The model simply follows the instructions it was designed to interpret.
This makes tool poisoning particularly dangerous because conventional model security techniques offer little protection. The vulnerability exists outside the model but within the expanding ecosystem that surrounds it.
A poisoned MCP tool can appear completely legitimate, with the executable code unchanged, functioning authentication and encrypted network traffic. Yet, the AI agent can be manipulated into exposing sensitive information, invoking unintended actions or bypassing organizational policies simply because the metadata instructed it to do so.
This requires securing machine-readable instructions rather than software artifacts. Security teams must therefore begin treating tool metadata with the same level of trust verification traditionally reserved for executable code.
MCP Adoption: Outpacing Trust Verification
The rapid pace of MCP adoption has dramatically increased enterprise exposure. Organizations are connecting AI agents to increasingly privileged enterprise systems while often applying the same assumptions that governed conventional APIs or application integrations.
Unlike traditional software, AI agents continuously interpret natural language instructions from multiple external sources. Every tool description, configuration file, plugin and metadata object becomes part of the decision-making process.
In April 2026, researchers at OX Security identified a related but distinct risk in the same ecosystem. They found an architectural flaw in how the MCP’s official SDKs handle untrusted configuration input, allowing arbitrary command execution on systems running affected implementations. The researchers linked this exposure to SDKs with more than 150 million downloads and estimated that up to 200,000 MCP instances could be vulnerable across developer environments, internal platforms and cloud services.
Another April 2026 report from Trend AI found that the number of exposed MCP servers has nearly tripled to 1,467, up from the 492 instances the firm first identified running with no client authentication or traffic encryption at all.
Although distinct from tool poisoning, this is a risk that lives in how servers are configured and launched. It points to the same underlying problem of MCP adoption outpacing the trust verification built around it.
Building Security Into The AI Supply Chain
Visibility is the first priority. Most organizations can’t currently inventory every MCP server, AI tool or agent connection operating across their environments. Without that visibility, the associated risk can’t be measured.
At Egnyte, we use encrypted transport protocol to ensure the identity of our MCP tool, which can be verified using protocol certificates. We carefully select MCP servers provided to our customers through our curated list. We also create MCP servers ourselves for the most critical software used by our customers.
The next immediate priority is for enterprises to build stronger governance around tool onboarding. Every external MCP server should undergo security validation before being connected to production AI agents. Metadata should be inspected, validated and monitored for unexpected changes in the same way organizations monitor software dependencies.
Organizations should adopt least-privilege principles for AI agents. Agents should receive only the minimum permissions required to complete specific tasks, limiting the impact of compromised tools or poisoned instructions. Continuous monitoring is equally important here. Agent behavior should be logged and analyzed to identify unusual tool selection patterns, unexpected privilege escalation or abnormal sequences of actions that could indicate manipulation.
Finally, organizations should assume that third-party AI ecosystems will experience supply chain attacks. Security architectures must therefore be designed around containment rather than implicit trust, ensuring that compromise of one MCP-connected tool doesn’t cascade across the broader enterprise environment.
Conclusion
As AI agents become increasingly autonomous, trust can no longer be assumed simply because a tool is connected through a standardized protocol. Every new integration expands the enterprise’s attack surface, and every MCP server becomes part of the organization’s software supply chain.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?