Model Context Protocol (MCP) in the enterprise – connecting AI to your systems without opening a hole

The problem MCP solves is mundane and expensive. Until recently, every AI tool that needed to reach company data required its own integration: one way for an assistant in a chat platform, another for a development tool, another for your own application. With three systems and three clients, that is nine connections to write and maintain.

MCP inverts the arrangement. You expose the system once – as an MCP server that declares its tools (actions to perform), resources (data to read) and prompt templates. Any standard-compliant client can consume it with no extra work. Nine connections become three servers.

What MCP does not solve: it does not clean up your data, it does not replace the permissions layer, and it does not make the model understand your process. An MCP server over a messy customer file gives the agent convenient access to the mess. Nor is it free to run – it is another component to version, monitor and update whenever the underlying system's API changes.

The practical break-even looks like this: a single stable connection between one system and one application is usually cheaper to build classically. MCP starts paying off with the second client or the third system – and then it pays off quickly, because the cost of every further combination falls close to zero.

The architecture has three elements, and it is worth keeping them apart, because they are what get confused most often in security discussions.

The host is the application a person uses – an assistant in a browser, a development tool, your own application with an embedded model. The host decides which servers are available at all and shows the user what is happening.

The client is the layer inside the host that holds the connection to a specific server and translates between the protocol and the model. The server is the component on the system side – it exposes the list of tools and resources and executes calls. A server can run locally, next to the application, or remotely as a network service; the latter is more convenient and accounts for most published incidents.

One detail is easy to miss: the description of every tool – its name, purpose and parameter descriptions – enters the model's context as text. The model reads it and treats it as an instruction. Which means whoever controls the tool description partly controls the agent's behaviour. The entire class of attacks known as tool poisoning derives from exactly this property.

First: working with documents and knowledge. An MCP server over a document repository exposes permission-aware search, content reads and metadata. The gain is that the same layer serves an intranet assistant, a chat assistant and a proposal-drafting tool – without three separate search implementations.

Second: operational data from ERP and CRM. Here the MCP server is a convenient place to enforce rules: you expose not „the database” but a specific list of operations – check stock, fetch order status, prepare a draft order. The permission scope is then stated explicitly, in one place, instead of being scattered across the prompts of several applications. That is good practice regardless of how many AI clients actually consume it.

Third: analytics. A server exposing defined metrics and queries is safer than an agent writing arbitrary SQL against a production warehouse – and it delivers one binding definition of every indicator as a by-product. It is the same mechanism we describe under the semantic layer in conversational analytics.

The common thread across all three: an MCP server is where you decide what is allowed, not merely how to connect. Designed as a list of permitted actions, it works as a safeguard. Designed as universal database access, it is just a more convenient route to the same problems.

The OWASP list for MCP organizes the risks around five patterns worth knowing by name, because they show up in vendor documentation and in conversations with security teams.

Confused deputy is a situation where a server holds broad permissions and executes an operation on behalf of somebody who does not have them – because the server cannot tell whose authority it is acting under. Token passthrough means forwarding a user token upstream instead of performing a proper OAuth 2.0 exchange; the result is a token circulating through systems that were never meant to see it.

Tool poisoning exploits what we described above: malicious instructions placed in a tool's metadata. In April 2025 Invariant Labs published a working demonstration in which an innocuous-looking maths tool exfiltrated SSH keys. SSRF through connectors is the classic abuse of a server as a proxy to internal network resources. Rogue server registration relies on weak session binding and missing attestation – the agent connects to something claiming to be a known server.

On top of that come incidents from real deployments. The most frequently cited is the Postmark MCP server of September 2025, which silently sent a hidden copy of every agent-dispatched email to a domain the attacker controlled – behaviour invisible to the user and undetectable without traffic analysis. A scan of more than 500 publicly reachable servers found 38% with no authentication at all. These are not theoretical risks; they are the consequence of a component that is easy to launch being launched without review.

On 28 July 2026 a new specification version took effect, prepared from May onwards. The most important change is architectural: the protocol became stateless at its own layer, delivered through six related change proposals. The practical effect is that servers can be run in cloud environments like any other service – horizontally scaled, with no session pinned to an instance.

Older versions have a 12-month deprecation window. For a company with MCP integrations running today, that means a concrete date in the calendar for review and migration – and a good moment to settle the things that were deferred during the first deployment.

The new version brings its own risks worth knowing before migration: predictable identifiers can allow a workflow to be hijacked; careless mapping of inputs onto headers can push API keys and personal data straight into request headers; long-running tasks create a denial-of-service vector through cost asymmetry; and interface extensions open classic browser-side risks. The common thread: security has moved from the protocol into implementations and platforms.

The checklist for admitting an MCP server to production comes down to seven questions. Who publishes the server and is it on your approved vendor list. Is authentication required and delivered through token exchange rather than passthrough. What is the narrowest possible permission scope for this use case. Have the tool descriptions been reviewed by a human. Do calls reach a log with user identification. Is the server exposed to the internet, and does it need to be. Who owns updating it when the protocol version changes.