MCP Security: The New Attack Surface Companies Need to Understand

AI agents become significantly more useful when they can interact with the systems where business work actually happens. They need access to databases, files, developer tools, CRM platforms, cloud infrastructure, internal APIs, messaging systems, and external services.

The Model Context Protocol (MCP) has emerged as an important standard for making those connections easier. Instead of building a custom integration for every AI application and every enterprise tool, MCP provides a common way for AI clients and agents to discover tools, access resources, and interact with external systems. The adoption has been extremely fast. Anthropic introduced MCP as an open-source protocol in November 2024. By December 2025, the MCP ecosystem reported more than 10,000 active servers and over 97 million monthly SDK downloads, with support across platforms including ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code. MCP was subsequently donated to the Agentic AI Foundation under the Linux Foundation. That growth makes MCP important infrastructure for agentic AI.

It also creates a new security boundary. An MCP server can expose tools that allow an AI system to read files, search databases, call APIs, interact with SaaS platforms, execute developer operations, or modify business systems. The model may decide dynamically which of those capabilities to use based on natural-language instructions and information collected during the task. This creates a different risk from a traditional API integration. Developers are no longer defining every sequence of calls in advance. The AI itself can interpret context and select tools.

OWASP describes MCP as creating a security surface that combines familiar problems such as supply-chain compromise and excessive permissions with AI-specific risks including prompt injection, tool poisoning, tool shadowing, and data exfiltration through legitimate tool calls.

The security challenge is therefore not simply protecting an MCP endpoint. Businesses need to control which MCP servers are trusted, which tools an agent can see, which credentials those tools receive, what data can leave the organization, and how much damage a manipulated agent could cause.

MCP Turns AI Integration Into a Security Boundary

The basic MCP architecture appears straightforward. An AI application acts as the MCP host. It connects through MCP clients to one or more MCP servers. Those servers expose capabilities such as tools, resources, and prompts, which can ultimately connect the AI system to databases, APIs, applications, file systems, cloud environments, or other enterprise services.

Conceptually, the flow looks like:

User → AI application → MCP client → MCP server → Tool / API / Data

This architecture solves a significant integration problem. Instead of every AI vendor creating proprietary connectors for every business platform, systems can expose capabilities through a shared protocol. But the same abstraction that simplifies integration also concentrates trust.

Connecting an MCP server can effectively introduce a new set of capabilities into the agent’s operating environment. A server might expose harmless functionality such as searching public documentation, or highly sensitive functionality such as modifying a customer account, reading internal files, accessing source code, executing commands, or deploying infrastructure. The difference may be only one tool definition.

This is fundamentally different from giving an employee access to a traditional application. The employee sees the interface and deliberately chooses actions. With MCP, tool descriptions can be presented directly to an AI model, and the model determines whether a tool appears useful for completing the user’s request. OWASP highlights this characteristic as one of the central security concerns around MCP: the LLM can see tools from multiple connected servers, which creates opportunities for one malicious or compromised server to influence how the agent interacts with other systems. Consider a company connecting an AI coding assistant to three MCP servers: one for source repositories, one for internal documentation, and one for cloud infrastructure. Each server may be legitimate independently.

Together, however, the agent can potentially read internal information, modify code, and interact with deployment infrastructure inside one reasoning process. That creates capability aggregation. An individual permission that looks relatively safe can become much more powerful when combined with several other permissions. Read access to internal documentation plus access to email plus a tool that uploads files can create a potential data-exfiltration path even if none of those capabilities appears dangerous on its own. The relevant security unit therefore becomes larger than the MCP server. Organizations need to evaluate the complete agent capability graph: which servers are connected, which tools they expose, what data each tool can reach, which credentials they use, and which capabilities become possible when tools are combined.

This is one reason MCP security is becoming an architectural issue rather than merely a protocol configuration problem.

Tools and Context Can Become Attack Inputs

