MCP Security for Businesses: A Practical Guide to Governing AI Connections

AI assistants are becoming more useful because they can connect to the systems where work happens. Through the Model Context Protocol (MCP), an employee may let an AI client read a code repository, search a project workspace, query a database or interact with a business application. That convenience also creates a new security question for Hong Kong organisations: who approved each connection, what can it access, and what information can leave the device?

In its 3 November 2026 security checklist, dope.security examines the risks around MCP servers used by employees and separates the problem into two parts: securing the servers an organisation operates, and governing the external servers that employees connect to from their own AI clients. That distinction is useful for buyers because endpoint controls and server-side controls solve different problems.

Why MCP changes the security conversation

MCP gives AI clients a standard way to call tools and retrieve information from connected services. A developer might connect an assistant to GitHub and Jira; an analyst might connect it to a data warehouse; a sales team might connect an agent to a CRM. Each connection can carry credentials and permissions that reach real business data.

The risk is not limited to a malicious prompt. A server may be poorly authenticated, a token may have excessive scope, a tool description may be manipulated, or untrusted output may influence an agent to perform an unsafe action. If tool calls are not logged with user and application context, an investigation may struggle to establish what happened.

The US National Security Agency’s May 2026 guidance on MCP warns that agentic workflows introduce systemic risks involving trust boundaries, dynamic tool invocation and context sharing. OWASP’s MCP Top 10 also highlights risks such as prompt injection through contextual payloads, insufficient authentication and authorisation, and weak audit telemetry. These are practical design concerns, not reasons to ban every AI integration.

Two security layers: the server and the employee device

For MCP servers that the organisation owns, security starts with strong authentication and narrow permissions. Use OAuth 2.1 and PKCE where appropriate for remote access, validate token audience, avoid passing tokens through to downstream services, and grant only the scopes required for the task. Keep internal servers off public networks unless exposure is necessary and properly protected.

Tool execution should be sandboxed, inputs should be validated against strict schemas, and outputs should be treated as untrusted content. Keep server software and dependencies under change control, review the source and provenance of third-party MCP projects, and record the identity behind tool and model invocations. These controls reduce the chance that a compromised integration can reach unrelated systems.

The second layer is the client side. Employees may connect to MCP servers that the company does not operate, including vendor-hosted services and community projects. IT cannot directly harden every external server, but it can decide which managed devices may connect to them and what information is allowed to leave the endpoint.

dope.security describes its endpoint agent as identifying outbound MCP connections by user and process, allowing security teams to discover connected endpoints and apply allow, warn or block policies. The company also describes using Dopamine DLP to inspect information sent by AI tools. Buyers should validate these claims in a pilot, including the applications and operating systems they actually use.

Why a DNS-only inventory is not enough

A domain list can show that a laptop contacted a cloud service, but it may not reveal which local application initiated the connection or which user was responsible. A browser-only control may miss native desktop clients, coding assistants, command-line tools or scripts. A cloud proxy can inspect traffic routed through it, but unmanaged routes, certificate-pinned applications and tunnel exceptions can create blind spots.

This does not mean that DNS filtering, browser controls or cloud proxies have no value. They remain useful layers for other security objectives. The buying question is whether the organisation can account for the AI clients and MCP connections that operate outside those layers, and whether its chosen controls can enforce policy without disrupting legitimate development work.

Hong Kong privacy and data-governance considerations

MCP connections can expose personal data, customer records, source code, financial information and confidential business documents to external services. Hong Kong organisations should therefore assess the purpose of each integration, the information it can access, the parties that process it and the retention arrangements that apply.

The PCPD’s 2026 guidance on protecting personal data privacy in the use of agentic AI reinforces that existing personal-data obligations remain relevant as AI systems become more autonomous. A practical governance process should document approved use cases, assess privacy and security risks before deployment, minimise the data and permissions made available to an agent, and retain appropriate human oversight for higher-impact actions.

For businesses with regional teams or Greater Bay Area workflows, review where data is sent and processed, who can administer the service, and whether the vendor’s data-flow documentation matches the organisation’s contractual and operational requirements. Do not assume that an AI tool’s user interface tells the full story of where connected data travels.

What Hong Kong buyers should test in a pilot

• Coverage: Can the control identify MCP traffic from browsers, desktop AI clients, IDEs and command-line tools used by your teams?
• Attribution: Can an alert be tied to a specific user, device, process and destination?
• Policy: Can administrators approve known endpoints, warn on unreviewed services and block prohibited connections by group?
• Data protection: Can the product inspect prompts or uploads where supported, and can you define what is monitored or blocked?
• Server-side controls: Does the solution complement rather than replace OAuth, scope management, sandboxing and logging on MCP servers you operate?
• Evidence: Can relevant events be exported to your SIEM and used in an investigation or internal audit?
• Operational fit: What happens when an application uses certificate pinning, a device is unmanaged, or a user works remotely?
• Privacy: Which fields are inspected or transmitted for classification, where are they processed, and how long are they retained?

Ask the vendor to demonstrate a realistic workflow rather than relying only on a feature checklist. For example, connect a test AI client to an approved repository and an unapproved external MCP endpoint, then verify the alert, policy decision, audit record and user experience.

A practical 30-day MCP control plan

Days 1–7: Discover. Select a representative pilot group from engineering, analytics and business operations. Inventory the AI clients and MCP endpoints they use. Identify the data sources and permissions associated with each connection.

Days 8–14: Classify. Mark integrations as approved, conditionally allowed or prohibited. For servers operated internally, review authentication, token scopes, network exposure, code provenance and logging. Assign an owner to every approved integration.

Days 15–21: Enforce carefully. Begin with monitoring and warning policies. Remove unnecessary permissions, block clearly unauthorised endpoints, and test DLP policies with representative prompts and files. Tune exceptions with application owners rather than creating broad bypasses.

Days 22–30: Prove and review. Send useful events to the SIEM, test the incident-response process, document residual risks and agree a review cadence. Revisit access when employees change roles, projects end or an external service changes its permissions.

Choose governance that supports useful AI

For Hong Kong IT leaders, the objective is not to stop employees from using every AI assistant. It is to make connected tools visible, keep permissions proportionate and prevent sensitive information from flowing into unapproved destinations. Server-side hardening protects the services an organisation runs; endpoint governance helps control the services its people connect to.

dope.security positions its platform around endpoint visibility, policy enforcement and data-loss prevention for AI activity. Treat that as a candidate architecture to validate against your own environment. The strongest buying decision will be based on a measured pilot, clear data-handling answers and evidence that the controls cover the AI workflows employees actually use.