A Guide to OpenClaw and Securing It with Zscaler

What Is OpenClaw

OpenClaw is an application designed as a persistent, long-running Node.js service that functions as a sophisticated AI agent. It bridges the gap between the LLM and the operating system, granting the agent the capability to manipulate files, execute shell commands, and interact with third-party services via the Model Context Protocol (MCP) or API.

It used to be called ClawdBot and MoltBot, and now OpenClaw. All refer to the same application.

Why It Matters?

In the past, agents have been specialized to one task or a group of similar tasks. OpenClaw lays the foundation to be a generalized application that can address multiple use cases while improving on the basic principles of AI agents with memory management and skills deployment.

This capability, while transformative, introduces a profound security paradox: the utility of the agent is directly proportional to its level of access. This very access creates an unprecedented attack surface within the host and the environment in which it is deployed.

Why Organizations Should Care

It is incredibly easy for users to download a malicious skill/library for OpenClaw. In fact, within days there were hundreds of malicious skills that users could download with a click of a button.

A great example is One-Click RCE, where:

“A victim would simply need to visit an attacker-controlled website that leaks the authentication token from the Gateway Control UI, which is enabled by default, via a WebSocket channel. Then an arbitrary command will run, even if the victim is hosting locally.”

The fact that no administrative rights are needed to install OpenClaw locally significantly increases the risk of users running and downloading malicious content/skills, using the OpenClaw device to move laterally once compromised, as well as uploading sensitive data (captured via integrations), since it can bypass typical security controls. This is made even worse by the fact that it is not easy to identify the application or service, nor does it have an identity related to OpenClaw.

This guide is for IT/security admins on how to protect their environments from a user installing, running, or bringing in rogue devices into a network that has OpenClaw installed/running. This poses a significant risk to the enterprise network and should not be allowed.

There are mitigating controls that users of OpenClaw can deploy, but these are often left to the user, who might not fully understand them and might not care to implement them. These controls are not covered here.

How Does OpenClaw Work?

OpenClaw is a gateway-centric system designed to facilitate an agentic loop (such as ReAct)—a continuous cycle of perception, reasoning, and action. This puts the LLM between the users and the data (for integrations/tools), allowing the LLM to provide reasoning. The architecture is divided into three primary functional domains: the Gateway, the front end (node), and the integration layer. Thus, OpenClaw uses standard HTTPS for all bound connections/integrations.

The Gateway

The Gateway serves as the centralized control plane, managing sessions, maintaining persistent memory, and routing communications between the user and the agent across various messaging platforms such as WhatsApp, Telegram, Slack, and Discord. Here are the default ports used by OpenClaw internally on the system:

Node Layer

The node layer is used to access resources on the system and beyond—such as local file system access, camera access, screen recording, and location services—and provide them to the Gateway. These are also a collection of node libraries running on the endpoint as part of the Node.js process.

The Integration Layer

This layer manages “skills”—modular packages of code, metadata, and natural-language instructions that define what the agent can do. It leverages the Model Context Protocol (MCP) to interface with external services (such as GitHub, Google Workspace, or Notion) using a standardized schema, ensuring the agent always uses the correct API parameters without requiring hardcoded custom integrations for every task.

Security Takeaways on Architecture

The key takeaway is that OpenClaw inherits the user-agent string from the Chrome browser. There is no hardcoded, unique “OpenClaw” user-agent string used globally for all outgoing traffic, which makes it difficult to differentiate OpenClaw applications from standard user browser traffic. Since all its integrations rely on outbound HTTPS connections, which are typically allowed on user devices and network firewalls, uniquely identifying it at the transport layer is challenging. Furthermore, the fact that the service runs locally on the device makes it difficult to detect at the network layer outside of the device itself.

In addition, OpenClaw has extensive integrations, allowing it access to a wealth of data out of the box, which can then be extended by adding “skills.” Couple this with local system access and the ability to install it without needing admin rights, and OpenClaw becomes a significant risk vector.

How Can Zscaler Help?

Note: This is not a step-by-step configuration guide. It provides guidance on what controls should be strongly considered to detect and restrict OpenClaw within an environment. Please use the standard change management process within your environment to roll out any changes.

There are two main ways of deploying OpenClaw:

1. Cloud-based/centrally hosted LLM (most likely scenario)
2. LLM deployed locally (typically needs computers with NPU/GPU and memory of over 32 GB)
    

OpenClaw can be installed locally on the device, in a container, or in an IaaS/PaaS platform. For this document, we will treat both container-based and locally installed methods the same.

Note that not all of these controls need to be implemented; this list merely provides a defense-in-depth strategy that would allow an organization to prevent unauthorized use from both managed and BYOD devices. A simple URL block would prevent the download, but pairing it with TLS inspection provides significantly more visibility and control. Controls such as file-type filtering, sandboxing, and DLP will enhance this protection. In addition, implementing tenancy control would allow access to enterprise GitHub while blocking other GitHub instances that could be hosting OpenClaw. Thus, it is generally recommended to implement layered controls.

A note on TLS inspection: Keep in mind that Node.js by default does not use the OS credential/certificate store; thus, if TLS inspection is enabled, the user will get a certificate error while talking with external tools, LLMs, and communication channels. The node libraries will have to end up trusting Zscaler root certificates to talk externally, thus forcing TLS inspection.

