Three letters have started showing up in places executives cannot ignore. A vendor announces Model Context Protocol (MCP) support in a release note. An engineer asks for approval to connect an AI assistant to the ticketing system "over MCP." A board member reads the term in a trade publication and asks whether the company has a position on it. The question I get in those conversations is usually some version of "should we allow this," and it is the wrong first question. The right one is “what does MCP actually do,” because most of the anxiety and most of the enthusiasm I hear comes from the same mistaken picture of it.

My goal with this blog post is to give you the plain version of what it is (and isn’t). I’ll also dig into the part that matters for governance. But first, four foundational terms, because the vocabulary is where most people get lost. And for pretty understandable reasons: Vendors use these terms interchangeably and so does the press.

Four Terms

• AI application. The product a person opens and types into: Claude, ChatGPT, a coding tool, a support chatbot your team built.
• Model. The reasoning engine behind the AI application. The application passes your request to the model and shows you what the model sends back. This is what can sometimes get confusing, because users can often choose which model an application uses. Use the Claude application and you can pick between Opus, Sonnet or Haiku as the model you want Claude to use. Think of the application as a video game console and the model as game cartridges. Without a game inserted, the console turns on but you can’t do anything useful. Swap the cartridge to change the world, rules and logic of what you’re able to do, even though you’re plugged into the same game console. The confusion is mostly branding. Claude is the name of the application and is often used as a catch-all for the models inside it (Claude Opus, Claude Sonnet, Claude Haiku; all summarized and described sometimes as “Claude” as well). Gemini and ChatGPT work the same way.
• Protocol. A common language that allows two pieces of software to talk to each other without either being built for the other. A good example in this context is email, which uses Simple Mail Transfer Protocol (SMTP). You can use any email application you’d like and it can communicate with a recipient using a totally different email application thanks to SMTP. MCP is another type of protocol. More on that below.
• Server. Not a machine in a rack. In this discussion, a server is a small program that sits in front of one business system, such as your ticketing system or your file share, and speaks that system's own language on one side and MCP on the other. The things it makes available are called tools. Vendors increasingly call the whole package a connector.

What MCP Actually Is

The Model Context Protocol (MCP) is a standard for connecting an AI application to the systems that hold your data and perform your work. It was published by Anthropic in late 2024, and the other major AI vendors have since adopted it, which is the only reason it deserves an executive's attention rather than an engineer's. 

Think of it like an electrical outlet. It has a standard size and voltage. Any toaster or lamp built to the standard works in any building that has one of those outlets, and neither the appliance nor the outlet had to be custom-made for the other. MCP does the same job for AI: it settles how an application connects to a system and how information moves once they are connected. Nobody has an opinion about the outlet standard in their building, and in a few years nobody will have one about MCP either. The opinions that matter are about what gets plugged in.

The problem MCP solves is unglamorous and expensive. Before it, every connection between an AI application and a business system was custom work. Connecting your assistant to Jira was a project. Connecting a different assistant to the same Jira was a second project. Ten applications and ten systems meant a hundred integrations, each written once, maintained forever and understood only by whoever happened to build it. A common protocol turns that hundred into twenty. That is the entire value proposition, and it is a real one.

Every MCP connection has three pieces: the application, the model and the server. The server publishes a menu of what it offers, which for our purposes comes down to actions it can take and data it can read. The model reads that menu and decides, on its own, which items to call when the application sends it a request.

That last sentence is the whole governance story, and I will come back to it.

In most products you never see these seams. The application, the model and its connectors arrive as one thing, which is why most people's picture of AI is still a single chat window. MCP is what lets anyone add a new connector to that picture. The engineer in the first paragraph, asking to plug the assistant into the ticketing system, is asking to add one, and the moment it is added, the seams are what matter.

What MCP Is Not

It is not intelligence, and it does not make the model better. MCP is a connector standard. It changes what a model can reach, not how well it reasons. If an AI pilot (i.e. a user) is disappointed because the model gets things wrong, MCP will not fix it. It will let the model get things wrong against more of your systems, faster.

It is not a security control. This is the most common misreading I encounter, usually in the form of "we're doing it over MCP" offered as reassurance. The protocol defines how a connection is made, and for remote servers it includes a standard way to handle authorization. It does not decide what the model should be allowed to do once connected. It carries whatever permissions you gave the credential behind the server, and it has no idea which of your records are sensitive. If the service account you handed it can read every customer file, so can the model, and so can anyone who can influence what the model decides to do. Least privilege is not a default here. It is something you have to impose.

It is not a product you buy, and it is not a switch you can turn off centrally. MCP is an open specification, and a competent engineer can write a working server for an internal system in an afternoon. That is why it spread so quickly, and it is why "do we allow MCP" is not really a decision you get to make once. In the environments I look at, the servers are already there. Some were downloaded by developers from public code repositories, some were written in-house, and often, the security team doesn’t know about either category. If you have an AI tool policy that does not mention this, your actual policy is whatever your engineers decided individually.

It is not an audit trail. When a model calls a tool through MCP, nothing about that call is recorded unless someone built the recording. Your security monitoring sees an outbound connection and nothing else. The prompt that led to the action, the data the server returned, the action it took and the result all pass through a layer that logs nothing by default. That gap is fine right up until the morning you need to answer how your data got leaked, and then it is the whole problem.

It is not a boundary. A local MCP server is a program running on someone's machine with that person's access, usually downloaded from a public code repository, and often reviewed by no one. The protocol does not sandbox it. This is ordinary software supply-chain risk wearing new clothes, and it deserves the same scrutiny you would give any other dependency that holds a credential.

The Part That Matters

Strip away the acronym and the substance is this: MCP turns AI from a chat window that produces text into an active participant in your environment, holding credentials, reading records and taking actions. That transition is where the word "agent" comes into play, and where an important governance decision gets made, sometimes without anyone realizing it. It’s like granting a new integration a service account, and it deserves the same treatment: a named owner, a scoped credential, logging you control and a review that happens before the connection rather than after an incident.

The organizations handling this well are not the ones that block MCP. They are the ones that recognize what class of thing it is and apply controls they’re already using effectively.

Three questions to take to your next risk discussion:

• Which AI systems in the organization can currently reach internal data or take actions through a connector, and who approved each one?
• For each of those connections, whose credentials are behind it, and do they have excessive permissions?
• If one of them does something unexpected, do you control the records to reconstruct it?

If you can answer all three, MCP really is electrical work, and you can leave it to the engineers. If you cannot, the acronym was never the problem.

‍

Published By: Chris Neuwirth, VP of Cyber Risk, NetWorks Group

Publish Date: September 3, 2026

‍