By the end of this guide you will know what the Model Context Protocol is, why it appeared on your security team's risk register this year, and the five questions to put to any vendor who tells you their AI agent "supports MCP".
What is the Model Context Protocol (MCP)?
The Model Context Protocol is an open standard that lets an AI model connect to external tools, data sources and business systems through one consistent interface. Instead of building a custom integration for every AI tool and every system, an organisation exposes each system once as an MCP server, and any MCP-capable AI client can then use it.
Think of it as the USB-C port of enterprise AI. Before it, every model-to-system connection was a bespoke piece of engineering. After it, the connector is standard and the work shifts to deciding who is allowed to plug in.
That shift is precisely why the protocol has become a governance question rather than a developer one.
Why is MCP suddenly on every executive agenda?
MCP moved from developer curiosity to board-level topic because adoption outran the controls. Enterprise AI agents are now expected to read from CRMs, ticketing systems and document stores, and MCP is the mechanism doing it. The protocol went from optional to load-bearing in roughly eighteen months.
According to Stacklok's 2026 software report, 41% of surveyed software organisations are already running MCP servers in limited or broad production. That is not a pilot statistic. That is production infrastructure.
CIO magazine has described MCP as being "suddenly on every executive agenda", and the reason is simple: the protocol determines what your AI agents can reach inside your own estate.
For a Hong Kong enterprise running Dynamics, a local HR platform and a document store on-premises, MCP is the layer that decides whether an AI assistant can see employee records. That is an access-control decision, and access-control decisions belong to you, not to a vendor's roadmap.
How does MCP actually work?
MCP has three moving parts: a host application where the user works, a client inside that host, and one or more servers that each wrap a system or data source. The client asks a server what tools it offers, the model chooses one, and the server executes it against the underlying system.
Three concepts are worth knowing at board level.
--- Tools are actions the model can invoke, such as "create a ticket" or "look up an invoice". These are the ones that change things.
--- Resources are read-only data the model can pull in, such as a policy document or a customer record.
--- Prompts are reusable instruction templates a server can supply to standardise how a task is performed.
The critical point for a decision-maker: a tool call is an action taken inside a production system by software acting on a language model's judgement. Everything in your control framework that applies to a human performing that action should apply here too.
Is MCP different from a normal API integration?
Yes, and the difference is who decides what happens. A traditional API integration is deterministic: a developer writes code that calls a specific endpoint under specific conditions. With MCP, the server publishes what it can do and a language model decides, at runtime, which of those things to do.
That single change relocates a control point. In classic integration, the logic lives in reviewed, version-controlled code. In an MCP deployment, part of the logic lives in a model's interpretation of a request.
The practical consequence is that testing changes shape. You are no longer only testing whether an endpoint returns the right data. You are testing whether the agent chooses the right tool when a request is ambiguous, adversarial, or simply badly worded by a tired employee at 6pm.
This is also why the phrase "we have an AI integration" tells you almost nothing. The useful question is whether the model is choosing actions, and if so, what constrains those choices. For a related framing on distinguishing genuine agent capability from marketing language, see what agent washing looks like in practice.
What are the real security risks of MCP?
The security problem is structural rather than accidental. By prioritising developer convenience and unopinionated execution, MCP standardised a very large attack surface, and it did so faster than most organisations built controls around it. Security is now consistently reported as the leading blocker to enterprise MCP adoption.
Four risks matter most to an enterprise leader.
--- Tool poisoning. A malicious or compromised server describes its tools in a way that manipulates the model into taking an action the user never asked for. The instruction arrives as data, and the model treats it as a command.
--- Over-broad permissions. A server is connected with far more access than the task requires, so a single compromise reaches far more than one dataset.
--- Credential exposure in transit. Security assessments have found a significant proportion of MCP servers using plaintext HTTP endpoints, exposing OAuth tokens, API keys and session metadata to interception.
--- Immature supply chain. More than 30 CVEs were filed against MCP-related software in the first two months of 2026 alone. That is the signature of a young ecosystem, not a broken one, but it means you are patching frequently.
The seriousness of this is reflected in who is now publishing guidance. The US National Security Agency issued a Cybersecurity Information Sheet on MCP security design in June 2026, and the Cloud Security Alliance has published agentic MCP security best practices. Protocols do not attract that class of attention unless they are load-bearing.
What changed with Enterprise-Managed Authorization?
Enterprise-Managed Authorization, or EMA, is the MCP extension that hands control of AI tool access back to the organisation's identity provider. It became a stable specification on 18 June 2026, and it is the single most important development for anyone responsible for enterprise access control.
Before EMA, each MCP server asked each user for consent individually. Employees clicked "allow" on screens nobody in IT had reviewed, and the organisation had no central record of which AI agents could reach which systems.
EMA replaces that with a zero-touch flow. During single sign-on, the client exchanges the user's identity token for a grant scoped to one specific target server, using established standards: an OIDC or SAML login, an RFC 8693 token exchange, and an RFC 7523 JWT bearer grant.
In plain terms: your identity provider becomes the authority on which AI agents may reach which systems, using the same policies you already apply to every other application.
Okta is the first supported identity provider, through its Cross App Access capability. Anthropic has implemented EMA across Claude, Claude Code and Cowork, and Visual Studio Code supports it directly in the IDE. Microsoft has published guidance on what Entra ID and App Service can do today.
If your organisation already runs conditional access, EMA means your AI agent estate can finally sit inside that perimeter rather than beside it.
How should an enterprise evaluate an MCP deployment?
Use a four-stage sequence rather than a feature checklist. The sequence works because each stage produces evidence the next stage depends on, and because it fails cheaply if the answer is that you are not ready.
--- Stage 1: Inventory. List every MCP server already connected to an AI tool in your organisation, including ones individual teams enabled without asking. Most organisations are surprised by this list.
--- Stage 2: Classify by blast radius. For each server, record what it can read and what it can change. Separate read-only resources from action-taking tools. A server that can only read a public product catalogue is a different risk from one that can issue refunds.
--- Stage 3: Route through identity. Move access decisions out of per-user consent screens and into your identity provider using EMA, so that offboarding an employee also removes their AI agent's reach.
--- Stage 4: Log and review actions, not just conversations. Most AI logging captures prompts and responses. What an auditor will ask for is the record of tool calls: what action was taken, in which system, on whose authority.
A financial services firm in Hong Kong going through this sequence typically finds that stage two is where the project earns its budget. The inventory is uncomfortable, but the classification is what turns an unbounded risk into a scoped one.
What are the five questions to ask a vendor who says they "support MCP"?
"We support MCP" is a statement about connectivity, not about safety. These five questions separate vendors who have engineered for enterprise deployment from those who have simply enabled a feature.
--- Does your client support Enterprise-Managed Authorization, and with which identity providers? If the answer is per-user consent screens only, your access control is being delegated to your employees.
--- Which of your MCP tools take actions rather than read data, and can I disable them individually? All-or-nothing tool access is not a governance posture.
--- How do you defend against tool poisoning from third-party servers? Look for named mitigations, not reassurance.
--- What is in your tool-call audit log, how long is it retained, and can it be exported to our SIEM? If the log lives only in the vendor's console, your incident response depends on their support queue.
--- What is your patch cadence for MCP components, and how were the 2026 CVEs handled? Past behaviour under pressure predicts future behaviour.
A vendor who answers all five concretely has done the work. One who answers with the word "enterprise-grade" has not.
What goes wrong when organisations get MCP wrong?
The common failures are organisational rather than technical, and they follow a recognisable pattern. Each one is avoidable with a decision taken early rather than a fix applied late.
--- Shadow connections. Individual teams connect MCP servers to production systems without review, because the setup takes minutes and requires no procurement. IT discovers the estate during an incident.
--- Treating agents as users with unlimited hours. An AI agent granted a human's permissions can exercise them thousands of times a day. Rate and scope limits that felt unnecessary for a person become essential.
--- Governance written for chatbots. Policies drafted for AI that only answers questions do not cover AI that takes actions. If your AI policy does not mention tool calls, it predates the problem.
--- No rollback path. Organisations plan how an agent will act and not how to reverse what it did. Define the undo procedure before go-live, not during the first bad week.
--- Compliance as an afterthought. Under Hong Kong's Personal Data (Privacy) Ordinance, the fact that an AI agent moved personal data rather than an employee does not change the obligation. The data user remains accountable, and the PCPD's 2026 agentic AI guidance sets out what regulators now expect to see documented.
Conclusion: the protocol is settled, the governance is not
MCP has won the integration argument. With production adoption above 40%, a stable enterprise authorisation extension, and national security agencies publishing design guidance, the question is no longer whether your organisation will use it.
The open question is whether your AI agents will connect to your systems through your identity provider and your audit trail, or around them. That is a decision made once, early, and it is far cheaper to make deliberately than to retrofit.
Start with the inventory. It costs a week and it tells you where you actually stand.
Technology cycles reward the organisations that build the guardrails while the technology is still young. We understand AI. We understand you. With UD by your side, AI never feels cold.
Reviewed by the UD enterprise AI team.
Where should your organisation start?
Before you connect a single system to an AI agent, you need an honest read on where your organisation stands. We'll walk you through every step, from AI readiness assessment to identity integration, deployment and audit design, backed by 28 years serving Hong Kong enterprises.