One of the most unusual aspects of MCP security is that the definition of a tool can influence the model deciding whether and how to use that tool. A traditional API specification tells developers how to call an endpoint. An MCP tool description can become part of the context available to the AI model. That creates opportunities for tool poisoning. A malicious MCP server could hide instructions inside a tool description, parameter definition, metadata, or returned content. Those instructions may attempt to convince the model to retrieve additional information, use another tool, modify its behavior, or send sensitive data somewhere unexpected. The server does not necessarily need to exploit a software vulnerability.

It can attack the model’s reasoning. OWASP identifies tool poisoning, tool shadowing, cross-origin escalation, and data exfiltration through legitimate channels among the important MCP risks. Tool shadowing is particularly important in environments containing several MCP servers.

Imagine a trusted enterprise MCP server exposes a tool called get_customer_record. A malicious server may not need direct access to the customer database. Instead, its descriptions could attempt to influence the agent’s interpretation of the trusted tool or instruct it to retrieve information and pass the result into another apparently legitimate tool call. This creates an AI-specific version of a confused trust relationship.

Another problem is the rug pull. An organization reviews an MCP server, considers it safe, and approves the connection. The remote server later changes its tools, descriptions, or behavior. The original security review may no longer describe what the agent is actually using.

Anthropic has specifically noted that remote tools create a different trust problem from locally installed software. Local code can be reviewed and its version pinned, while a hosted MCP server can potentially change after the original trust decision. Anthropic recommends treating external remote resources cautiously and testing untrusted integrations in environments where their blast radius is contained. anthropic.com

This means enterprises should not treat MCP approval as a permanent binary decision. Trust needs a lifecycle. Organizations need to know which version or behavior was reviewed, whether tool definitions have changed, whether new capabilities appeared, whether scopes expanded, and whether the server continues to meet internal security requirements. The same principle applies to tool results.

An agent may retrieve a webpage, document, support ticket, GitHub issue, or database record through a trusted MCP tool. The tool itself may be secure, while the content it returns contains malicious instructions. This is indirect prompt injection. The security boundary therefore cannot be reduced to trusted server versus untrusted server. Even trusted infrastructure can deliver untrusted data. A safer design assumes that information entering the model through MCP may influence model behavior and keeps high-impact execution behind independent authorization and policy controls.

Identity and Authorization Can Fail in Subtle Ways

Authentication answers one question: Who is communicating with the MCP server? Enterprise security needs several additional answers.

Which human initiated the workflow? Which AI agent is acting? Which MCP client is involved? Which tool is being requested? Which resource is being accessed? Which permissions should apply to this specific action? Those distinctions matter because an MCP server may otherwise become a confused deputy. Suppose an MCP server connects to a business system using a privileged service account. Several users interact with the server through different AI agents. If the server executes every request using its own broad privileges, a user with limited permissions may indirectly perform operations that the server account is allowed to perform. The server becomes the deputy carrying more authority than the original requester. Authorization therefore needs to preserve the relationship between the user, agent, MCP server, downstream service, and requested action. The current MCP authorization model has continued evolving around OAuth-based mechanisms. The 2026-07-28 specification added additional authorization hardening, including issuer validation designed to reduce authorization-server mix-up risks. Granting access to the MCP server should not automatically grant identical access to every tool behind it.

Token handling is another important area. A dangerous pattern is token passthrough, where an MCP server accepts a token intended for another resource and forwards or reuses it incorrectly. MCP security guidance emphasizes that servers should validate that tokens were actually issued for them rather than accepting arbitrary tokens presented by clients. Over-scoped OAuth permissions create a related problem. An agent may need to read a calendar but receive permission to read and modify the entire account. Another integration may only need access to one repository but receive organization-wide developer permissions. These decisions dramatically change the impact of compromise.

A strong MCP security model therefore applies least privilege at several levels simultaneously: the agent should have limited capabilities, the MCP server should expose only necessary tools, the downstream credential should have limited scope, and individual high-risk actions may require additional authorization. The objective is not simply authenticated MCP. It is context-aware authorization across the complete chain of authority.

Local and Remote Servers Create Different Risk Models

