53% of MCP servers are hacker nests

MCP has established itself in less than 18 months as the standard for enterprise AI interconnectivity. The principle is appealing: a single protocol to connect your AI agents to your ERP, your CRM, and your document repositories, without custom development. The promise holds. But what most deployment guides don't say is that MCP was designed for functionality, not for security. And that difference comes at a steep price.

When the productivity tool becomes an open window onto your data

On May 1, 2025, Asana launches its MCP server in beta. The pitch: enable your AI assistants (ChatGPT, Copilot) to query your projects, tasks, and documents in natural language. Hundreds of teams activate the integration within the week.

On June 4, a bug is discovered. A logical isolation flaw in the MCP server allowed users to access data from other organizations: tasks, comments, files, project metadata. The leak had gone undetected for a month. Around 1,000 customers were notified. Asana took its MCP server offline from June 5 to June 17 to fix the issue (sources: BleepingComputer, The Register, UpGuard, June 2025).

What is instructive here is not that Asana suffered a cyberattack. There was none. It is that a simple configuration bug was enough to make third-party customer data visible for thirty days, on a tool that everyone had just connected in good faith. No company that enabled this integration had a way to detect the anomaly on the client side.

This scenario is nothing unusual. It illustrates a reality documented at scale: a study by Astrix Security published in early 2026, which analyzed more than 5,000 open source MCP servers, reveals that 53% of them use hard-coded credentials in configuration files, and that 492 publicly exposed servers have no authentication or encryption at all. The MCP ecosystem is growing faster than its security standards.

What you must put in place before activating the first connector

MCP is not a dangerous tool by nature. It is a powerful tool, poorly governed by default. Here are the non-negotiable rules, drawn from field experience and recent research.

Treat MCP like a door, not a pipe

An MCP server exposes capabilities to an AI agent: read files, query a database, trigger an action in a third-party system. That means a misconfigured or compromised agent can do everything you have authorized it to do.

The basic rule: never grant an MCP server more rights than it strictly needs. If your ERP connector only needs to read current orders, it has no reason to have access to HR records or financial data. The principle of least privilege, applied to AI agents, is not optional. It is the first control your cyber insurer will check in the event of an incident.

Map what you open, not just what you connect

The right question is not "which MCP tool am I connecting?" but "if this agent were compromised tomorrow, what would it have access to?" Ask that question for every connector under consideration.

Start with an inventory of your sensitive data: HR data, customer data, intellectual property, production data. Decide which ones must never be accessible to an external agent, no matter what happens. An IT director who cannot answer that question in five minutes is not ready for an MCP production deployment. It is an exercise that can be done in half a day with the right people in the room: the IT lead, the business owner, and if possible your CISO.

Beware of Shadow MCP: it arrives faster than Shadow IT

OWASP, which just published its MCP Top 10, identifies "Shadow MCP Servers" as one of the most underestimated threats. Developers or data teams spin up an MCP server locally or in a cloud environment, without going through IT, to speed up a project. The result is exactly the same as Shadow IT, with an added attack surface: the agent is running, it accesses data, and nobody knows it exists.

A realistic first step for an SME without an exceptional budget: an audit of active API tokens in your environment and a list of running processes on your development machines. This is not sophistication, it is basic hygiene. And that is often where the surprises appear.

Log your agents’ actions, not just their results

This is the least spectacular advice, and the one most often ignored. In the Asana incident, the leak lasted a month precisely because no client-side mechanism could detect abnormal access. Log every request from your MCP agents: what data was requested, by which agent, at what time, with what result.

This is not excessive monitoring. It is the minimum needed to answer the question "what happened?" in the event of an incident. It is also what NIS2 refers to as traceability of access to critical information systems, an explicit control point for the mid-sized industrial companies covered by the directive.

Run a pilot on a limited scope before deploying

A company does not need to connect twelve systems to its first MCP agent. Start with a single connector, on a scope of non-critical data, with precise success criteria: adoption rate, answer quality, zero security anomalies detected over 30 days. This pilot will give you the evidence to convince your leadership, and above all the experience to avoid costly mistakes when scaling. Involve your business teams from this phase onward: they know the useful data and the limits not to cross. Separating IT and business during the scoping phase guarantees a coherent and useless tool.

How akawan approaches this topic with its clients

Deploying MCP in an industrial or multi-site environment is rarely a purely technical problem. It is a problem of architecture, governance, and trade-offs: which data, with which rights, for which agents, under which conditions.

akawan gets involved upstream of any connector. We help our clients map their sensitive data, define access scopes adapted to their existing information system, and design an AI agent architecture that is production-ready, not just pilot-ready. When data protection is at the heart of the project, Bosl.ai can be integrated into the chain to ensure that sensitive data never travels in clear text to an external LLM, including in MCP flows.

The tool alone is not enough. What makes the difference is the upstream analysis work: inventory, trade-offs, governance. That is the value of a tool-assisted service approach.

What you should do this week

MCP is going to establish itself in your information system. This is not a trend; it is already a reality for your competitors and your software vendors. The question is not whether you will adopt it, but under what conditions.

The Asana case is not an exception. It is a warning. The incident was not caused by a sophisticated attack, but by an integration activated too quickly, on a beta tool, without prior governance.

Take thirty minutes this week to answer a simple question: if your AI agent were compromised tomorrow, what would it have access to? If you do not have the answer immediately, that is where everything begins.