A finance director at a mid-size trading company in Kwun Tong reads the headline over morning coffee: 135,000 OpenClaw instances exposed online, active infostealer campaigns targeting gateway tokens. She had just approved a pilot project to deploy an AI agent for her operations team. Now she is wondering whether to pull the plug.
That reaction is understandable. But the headline deserves context — because the security story around OpenClaw is not about the software being broken. It is about how people deploy it.
What Actually Happened
In February 2026, security researchers at SecurityScorecard and the TRACE team at Bitsight independently identified tens of thousands of OpenClaw instances sitting on the open internet with no authentication. Signal Cage reported over 135,000 exposed instances globally, some actively targeted by Vidar infostealer campaigns designed to steal gateway tokens. A Reddit compilation documented six CVEs and over 824 malicious skills circulating in public skill repositories during the first quarter of 2026 alone.
These are real numbers. They should not be dismissed.
But look at what they describe: self-hosted instances deployed on public cloud servers with default configurations, no firewall rules, and no access controls enabled. In most cases, the operator spun up an OpenClaw gateway on a VPS, left the default port open, and never set authentication. The equivalent would be leaving your office server room door unlocked, propped open, and posting the address online.
Self-Hosted Open vs. Managed Private: Two Different Things
The distinction matters enormously for Hong Kong businesses evaluating AI agent platforms.
Self-hosted open deployment means you install OpenClaw on your own server and expose it to the internet yourself. You are responsible for firewall configuration, TLS certificates, authentication, patching CVEs, and monitoring for malicious skills. If you skip any of those steps, your instance joins the count of exposed systems making headlines.
Managed private deployment means a provider handles the infrastructure, keeps it off the public internet, applies security patches, and configures access controls before you ever log in. Your AI agent runs inside a controlled environment. No open ports, no default credentials, no public exposure.
Every exposed instance in those reports falls into the first category. Not one of the documented incidents involved a properly managed private deployment.
Why This Matters More in Hong Kong
Hong Kong has specific characteristics that make deployment architecture more consequential than in other markets.
First, the Personal Data (Privacy) Ordinance (PDPO) holds data users directly accountable for data breaches. If your AI agent handles client information — emails, documents, contact details — and that data leaks through an unsecured deployment, the company bears responsibility. The Office of the Privacy Commissioner for Personal Data has been increasingly active in enforcement actions, and "we used an open-source tool" is not a defence.
Second, many Hong Kong SMEs operate in regulated industries. Insurance brokers licensed by the SFC, law firms governed by the Law Society, medical practices under the Medical Council — all have professional obligations around data handling that go beyond the PDPO. An exposed AI agent that processes client communications could trigger regulatory consequences beyond a privacy breach.
Third, Hong Kong's position as a cross-border business hub means AI agents here often handle data that touches multiple jurisdictions. A trading company's agent might process emails from mainland suppliers, Southeast Asian logistics partners, and European buyers in a single day. An unsecured instance does not just expose Hong Kong data — it creates a multi-jurisdictional incident.
The Non-Obvious Risk: Malicious Skills
The 824 malicious skills documented in early 2026 represent a less discussed but arguably more dangerous vector than open ports. OpenClaw's skill system allows third-party extensions to access tools, files, and communication channels. A malicious skill packaged to look like a useful integration — a CRM connector, a document formatter — could exfiltrate data even on an otherwise properly secured instance.
This is where managed deployments provide a structural advantage. A managed provider can vet skills before they reach your environment, maintain an allowlist, and monitor skill behaviour in production. A self-hosted operator installing skills from public repositories has no such safety net.
For Hong Kong businesses, this is the risk that deserves the most attention. The open port problem is solved by basic infrastructure competence. The malicious skill problem requires ongoing operational security that most SMEs are not staffed to provide.
Addressing the Real Objection
The concern most Hong Kong business owners have is not technical — it is reputational. "If OpenClaw is in the news for security problems, will my clients worry that I'm using it?"
Two things to consider. First, your clients almost certainly do not know or care what platform runs your internal operations, any more than they know which email server software you use. What they care about is whether their data is handled properly. Second, the security incidents in the news are about unmanaged deployments. A properly deployed AI agent behind authentication, on a private network, with vetted skills, is materially more secure than the average Hong Kong SME's current email setup — where staff routinely forward sensitive documents via unencrypted consumer email accounts.
The honest answer is: OpenClaw as software has had real vulnerabilities, like any actively developed platform. The six CVEs in 2026 were patched. The exposed instances were misconfigured, not hacked through the software itself. The malicious skills were in public repositories, not in curated managed environments.
Security is not a product feature you buy once. It is an operational practice. The question is not "is OpenClaw secure?" but "is your deployment secure?"
What a Secure Deployment Looks Like
For a Hong Kong business, the minimum standard should include:
- No public internet exposure. The gateway should not be reachable from the open internet. Access via VPN or private network only.
- Authentication on every endpoint. No default credentials, no open ports, no "we'll set that up later."
- TLS encryption in transit. All communication between the agent, gateway, and any connected services should be encrypted.
- Skill allowlisting. Only vetted, approved skills should be permitted. No installation from public repositories without review.
- Regular patching. CVEs get published. Patches need to be applied promptly, not quarterly.
- Audit logging. Every action the agent takes should be logged and reviewable, particularly for regulated industries.
If your team can maintain all of that internally, self-hosting is viable. If not, a managed deployment is not a luxury — it is the responsible choice.
The Bottom Line
The security headlines are real, but they describe a specific failure mode: unmanaged self-hosted instances left open on the internet. That is a deployment problem, not a platform problem. Hong Kong businesses operating in regulated industries, handling cross-border data, and accountable under the PDPO should treat AI agent deployment with the same rigour they apply to any other system that touches client data.
If you are evaluating an AI agent for your business and want to understand what a properly secured deployment looks like in practice, agent88.hk can walk you through it.