Not every MCP server runs in the same environment. Some are remote services accessed over the network. Others are local programs launched directly on a user’s workstation or development environment. Those models create very different security assumptions. A remote MCP server primarily creates a network and service trust relationship. Organizations need to consider authentication, authorization, data disclosure, server behavior, vendor security, tool changes, logging, and whether information sent to the server leaves the company’s controlled environment. A local MCP server introduces something closer to software supply-chain risk. A local server may run with access to the same workstation as the AI client. Depending on configuration, it may be able to read local files, inspect environment variables, access developer credentials, call local applications, communicate over the network, or execute system commands. OWASP warns that local MCP servers running with broad host access can introduce risks including credential theft, file-system traversal, and arbitrary code execution. cheatsheetseries.owasp.org

That means installing an MCP server should not be treated as casually as adding another AI prompt template. It can resemble installing a development extension or local application. The software supply chain therefore becomes part of MCP security. Companies need to know where the package came from, who maintains it, which dependencies it contains, what permissions it requests, and whether its behavior can change automatically through updates. Version pinning and source review can reduce some of this risk for local servers.

Remote servers create the opposite problem: the organization may know exactly which URL it connected to but have limited control over future server-side changes.

Neither model is inherently secure or insecure. They simply need different controls. Organizations should also consider server-side request forgery and network reachability when MCP servers fetch external resources or perform OAuth discovery. The MCP security guidance and SDK implementations include protections related to SSRF because agents and servers increasingly operate across dynamic URLs and external endpoints. Network architecture therefore matters as much as model configuration. A compromised MCP server running inside a sensitive network segment should not automatically be able to reach every internal service. Traditional controls such as network segmentation, egress restrictions, workload isolation, secrets management, and sandboxing remain highly relevant. MCP does not replace conventional cybersecurity.

It connects AI reasoning to environments where conventional cybersecurity becomes even more important.

Containing the Blast Radius Matters More Than Perfect Model Behavior

Companies should assume that prompt injection will continue to be possible. They should also assume that an agent will occasionally misunderstand instructions. That does not mean MCP cannot be deployed safely. It means the architecture should not depend on perfect reasoning. A useful security question is: If this agent is manipulated right now, what is the maximum damage it can cause?

That question changes security design. An MCP agent with read-only access to a limited documentation repository creates one type of risk. The same agent with access to customer records, email, cloud administration, production deployment, and payment tools creates a completely different blast radius. Anthropic has described containment as increasingly important as agent capabilities grow: the probability of undesirable behavior can be reduced through safeguards, but the potential consequences also need to be bounded through the surrounding system.

One practical approach is to classify MCP tools by impact. Low-risk read tools can often execute automatically. Sensitive reads may require stronger identity controls. Write operations may need stricter authorization. Financial, destructive, administrative, or externally visible actions can require explicit approval or a separate privileged workflow. The security layer should exist outside the model.

If the model decides, “I should delete this database,” the MCP tool should still independently determine whether the operation is authorized.

Security decides whether execution is permitted. Containment can also include sandboxing local MCP servers, restricting filesystem access, limiting network destinations, using short-lived credentials, isolating production tools from development agents, enforcing rate limits, and preventing unrestricted recursive tool execution. Logging needs to capture more than ordinary API access.

For high-impact MCP environments, businesses should be able to reconstruct which user initiated the request, which agent processed it, which MCP server supplied the tool, what parameters were passed, which downstream resource was accessed, what authorization was used, and what result was returned. This becomes essential for incident investigation. It also enables behavioral monitoring.

A documentation MCP server suddenly accessing thousands of files, an agent beginning to invoke tools it rarely uses, or a server that unexpectedly changes its tool definitions can all become security signals.

MCP security therefore benefits from the same principle used throughout modern zero-trust architecture: trust should be continuously evaluated rather than permanently granted.

Enterprise MCP Needs Governance as Much as Engineering

As MCP adoption expands, unmanaged server growth can become another form of shadow IT. One development team installs a GitHub MCP server. Another connects an AI assistant to internal databases. A third builds a custom MCP interface for a CRM. Employees begin experimenting with publicly available servers. Each connection may appear relatively small.

