By the end of this guide you will be able to define an MCP gateway in one sentence, explain to your CISO why agent pilots stall without one, and ask any vendor five questions that separate a governed deployment from an unmanaged one.
That matters this quarter because the connection layer under enterprise AI agents has quietly become the layer where the risk lives.
What is an MCP gateway?
An MCP gateway is a single controlled entry point that sits between your AI agents and every Model Context Protocol server they call. It authenticates the request, checks which tools the caller is allowed to use, logs the call, and routes it onward. Think of it as an API gateway for agent tool access.
The Model Context Protocol itself, released by Anthropic and now supported across most major model providers, is a standard way for a model to discover and call external tools: a CRM, a file store, a ticketing system, an internal database.
The protocol solved the integration problem. It did not solve the control problem. The gateway is what enterprises add to close that gap.
Why did MCP need a gateway layer in the first place?
MCP was designed for a single developer connecting one model to a few tools on a laptop. Enterprise deployment inverts every assumption: hundreds of users, dozens of servers, shared credentials, audit obligations. Without a central chokepoint, each agent holds its own connection and its own secrets, and nobody can answer who called what.
The scale is no longer theoretical. Analysis published by Digital Applied in 2026 puts MCP deployment at roughly 28% of Fortune 500 companies, with 41% of surveyed software organisations running MCP servers in limited or broad production.
The same analysis cites CData's estimate that 30% of enterprise application vendors will ship an MCP server during 2026. The official MCP Registry API held 9,652 current server records as of 24 May 2026.
The structural problem in one line
A protocol that assumes a trusted local operator is being deployed into environments where the operator is a non-deterministic model acting on behalf of hundreds of employees.
How does an MCP gateway actually work?
A gateway intercepts every tool call and applies four controls before the call reaches its destination. It binds the call to a real human or service identity, checks that identity against an allowlist of permitted tools, writes an audit record, and pauses high-impact actions for human approval. Only then does the call proceed.
The four control functions map directly onto controls your security team already operates for APIs.
--- Identity binding. The call carries a verified user or service identity through SSO or OAuth, rather than a shared service account that makes attribution impossible.
--- Tool allowlisting. Finance agents can read the ledger and cannot write to it. The permission lives in the gateway, not in a prompt that a user can talk their way around.
--- Audit logging. Because MCP standardises the tool-call payload format, a gateway can log every call in one consistent schema across every server.
--- Human-in-the-loop approval. Actions above a defined threshold, such as issuing a refund or deleting a record, queue for sign-off instead of executing silently.
Gateway patterns are now on the protocol's own roadmap rather than being purely a vendor invention. Priority work through 2026 has centred on stateless streamable HTTP transport for load-balancer compatibility, retry and expiry semantics for long-running tasks, and enterprise readiness features including audit trails and SSO-integrated authentication.
What has gone wrong for organisations without one?
The public incident record is specific enough to be uncomfortable. Three categories dominate: cross-tenant data exposure from flawed access logic, supply-chain compromise of the servers themselves, and credential theft through registry infrastructure. Each was a control failure at the connection layer, not a model failure.
Cross-tenant exposure. In June 2025, a logic flaw in Asana's MCP server exposed project names, task descriptions and metadata across separate customer tenants for roughly two weeks, with over 1,000 customers potentially affected, according to Asana's own disclosure and subsequent analysis by UpGuard.
Registry supply chain. GitGuardian identified a path-traversal flaw in Smithery's build configuration that would have allowed an attacker to build images from the builder's home directory and exfiltrate credentials, exposing roughly 3,000 MCP servers.
Volume of disclosed flaws. Security reporting catalogued more than 30 MCP-related CVEs filed in January and February 2026 alone, including CVE-2025-49596 at CVSS 9.4 and CVE-2025-6514 affecting a package with over 437,000 downloads.
For context on why identity is the recurring theme, see our explainer on agent identity and the governance gap behind every AI agent.
What do Hong Kong regulators expect from agent deployments?
Hong Kong has no single AI statute. Obligations flow from the Personal Data (Privacy) Ordinance, PCPD guidance, and sector rules from the HKMA and Insurance Authority. The PCPD has moved from publishing frameworks to actively checking compliance, and its March 2026 alert on agentic AI reads almost like a gateway specification.
According to Mayer Brown's mid-year 2026 review of AI regulation in Singapore and Hong Kong, the PCPD launched compliance checks on 60 organisations in January 2026 and published results in May 2026. Those results found 95% of the organisations using AI in day-to-day operations, with over half running three or more AI systems.
No PDPO contraventions were found. The PCPD nonetheless recommended governance structures, privacy impact assessments, AI audits, staff training and incident-response plans.
The March 2026 agentic AI alert went further, identifying agents that can reach local files, email, credentials, browser contents and external services as an elevated privacy risk. Its practical recommendations were to restrict agents to minimum access rights, avoid administrator privileges, and separate runtime environments from local infrastructure.
Read that list again as an architecture requirement. Minimum access rights is tool allowlisting. Avoiding administrator privileges is identity binding. Separating runtime from local infrastructure is the gateway sitting in between.
How do you evaluate an MCP gateway? Five questions
Five questions separate a governed deployment from a demo. They test whether the gateway can answer for itself under audit, not whether it works on a happy path. Ask them in the vendor session and ask for evidence rather than assurance on each one.
--- Question one: can you show me the log of a single tool call, end to end? If the answer involves stitching together three systems, you do not have an audit trail. You have fragments.
--- Question two: which identity does the downstream system see? If every call arrives as one service account, you cannot investigate an incident and you cannot satisfy a PDPO enquiry about who accessed what.
--- Question three: how do I add a server, and who approves it? A registry with an approval workflow is the difference between a governed catalogue and shadow AI. With over 10,000 public MCP servers available, self-service installation is the default failure mode.
--- Question four: what happens when a tool call is ambiguous or fails? Retry semantics and expiry policy matter because agents retry aggressively. Ask what stops a retry loop from issuing the same transaction four times.
--- Question five: what is the blast radius of one compromised server? If the answer is anything other than a bounded set of allowlisted tools for a bounded set of identities, the architecture is inherited risk.
What does this look like in practice?
Two Hong Kong scenarios show why the gateway decision arrives earlier than most leaders expect. In both cases the agent works in the pilot and stalls at the security review, because the pilot connected directly and the production architecture cannot.
A mid-sized financial services firm. An operations team pilots an agent that reads client records and drafts responses. The pilot uses one API credential with broad read access. At the pre-production review, the second line of defence asks which staff member's authority each read was performed under. There is no answer, and the project pauses for a quarter.
A logistics group with legacy systems. An agent connects to a warehouse management system, a customs broker portal, and a finance package. Three teams own three credentials. Nobody owns the question of what the agent may write. The gateway is added not for security theatre but because it is the only place a single write policy can exist.
Published production numbers suggest the payoff is real once the control layer exists. Pinterest's MCP ecosystem, documented in March 2026, recorded roughly 66,000 monthly tool invocations from 844 active users, with an estimated 7,000 hours saved per month.
If you are also weighing platform-level options, our explainer on what OpenAI Presence is and how enterprise agent platforms are structured covers the adjacent build-or-buy question.
What goes wrong when organisations attempt this without guidance?
Four failure patterns recur. None of them are technical exotica. They are sequencing errors, where a decision that belongs at the start of the project gets made by default in month five, and the cost of reversing it is a rebuild rather than a configuration change.
Pitfall one: treating the gateway as a phase-two item. Retrofitting identity binding after agents are live means rewriting every integration. Deciding it first costs a week of architecture time.
Pitfall two: allowlisting by prompt instead of by policy. A system prompt that says the agent must not delete records is a suggestion. A gateway that never exposes the delete tool is a control.
Pitfall three: no named owner. Governance guidance published across 2026 converges on the same point: accountability diffuses across data, MLOps, security and domain teams unless one named executive holds documented decision rights before agents reach production.
Pitfall four: measuring the pilot on capability alone. A pilot that proves the agent can do the task but produces no audit evidence has not de-risked anything. It has moved the hard conversation later, with more sunk cost attached.
The strategic takeaway
MCP standardised how AI agents reach your systems. It did not decide who is allowed to reach what, or who answers for it afterwards. That decision is architecture, it belongs to you, and it is cheapest to make before the first agent goes live.
The organisations that will move fastest through 2027 are not the ones with the most agents. They are the ones that can explain, in a single log line, what every agent did and on whose authority. That capability is a week of design work at the start and a rebuild at the end.
We understand AI. We understand you. With UD by your side, AI never feels cold. Twenty-eight years of building infrastructure for Hong Kong enterprises has taught us that the boring control layer is usually what decides whether the exciting part ever ships.
Reviewed by the UD enterprise AI team, Hong Kong. Last updated 24 August 2026.
Ready to Map Your Agent Architecture?
Before you choose a gateway, you need a clear picture of where your organisation actually stands: which systems agents would touch, which controls already exist, and which gaps would stop a security review. Start with UD's AI Ready Check. We'll walk you through every step, from readiness assessment and architecture review to deployment and performance tracking, backed by 28 years of Hong Kong enterprise experience.
