AI just standardised how it plugs into everything.
For two years the hard part of putting AI to work was not the model. It was the wiring. Every time you wanted a model to read your documents, query your database or use a tool, someone had to build a custom integration, and every integration was bespoke, brittle and one more thing to maintain. That problem is now largely solved, and the solution has a name most leaders have started hearing without quite knowing what it is. The Model Context Protocol, or MCP, is the standard that lets AI connect to the systems where your data and tools live. In eighteen months it has gone from one company's idea to something close to industry plumbing, and that shift quietly changes the most important question an organisation should be asking about AI integration.
The question is no longer whether to connect AI to your systems. The protocol has made that easy, and your people are already doing it. The question is whether you can see and govern the connectors, because each one is a new door into your data, and most organisations have no idea how many doors they have opened.
What MCP actually is
Anthropic introduced the Model Context Protocol on 25 November 2024, describing it as "a new standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments." The problem it set out to solve is the one every integration team knows. Sophisticated models were trapped behind a wall of custom connectors, each built separately for each data source, none reusable. MCP replaces that mess with a single protocol, so that any AI client that speaks MCP can connect to any system that exposes an MCP server, without a fresh bespoke build each time.
The useful analogy is a universal port. Before, every device needed its own cable. MCP is the equivalent of agreeing on one connector, so a model and a tool can talk without a custom adapter in between. A model is the client. The systems it reaches, your files, your ticketing system, your database, your code repository, run small MCP servers that expose what the model is allowed to use. The protocol carries the conversation.
What makes this matter is that the industry agreed. A standard is only worth anything if everyone adopts it, and they did, fast. OpenAI adopted MCP across its products, including the ChatGPT desktop app, in March 2025. Google followed with its DeepMind models in April 2025. Microsoft built it into its agent tooling, and Cloudflare and others moved to host it. In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, putting the standard under neutral, open governance rather than one vendor's control. By late 2025 the project reported more than 10,000 public MCP servers in its registry. A protocol with that breadth of adoption is no longer a bet. It is the default.
Why it actually matters
The significance is not the protocol itself. Protocols are plumbing, and plumbing is boring by design. The significance is what the plumbing enables and what it exposes.
On the capability side, MCP is what makes the current wave of useful AI agents possible. An agent that can only chat is a novelty. An agent that can read your real documents, check a live system and take an action is a tool, and MCP is how it reaches those things without a developer hand-building each connection. The agent platforms making news this year, the control planes for discovering and running agents across clouds, all sit on top of this kind of standardised connection. If you are evaluating any agentic AI capability, you are, whether the vendor says so or not, evaluating MCP connectors underneath.
On the exposure side, every connector is a grant of access. An MCP server that lets a model read your document store has been given the keys to that store. One that can act in a system can change things in that system. Multiply that by a model's ability to chain tools together, where the output of one connector becomes the input to the next, and a single AI assistant with a handful of connectors has a reach across your environment that no individual employee would be granted without a access review. That is the part most organisations have not caught up to. They are thinking about which AI model to use while their people quietly attach connectors that open real doors.
The enterprise question has shifted
The early phase of MCP was about proving the standard could attract developers. It did. The current phase is about operationalising it inside organisations that have real security and compliance obligations, and the tooling has started to catch up. In June 2026 the protocol's Enterprise-Managed Authorization extension reached stable status. As the MCP project describes it, the extension lets organisations "centrally provision MCP server access through their identity provider so users get connected servers on first login without per-app OAuth," and "control MCP server access centrally through their trusted identity provider." In plain terms, an organisation can now decide, in one place, which connectors its people are allowed to use, rather than each employee wiring up their own.
That is the difference between MCP as a developer convenience and MCP as governed enterprise infrastructure. The capability to centrally manage connectors exists now. Whether an organisation uses it is a choice, and the organisations that do not will keep accumulating connectors nobody approved.
The hype check
Two things are oversold, and a leader should hold both lightly.
The first is the idea that MCP makes AI integration safe. It standardises integration; it does not secure it. In April 2025, security researchers analysing the protocol found multiple outstanding security issues, including prompt injection and poisoned tools that allow for data exfiltration through other connected tools. The mechanics matter. Because a model can be steered by the content it reads, a malicious document or a compromised connector can instruct the model to misuse the other connectors it has access to, turning a benign-looking tool into a path for data to leak. A standard connector is still a connector, and the easier it is to attach one, the easier it is to attach a bad one.
The second oversold idea is that adopting MCP is a strategic decision an organisation gets to make deliberately. For most, the decision has already been made by their staff. The major AI clients people already use speak MCP. The connectors are a few clicks away. Treating MCP adoption as a future board decision misreads where things are. The realistic posture is not whether to allow it but how to see and govern what is already happening.
The connector supply chain
There is a dimension to this that the convenience hides. When a developer or an employee attaches a connector, they are often pulling it from a public registry of thousands of community-built servers. That registry is a supply chain, and supply chains carry supply-chain risk. The maturing of MCP is now less about proving the standard works and more about the unglamorous problems of operating it at scale: registry governance, namespace trust, the reliability of hosted servers, and the review of whether a given tool is safe to use. A connector named to look like an official integration may not be one. A popular community server may be well built or may be quietly hostile. The ease of attaching a connector is exactly what makes the provenance question easy to skip.
This is the same lesson software learned the hard way with open-source package registries. A vast ecosystem of reusable components is a gift and an attack surface at once, and the organisations that came through it well were the ones that decided what they would pull from where, and checked. MCP connectors deserve the same posture: a known source, a reason to trust it, and a record of the decision.
What to do about it
The work is connector governance, and it looks a great deal like the third-party and access governance disciplines an organisation should already have. Four moves.
Inventory the connectors. Find out what MCP servers your AI tools are actually connected to. This is the step almost nobody has done, and it is the one that turns an abstract risk into a list you can manage. You cannot govern doors you cannot see.
Scope to least privilege. A connector should expose only what the task needs. A model that needs to read a folder does not need write access to the whole repository. Review what each connector can do, not just what it is used for, because the gap between the two is where the risk lives.
Manage authorisation centrally. Use the enterprise controls that now exist. Provision approved connectors through your identity provider so access is granted, reviewed and revoked in one place, rather than letting each person attach their own. The Enterprise-Managed Authorization capability exists precisely so this is possible.
Review the tools, not just the access. Before a connector is approved, someone should assess what it is and where it comes from, the same way you would assess any third party given access to your systems. A connector from an unknown source is an unknown party with a key.
For Australian regulated organisations, this maps directly onto obligations already in force. A connector that wires AI into a core system is part of your information security surface, squarely within the kind of control APRA's CPS 234 expects, and where it reaches a system the business depends on, it starts to look like the material service arrangements CPS 230 asks you to identify and manage. The framing that keeps this sane is simple. An MCP connector is not a feature. It is third-party access, and it deserves the inventory, the scoping and the review that any third-party access gets.
This is not only a security team's problem, which is part of why it gets missed. The person attaching a connector is usually a developer chasing a useful capability or an employee trying to get work done, not someone thinking about access governance. The person accountable for the exposure is a CISO, a head of model risk or a line leader who often does not know the connector exists. Closing that gap is a leadership task as much as a technical one: someone has to own the list, and own the rule that connectors go through it.
The Model Context Protocol is a genuine advance, and the standardisation it brought is worth understanding. But the lesson for anyone deploying AI is not that integration got easy. It is that integration got easy, which means the doors got cheap to open, which means the only thing standing between a useful agent and an ungoverned sprawl of access is whether someone is keeping the list. Be the organisation that keeps the list.
TheAICommand. Intelligence, At Your Command.