Collectively, the organization can develop a large network of AI-accessible capabilities without a reliable understanding of which systems are connected. This is where MCP security becomes an operational governance problem. Organizations need an inventory of approved MCP servers and the tools they expose. Each production server should have a clear owner, business purpose, data classification, authorization model, connected systems, and lifecycle. Public servers should not automatically become enterprise-approved servers.

The MCP ecosystem itself has recognized this need. The protocol’s November 2025 release emphasized enterprise security and the development of internal MCP registries that organizations can govern themselves. Model Context Protocol Blog.

An internal registry can provide a controlled discovery layer. Instead of allowing employees or agents to connect arbitrary servers from across the internet, the enterprise can maintain a catalog of reviewed integrations. Security teams can define which servers are approved, which versions are allowed, which environments they can access, and which tools require stronger controls. This does not mean every MCP server needs months of review. Risk-based governance is more scalable. A server exposing public documentation can follow a lightweight process. A server capable of accessing production databases or deploying cloud infrastructure should face much stronger requirements.

A practical enterprise review can examine several areas together: source and vendor trust, authentication, requested scopes, tool definitions, data exposure, network access, credentials, logging, update behavior, and potential tool combinations with other connected servers.

Testing should also include AI-specific abuse cases. Security teams can test whether malicious content returned by one MCP server can influence use of another tool, whether hidden tool-description instructions change model behavior, whether sensitive information can be encoded into legitimate calls, and whether high-impact actions remain protected when the model has been manipulated.

Lifecycle management matters as much as onboarding. When a server is no longer needed, its credentials and network access should be removed. When tool definitions change, the risk assessment may need to be repeated. When ownership disappears, the server should not remain connected indefinitely simply because nobody knows whether it is still important. The long-term goal is not to block MCP adoption. It is to make secure MCP adoption easier than unmanaged MCP adoption. That means providing approved servers, standard authentication patterns, scoped authorization, security middleware, centralized logging, testing tools, and internal documentation that development teams can reuse.

MCP becomes much safer when security is part of the platform rather than something every team has to rediscover independently.

Conclusion

MCP solves a real problem.AI agents need standardized ways to interact with the applications, data, tools, and infrastructure that businesses already use. A common protocol can dramatically reduce the complexity of building those integrations and has already become an important part of the agentic AI ecosystem.But connecting AI to more tools also creates more authority. MCP introduces security risks that exist at the intersection of traditional cybersecurity and AI behavior: excessive permissions, supply-chain compromise, confused deputy problems, credential misuse, prompt injection, tool poisoning, changing remote servers, and data exfiltration through legitimate functionality. Companies therefore should not think about MCP security as simply “Is this server secure?”

The more useful questions are: Which agent can connect to it? Which tools can the agent use? Which credentials do those tools receive? Which data can they reach? Can one server influence another? Who approved the relationship? And what happens if the agent is manipulated?

The safest architecture assumes that models, external content, and third-party integrations can eventually behave unexpectedly.

Identity, authorization, isolation, monitoring, approvals, and least privilege determine how far that unexpected behavior can travel. MCP makes AI integrations easier. Enterprise security needs to make sure easier integration does not become easier access to everything.

Why Ficus Technologies?

At Ficus Technologies, we help businesses move AI agents from isolated experiments into secure production environments. MCP deployments often touch several layers of architecture at once: AI applications, APIs, identity systems, enterprise data, cloud infrastructure, developer platforms, SaaS services, and cybersecurity controls. Securing them requires understanding the complete execution path rather than protecting the model or MCP server in isolation. Our expertise across AI development, custom software, API integration, cloud architecture, DevOps, data platforms, and cybersecurity allows us to design MCP-enabled systems with clear trust boundaries. That can include scoped agent identities, secure MCP server architecture, controlled tool access, OAuth integration, secrets management, sandboxing, observability, internal registries, and approval mechanisms for high-impact actions. As organizations connect AI to more of their technology environment, the ability to control those connections will become just as important as the intelligence of the agents using them.

Connect AI to your business systems without giving it unrestricted access – with Ficus Technologies.

Sergey Miroshnychenko

CEO AT FICUS TECHNOLOGIES

My company has assisted hundreds of businesses in scaling engineering teams and developing new software solutions from the ground up. Let’s connect.