Netskope Threat Labs details MoltBot risks and mitigations

MoltBot, a self-hosted personal Artificial Intelligence (AI) agent, presents unauthenticated remote access and host-level privileges that pose data risk; Netskope Threat Labs advises restricting installations to isolated sandboxes and disabling remote access in enterprise environments.

Research Overview

MoltBot, previously named ClawdBot, is an open-source agent intended for local self-hosting that can read and write files, execute commands, and operate browsers. The vendor analysis focuses on the agent's default network exposure and the level of control it receives on its host.

Key Findings

Netskope Threat Labs identified two primary risk vectors: by default MoltBot permits unauthenticated remote access, allowing any network-reachable actor to connect to and control the agent. The agent also runs with full host privileges, enabling file modification, command execution, and browser control without built-in safeguards.

Technical breakdown

Observed technical risks include indirect prompt injection, non-deterministic destructive actions, storage of plaintext memory, potential supply-chain vectors, and limited contextual judgment by the model, any of which can lead to data exposure or system disruption.

Installation sources

Common installation vectors identified include direct installer scripts and package mirrors, for example molt.bot/install.sh, molt.bot/install.ps1, molt.bot/install.Compliance Metadata (CMD), github.com/moltbot/, registry.npmjs.org/moltbot/, yarn.npmjs.org/moltbot/, and registry.yarnpkg.com/moltbot/.

Web fetch user-agent string

One default tool, web_fetch, uses a legacy Chrome user-agent string that can signal MoltBot activity when correlated with access to the molt.bot or clawd.bot domains.

Operational impact

Netskope recommends running MoltBot only in constrained sandboxed environments that have no access to sensitive data and disabling remote access to the installation. For environments using Netskope Secure Web Gateway (SWG), transaction events can help identify prior installations by searching for installer downloads, PowerShell or curl-based access, Network Performance Monitor (NPM) mirror downloads, and git clones.

Product update

Targeted blocking

As a mitigation, administrators can block specific installer paths and package mirrors such as molt.bot/install.sh, molt.bot/install.ps1, molt.bot/install.CMD, github.com/moltbot/, registry.npmjs.org/moltbot/, yarn.npmjs.org/moltbot/, and registry.yarnpkg.com/moltbot/ to prevent typical installation methods.

Aggressive blocking

Organizations seeking broader restriction can block the molt.bot domain and its subdomains (for example, *.molt.bot) to prevent access to the site and its documentation.

User coaching

Instead of blocking, real-time user coaching can warn users attempting to access installer paths and allow informed users with a legitimate business need to proceed to the website or repository.

Enterprises should identify any existing MoltBot installations, ensure they are isolated from sensitive systems, and disable remote access where appropriate; this “Blog Signals brief” is a fact-based summary of the vendor blog.