The rapid adoption of Model Context Protocol (MCP) has made it easier for AI models, agents and development tools to connect to external systems. But a new analysis highlighted by The Hacker News points to a less mature security picture around the public MCP server ecosystem.

According to the report, researchers reviewed 15,465 public MCP servers and found that while the protocol has gained traction, the surrounding ecosystem may expose organisations to security and governance risks. The source text frames MCP as a growing standard for connecting models, agents and IDEs to tools and data, but also argues that enterprise adoption has moved faster than the security controls around public servers.

What happened

The source article cites research from OX Security into the public MCP server landscape. MCP was introduced as a common way for AI systems to access tools and data sources. That promise has helped accelerate adoption among developers and enterprises building agent-based workflows.

At the same time, the source says the broader ecosystem has not kept pace on security. The article references earlier work by the same team involving vulnerabilities linked to Anthropic's MCP environment, and positions the latest findings as evidence that public MCP servers create a larger attack surface for businesses connecting AI systems to external tools.

Based on the information provided, the key confirmed point is that researchers assessed a large number of public MCP servers and reported security concerns around the ecosystem. Specific technical findings should be checked against the original research before businesses use them for risk or compliance decisions.

Why it matters for European businesses

For European companies, MCP-related security issues are relevant because they sit at the intersection of AI adoption, software supply chain risk, data access and internal automation. If a business gives an AI agent access to external tools through poorly governed connectors, the risk is not limited to the AI model itself. The risk extends to the systems, files, APIs and business processes those connectors can reach.

This matters for several reasons:

• Third-party risk: Public MCP servers may be created and maintained by external developers with varying security practices.
• Data exposure: AI agents connected to tools can potentially access internal documents, customer records, code repositories or business applications.
• Privilege management: An insecure connector can widen access beyond what a user or workflow actually needs.
• Compliance pressure: Businesses operating under GDPR, sector rules, customer security requirements or internal governance policies need to understand how AI-connected tooling handles data and access.
• Operational resilience: If MCP servers become part of production workflows, outages or malicious behaviour in those dependencies could disrupt internal processes.

For SMEs in particular, the appeal of agent tooling is often speed. Teams may connect copilots, internal assistants or workflow agents to external servers before procurement, security review or documentation processes catch up. That can create shadow AI infrastructure similar to earlier shadow IT or unsanctioned SaaS adoption.

Who may be affected

The issue is most relevant for organisations that are already using, piloting or evaluating AI agents, LLM-based assistants or developer tooling connected to external systems.

• IT and security teams responsible for AI governance, access control and third-party software review.
• Software and product teams integrating MCP-compatible tools into development environments, internal copilots or customer-facing products.
• Marketing and operations teams experimenting with AI agents that connect to CRMs, content systems, analytics tools or automation platforms.
• E-commerce businesses using AI assistants across product data, customer support or back-office workflows.
• Regulated businesses that need stronger controls over personal data, auditability and supplier risk.

Even companies that do not directly deploy MCP may still be exposed if a software vendor, agency or internal team uses MCP-based components inside broader AI automation projects.

What companies should consider

European businesses do not necessarily need to avoid MCP-based tooling, but they should approach it with the same discipline used for APIs, plugins, SaaS integrations and open-source dependencies.

• Inventory AI connectors: Identify where MCP servers or similar tool-connection layers are already in use across teams and vendors.
• Review trust boundaries: Check what data, systems and actions each AI connector can access, and whether that access is genuinely necessary.
• Prefer approved sources: Use vetted internal or trusted vendor-managed servers where possible instead of unknown public endpoints.
• Apply least privilege: Limit credentials, scopes and permissions for AI-connected tools.
• Strengthen monitoring: Log tool calls, access events and unusual agent behaviour so issues can be detected and investigated.
• Assess supplier risk: Ask AI vendors and implementation partners whether MCP is used in their architecture and how those components are secured.
• Include AI connectors in governance: Update internal AI usage policies, procurement checks and security review processes to cover tool-connected agents and not only the models themselves.

The broader lesson is practical: as AI agents become more useful, they also become more connected. For businesses in Europe, that means AI adoption should be assessed not only by model quality and productivity gains, but also by the security of the connectors, permissions and external services that make those systems work.