1. Preventing download of OpenClaw: Using URL and/or a combination of file type control, Zscaler can prevent unauthorized downloads of OpenClaw on endpoints. OpenClaw install files are typically .ps1, .sh, or Docker files. These file types should be blocked.

Block URLs	https://openclaw.ai/ https://github.com/openclaw/openclaw URL Filtering
Filetypes	Block File type ps1, sh, Docker(yaml/yml).   File Type control
Detecting existing installs	Existing installs of OpenClaw can be detected using Zcaler Endpoint DLP, EDR, or MDM. See the respective sections below for details.

2. Preventing the download of additional playbooks and 0day malware is crucial. OpenClaw uses markdown for its skills files. Custom file type control can be used to detect markdown files and block downloads. Furthermore, Zscaler CASB can be used to isolate, restrict, or block access to GitHub repositories to prevent users from duplicating repos and bypassing security by using custom repositories.

Block URLs	https://openclaw.ai/ https://github.com/openclaw/openclaw
TLS Inspection	Enable TLS inspection policy as broadly as possible and at a minimum across allowed LLMs and sanctioned Apps with which OpenClaw Integrates OpenClaw Integrations
Sandbox policy	Any Executable and Archive should be Quarantine First-time Action     Zscaler Sandbox
Filetype control	Blocking File types: JSON, ps1, sh, Docker(yaml/yml), Markdown, unscannable and password protected files Zscaler File Type Controls Zscaler Custom File Type Controls
Cloud App control	Restrict access to Github to align with user role                           Zscaler Cloud App control
Tenancy restrictions for Github	Certain users such as developers might still need access to Enterprise Github repo, Zscaler Tenant Profiles in combination with cloud app controls can be used to provide granular access.         Zscaler Tenant Profile

3. Prevent callbacks and connections to known malicious and 0-day malware. OpenClaw Skill files that are malicious would often call back to C&C servers; they can also use evasive techniques such as SSH tunnels or DOH tunnels. Zscaler can prevent these callbacks along with preventing executables/scripts that would trigger these callbacks.

Advance Threat protection policy	Enable Botnet production Enable Malicious Active Content Protection Enable Fraud Protection Block Unauthorized Communication Protection                                                         Block BItTorrent Block P2P file sharing ATP policy
Sandbox policy	Any Executable and Archive should be Quarantine First-time Action Zscaler Sandbox
DNS DGA	ATP policy
DNS tunnels	Enable DGA under ATP Policy Block DOH tunnels Block unknown DNS tunnels ATP policy DNS Control
SSH tunnels	Unauthorized Communication Protection ATP policy

4. Protect Against sensitive data leakage. Depending on the deployment, OpenClaw will have to use the network for tool/skill access and/or for LLM access. During this time, Zscaler can perform data protection on these sessions, if they are inspected. Keep in mind that Node.js by default does not use the OS certificate store; thus, if TLS inspection is enabled, the user will get a certificate error while talking with external tools, LLMs, and communication channels. Thus the node libraries will have to end up trusting Zscaler root certificates to talk externalling, thus forcing TLS inspection.

5. Prevent unauthorized LLM calls. The most common deployment I anticipate would be using public LLMs. In which case OpenClaw will be making outbound calls to LLM using API. Controls should be placed around this where only sanctioned AIs are allowed from an organization's network and this sanctioned AI will provide visibility and guardrails.

6. Prevent rogue devices from running OpenClaw and/or moving laterally. In open networks such as college campuses or research institutions, users can plug in rogue devices that have OpenClaw running. If these devices are compromised or used maliciously, they can be used as an entry point into the enterprise network. A common example is plugging a MacMini into an open port. This is where Zscaler can help control and direct communications from these devices by effectively isolating them. 

7. Restrict BYOD From Accessing Enterprise data directly: Another use case to cover is for contractors and/or BYOD devices accessing SaaS applications such as Workday or Salesforce. Contractors or BYOD devices with OpenClaw can download skills that would allow them to use the Chrome Dev Kit to scrape data from your SaaS services. This is where Zscaler can help prevent data loss at a mass scale with Zscaler Zero Trust Browser.

Endpoint Controls to Consider

As OpenClaw runs locally on an endpoint, the Gateway and node layers have components/services that are running on the endpoint locally. EDRs have visibility and control into these, thus EDR should be paired with Zero Trust principles to gain full visibility and control over managed devices.

1. Package/config file inspection with EDR: Inventory NPM global installations and identify OpenClaw binaries and config files in common paths.

2. Installer Logic: Rules can be set to block common one-line "curl-to-bash" installation patterns.

3. Process monitoring and escalation detection: Detect Node processes running on the endpoint, especially with high privilege access. 

4. Detecting locally hosted services: OpenClaw’s front end can be deployed as local only or a remote service. In either scenario all inbound access to endpoints should be blocked, especially the ports called out in the Gateway section. 

5. MDMs can also be used to detect presence of OpenClaw on managed devices

Summary

OpenClaw feels like a new frontier in agentic AI. It is poised to change how we view and use AI agents today, and potentially lay the groundwork for what Agentic AI applications could like like going forward However, at this point, OpenClaw introduces significant security and privacy risks for an organization. Zscaler can help accelerate enterprise, government, and education institutions' secure adoption of GenAI while ensuring malicious tools or risky applications are not introduced, preventing data loss, and preventing device compromise within the organization's environment.