What is MCP (Model Context Protocol)? A plain-English guide to AI's newest integration risk

Ask an AI agent to check a calendar, read a spreadsheet, or open a support ticket, and something has to carry that request from the model to the actual tool. Through 2025 and into 2026, the thing doing that carrying has increasingly been a single open standard: the Model Context Protocol, or MCP. It has spread fast because it solves a real problem. It has also opened a new kind of door into company systems that most organisations have not yet thought to check.

The plain definition

MCP is an open protocol that lets an AI assistant or an autonomous agent connect to outside tools, files, databases and services through one common interface, rather than a custom integration built for every tool it might ever use. Three parts work together: the client, the AI assistant or agent making requests; the server, a small program that exposes a particular tool or data source, a calendar, a code repository, an email inbox, a database, and translates requests into whatever that tool actually needs; and the connection between them, which carries instructions and data back and forth.

The appeal is obvious. Instead of writing bespoke code every time an agent needs to touch a new system, a developer points it at an MCP server and the agent can use that tool immediately. A large and fast-growing number of MCP servers now exist across public registries, covering everything from source-code hosting to email to internal databases.

Why it is an audit problem, not just an integration problem

Every MCP server an organisation connects is a new, often unaudited integration point into its data and systems. The server was usually written by someone outside the organisation. It typically runs with far more access than a human would be given for the same task, because the whole point is letting the agent act without a person approving each step. And because an MCP server can change its own behaviour between sessions, a connection reviewed once last month is not guaranteed to be the same connection today.

That combination, broad access, outside authorship and behaviour that can shift without notice, is precisely what an audit process exists to catch. Most MCP servers have never been through one.

What has already gone wrong

This is not a theoretical risk. Three documented cases from 2025 show the pattern.

• A command-execution flaw in a widely used MCP proxy. In July 2025, security researchers at JFrog disclosed CVE-2025-6514, a critical flaw (CVSS 9.6) in the mcp-remote package. A malicious MCP server could send a crafted authorisation link during login that triggered arbitrary command execution on the connecting machine, simply because the client trusted a value it should have checked.
• A malicious package hiding inside a legitimate tool. Researchers reported that the postmark-mcp package on npm was modified to quietly blind-copy every email it sent to an attacker-controlled address. The compromised version shipped on 17 September 2025 and was not pulled until 25 September 2025, as documented by Snyk. The change was a single added line of code; in that window, anything sent through it, invoices, password resets, internal mail, was copied straight to the attacker.
• A private-data leak with no simple fix. In May 2025, researchers at Invariant Labs showed that GitHub's own MCP server could be tricked into leaking private repository data. A booby-trapped public issue, once read by an agent with access to both public and private repositories, could coerce that agent into copying private information into a public pull request. As the researchers noted, the flaw could not be closed with a server-side patch alone: it needed architectural limits on what a single agent session is allowed to touch.

None of these were failures of the underlying AI model. Each was a failure of the integration layer around it, the exact layer MCP is built to standardise.

The model is often the most reviewed part of the stack. The integration that connects it to real data is frequently the least reviewed part, and it is the part with the access.

What a sovereignty-first approach to MCP looks like

None of this means avoiding MCP. It means treating every server the same way a sovereign AI system treats everything else: nothing gets access without being checked first.

• Has this specific MCP server been reviewed, by someone other than the people who wrote it?
• What is the smallest set of permissions it can run with, and is it actually running with that set?
• Can its behaviour change without triggering a new review?
• Is there a record of what the agent actually did through that server, one that can be checked afterwards without relying on the server's own logs?
• If this one connection were compromised tomorrow, what is the actual blast radius?

Governance, not blind trust

This is the gap an audited marketplace is built to close. Trust Agent lists AI agents and the integrations behind them only after they have been through an audit, rather than asking an organisation to take a vendor's word for it. Alongside that, it runs a set of online, browser-based courses on AI governance and security, each ending in a completion certificate, with downloadable workbooks offered as a companion resource rather than the product itself. The certificate confirms the course was completed; it is not a professional accreditation.

That is the same instinct behind a Sovereign Intelligence Operating System: do not assume a component is safe because it is popular, or because it ships from a familiar-sounding source. Check it, record what it does, and keep the ability to verify that record without having to trust the component's own word for it. MCP made agent integrations easy. The incidents above show what happens when easy gets mistaken for audited. They are not the same thing, and 2025 supplied the evidence.

That is MCP: a genuinely useful standard, and a new integration point that deserves exactly the scrutiny it has mostly not had yet.