The Model Context Protocol, explained for the people who have to procure it

A planning officer who wants their AI assistant to read a live case file, or a finance team that wants it to query the invoicing system directly, is one small technical step away from doing exactly that. The step has a name, the Model Context Protocol, or MCP, and most public bodies currently buying or piloting AI tools have never reviewed what it actually allows into, or out of, their systems.

What MCP actually is, without the jargon

Before MCP, connecting an AI assistant to a specific piece of software, a case management system, a finance database, an email inbox, meant someone writing bespoke integration code for that exact pairing, then doing it again for the next one. MCP standardises that step. It defines one common way for an AI assistant to discover what a connected system can do and to call on it, so the same connector works across different assistants and different tools instead of needing new custom code for every combination. It is the plumbing behind the scenes when a general-purpose chatbot suddenly seems able to look something up in another system. It is not a new capability the underlying model has learned; it is a new pipe the model has been given to use.

That standardisation is genuinely useful. It is also, for exactly the same reason, what turns this into a governance question rather than a purely technical curiosity.

Why this is a procurement problem, not only an IT one

Standardising a connection makes it quick to add. Quick to add means it is quick to add without anyone outside the immediate team noticing, and that is precisely the shape of the shadow IT problem procurement and security teams already know, now applied to AI agents specifically. A January 2026 survey of 2,000 employees at companies with more than 500 staff, run by the security vendor BlackFog, found that 51% had connected an AI tool to work systems without IT's approval or knowledge, that 49% had adopted an AI tool without employer approval at all, and that a third admitted sharing enterprise research or datasets through tools nobody had reviewed. None of that is specific to MCP, but MCP is the mechanism that turns "connect the assistant to that other system" into a five-minute task rather than a development project, which is exactly the kind of change that turns a slow-moving risk into a fast one.

What the risk actually measures out to

This is not hypothetical. Researchers at the API security firm Pynt assessed more than 280 publicly available MCP servers and found that 72% exposed at least one sensitive capability to an attacker, that 9% were classed as high risk, and that 13% accepted input from unverified sources such as emails or web content, which an attacker can use to smuggle in malicious instructions. The same research found the risk compounds as more servers are connected: a setup combining two MCP servers had a 36% chance of producing an exploitable configuration, rising to 92% once ten were combined. Separately, security researchers at JFrog disclosed a critical vulnerability, tracked as CVE-2025-6514 and rated 9.6 out of 10 for severity, in a widely used MCP connector tool: a malicious server could trigger arbitrary command execution on the machine connecting to it, a flaw the maintainer patched once it was reported. None of these findings describe a defective product. They describe what happens, measurably, when integrations multiply faster than anyone is reviewing them.

The three costs an "it's just a connector" framing hides

• Shadow IT, with less friction than before. Every MCP connection a team adds on its own is a system an AI assistant can now reach that procurement and security never signed off on, and the easier the connection is to make, the less likely anyone registers it formally.
• Vendor lock-in by accumulation. A dozen ad hoc MCP connections, each wired up by a different team for a different tool, is a dozen dependencies nobody has mapped. Untangling or migrating any one of them later means first rediscovering that it exists.
• An audit gap, not just a security gap. A public body can usually produce a record of what a conventional software supplier's integration was allowed to do. An ad hoc MCP connection, added without a review, rarely has an equivalent record, which becomes a problem the moment an auditor, a regulator or a freedom of information request asks what an AI system actually had access to.

The governable alternative: review before use, not trust after the fact

None of this is an argument against agent tooling. It is an argument against adopting it the way most organisations currently are, one ungoverned connection at a time. The alternative is a marketplace model: agents and tool integrations are reviewed before they are listed, staff choose from what has already been checked rather than wiring up their own connection from scratch, and the organisation keeps one central, visible record of what it has adopted through that route. That does not make any single integration technically risk-free, and it does not replace a public body's own register of every system it connects to, but it replaces guesswork about a listed agent's provenance with a checked one. Trust Agent (trust-agent.ai), published by Mickai LTD, runs on that model. Mickai's other product, the Sovereign Intelligence Operating System, applies the same principle to the AI deployment itself: an organisation's own hardware, under its own control, rather than a growing, unmapped set of connections into systems it does not own.

What to actually ask before approving an MCP connection

A procurement or security team evaluating a request to connect an AI assistant to a new system does not need to understand the protocol's internals. Five questions cover most of what matters:

• Exactly what data and actions does this connection expose, written down, not as a general description?
• Who maintains the server code behind it, and how are updates and vulnerability disclosures handled?
• Is this connection on the organisation's own register of every MCP integration it runs, or does its existence depend on someone remembering to mention it?
• Can it be revoked centrally and immediately if a vulnerability is disclosed, without relying on the team that originally set it up?
• Is there a log of what the agent actually did through this connection, not only a record of what it was permitted to do?

A connection that cannot get a straight answer to all five is not yet ready for a live system, whatever productivity case is being made for it.

Disclosure

Common Fortune is a Mickai publication. Mickai builds the Sovereign Intelligence Operating System, designed to run AI on an organisation's own hardware, and sells AI-readiness advice at mickai.co.uk/ai-readiness. Naming this here is a disclosure, not a claim of neutrality; the governance questions set out above apply regardless of which vendor or platform a public body ultimately chooses. Trust Agent, also published by Mickai LTD, runs the audited-agent-marketplace model described above and offers free online courses on deploying and governing AI agents at trust-agent.ai.