Enterprises are racing to plug Large Language Models (LLMs) into their internal systems CRMs, ticketing tools, code repositories, databases, and SaaS platforms. The Model Context Protocol (MCP) has emerged as the leading standard for this integration. It gives AI models a uniform way to discover and call external tools, read files, and pull live context from third-party systems.

But every new integration layer is also a new attack surface. As MCP adoption accelerates across enterprise AI stacks, security teams are asking an uncomfortable question: is Model Context Protocol solving the AI integration problem while quietly creating the next big AI security risk?

This blog breaks down how MCP works, where its architecture introduces risk, the emerging attack techniques security researchers are already documenting, and what CISOs and security engineering teams should do about it.

A Brief on Model Context Protocol

Model Context Protocol is an open standard that defines how AI applications (MCP hosts, such as an AI assistant or IDE plugin) connect to external data sources and MCP servers through a standardized server architecture. Think of it as a “USB-C port for AI applications”: instead of writing a custom integration for every tool an LLM needs to access, developers expose that tool through an MCP server, and any MCP-compatible host can consume it.

At a high level, the architecture has three components:

• MCP Host:  the AI-powered application (e.g., an AI coding assistant, a chatbot, an agentic workflow orchestrator) that the end user interacts with.

• MCP Client: Embedded inside the host, responsible for maintaining a 1:1 connection with a given MCP server and translating requests/responses.

• MCP Server: A lightweight service that exposes specific capabilities, Tools (functions the model can invoke), Resources (structured data the model can read), and Prompts (reusable prompt templates), over a standardized JSON-RPC 2.0 interface.

Why Does MCP Change the AI Threat Model?

Traditional API security operates on well-understood assumptions: a developer writes the integration code, defines strict input validation, and controls exactly what gets called and when. MCP inverts this model in three important ways:

1. The model decides what to call, not the developer. The LLM parses tool descriptions and autonomously chooses which MCP server, tool, and parameters to use based on natural language reasoning that can be manipulated.

2. Trust is established at discovery time, not enforced at runtime. Once an MCP server is connected, its tool definitions are treated as trusted instructions the model will act on, even if that server’s behavior changes after the fact.

3. Context flows in from everywhere. MCP resources can pull in emails, web pages, file contents, Git commits, ticket descriptions, any of which can carry text engineered to influence the model, alongside legitimate data.

This combination- autonomous invocation, implicit trust in tool metadata, and untrusted content flowing directly into the reasoning loop- is precisely the pattern security researchers look for when identifying a new class of supply chain risk.

Major AI Security Risks Introduced by Model Context Protocol

As organizations integrate the Model Context Protocol into their AI ecosystems, they must also recognize the new security challenges it introduces. The following are some of the most significant risks associated with MCP-enabled AI environments.

1) Malicious MCP Servers

One of the biggest concerns is the deployment of untrusted MCP servers.

An attacker could publish an MCP server that appears legitimate but actually performs malicious operations.

For example:

• Returns manipulated data
• Executes hidden commands
• Requests excessive permissions
• Collects enterprise information
• Injects malicious prompts

If organizations connect AI systems to third-party MCP servers without validation, attackers gain a new entry point.

2) Prompt Injection Through Context

Prompt injection has already become one of the most significant AI security risks.

With MCP, attackers can inject malicious instructions through:

• Documents
• Databases
• APIs
• Emails
• Web pages
• Knowledge repositories

Instead of directly attacking the AI model, malicious instructions become part of the retrieved context.

3) Cross-Server Shadowing and Tool Name Collisions

In multi-server environments, a host may connect to several MCP servers simultaneously. A malicious server can register a tool with a name or description similar to a legitimate one, or explicitly instruct the model, via its own tool description, to route calls intended for a trusted server through itself instead, effectively shadowing a legitimate tool and intercepting data or credentials meant for it.

4) Supply Chain Risk from the Open MCP Server Ecosystem

The MCP ecosystem has grown rapidly, with thousands of community-built servers published on public registries with varying levels of code review, signing, or vetting. Organizations installing third-party MCP servers are, in effect, extending trust to unaudited code with the ability to influence AI-driven decisions and access connected systems, a supply chain risk profile similar to unvetted npm or PyPI packages, but with the added dimension that the “payload” here is natural-language instructions, not just executable code.

As the adoption of the Model Context Protocol grows, organizations need a cybersecurity partner that understands both AI and enterprise security. Kratikal combines deep cybersecurity expertise with AI security best practices to help organizations stay ahead of emerging threats.

Common Security Weaknesses in MCP Deployments

Organizations adopting the Model Context Protocol should evaluate common weaknesses such as:

Security Area	Potential Risk
Authentication	Weak or missing identity verification
Authorization	Excessive privileges
Encryption	Insecure transport channels
Logging	Lack of audit trails
Input Validation	Prompt Injection
Resource Isolation	Cross-context leakage
Server Validation	Rogue MCP servers
Tool Security	Unsafe function execution
Supply Chain	Untrusted connectors

Mitigation Strategies to Secure Model Context Protocol

Organizations adopting MCP shouldn’t avoid it; the productivity gains are real, but they should treat it with the same rigor as any new trust boundary entering the enterprise.

1) Treat MCP servers as untrusted code until vetted.

Apply the same due diligence used for third-party dependencies: source review, provenance verification, and signed releases where available. Maintain an approved registry of vetted MCP servers rather than allowing ad hoc installation.

2) Enforce least-privilege scoping for every MCP server connection.

Credentials and access tokens granted to an MCP server should be scoped tightly to the specific task,  never inheriting full user-level or org-level permissions by default.

3) Pin and monitor tool definitions. 

Capture a hash or snapshot of a tool’s description and schema at approval time, and alert on any drift. This directly mitigates rug-pull-style attacks where a trusted tool’s behavior changes post-approval.

4) Apply content sanitization to ingested resources.

Treat any external content pulled in via MCP resources (documents, tickets, web content) as untrusted input and run it through prompt-injection detection before it reaches the model’s context window.

5) Integrate MCP risk into existing VAPT and red team scope.

Security assessments, including Vulnerability Assessment and Penetration Testing engagements, should now explicitly test AI-integrated environments for tool poisoning, privilege escalation through agent workflows, and indirect prompt injection paths, not just traditional network and application layers.

Conclusion

Model Context Protocol is not inherently insecure; it’s an architectural pattern, and like any pattern, its security depends entirely on implementation discipline. But the same properties that make MCP valuable (autonomous tool use, broad interoperability, rapid ecosystem growth) are the properties that historically precede a wave of exploitation, much like early API sprawl, early cloud IAM misconfigurations, and early open-source supply chain attacks did before them.

The right posture isn’t to wait for MCP-specific breaches to make headlines before acting. It’s to bring MCP integrations into existing governance frameworks now: asset inventory, least privilege, supply chain vetting, and continuous monitoring, applied to a new class of “agentic” trust relationships that traditional tooling wasn’t originally designed to see.

Organizations shouldn’t wait for MCP-specific breaches before taking action. Integrate MCP into existing security and governance frameworks from the start. Enforce least-privilege access, vet third-party MCP servers, and continuously monitor AI interactions. Regular AI Pentesting Services can help uncover prompt injection, tool poisoning, excessive permissions, and other AI security risks before attackers exploit them.

FAQs