What Is Clawdbot and Is It Actually Safe to Run on Your System?

[Update] February 3, 2026: “341 Malicious ClawHub Skills Found Stealing Data From OpenClaw Users”

[Update] February 2, 2026: “Moltbook Backend Exposure Enabled AI Agent Account Takeover”

[Update] January 28, 2026: “Supply Chain Risks Identified in the Clawdbot Ecosystem”

[Update] January 27, 2026: “Has Clawdbot Been Rebranded as Moltbot?”

Clawdbot has rapidly moved from an obscure open-source project into a widely deployed AI agent gateway. On social media, it is framed as a personal AI assistant that lives inside messaging apps, remembers everything, and executes tasks autonomously. The promise is seductive: no browser tabs, no copy-paste, just text your assistant and it acts.

What is rarely discussed is what this actually means in operational terms. Clawdbot is not a productivity app. It is long-running infrastructure that bridges large language models with real execution environments. Once deployed, it becomes part of your attack surface, not just another tool in your stack.

What Exactly Is Clawdbot Doing Under the Hood?

At its core, Clawdbot is an agent gateway that connects LLMs to messaging platforms and local system capabilities. Messages arriving from Telegram, Slack, WhatsApp, Signal, or Discord are routed through a persistent gateway process. That gateway can invoke tools, execute shell commands, read and write files, authenticate to third-party services, and maintain long-term state.

This is not speculative. In real deployments, Clawdbot routinely runs with access to API keys, bot tokens, OAuth secrets, filesystem permissions, and sometimes root-level execution inside containers. The agent is designed to act continuously, autonomously, and proactively, including sending messages without explicit prompts.

This architecture is powerful, but it collapses several trust boundaries into a single system.

How Does Clawdbot’s Architecture Expand the Attack Surface?

Two components matter most from a security perspective.

The Clawdbot Gateway handles message routing, AI inference calls, credential management, and tool execution. It is typically deployed as a long-running service, often exposed indirectly through reverse proxies such as Nginx or Caddy.

The Clawdbot interface is a web-based admin panel used to configure integrations, approve devices, inspect conversations, and manage keys. It effectively becomes the control plane for the entire agent.

Unlike a traditional admin UI, exposure of Clawdbot means exposure of everything the agent can see and do. Credentials, conversation history, execution capabilities, and perception control are all centralized behind this interface.

What Does Real-World Clawdbot Exposure Actually Look Like?

Theoretical threat models matter less than real deployment patterns. In practice, Clawdbot is being deployed quickly, often following “happy path” guides, and frequently without full hardening.

Clawdbot Control has a distinctive HTTP fingerprint. Whether through unique HTML strings, title tags, or static assets, it is trivially identifiable by internet-wide scanners. Using this fingerprint, exposed instances can be enumerated within hours of deployment.

According to Shodan searches, 1,009 Clawdbot gateways are currently exposed on the public internet (recent rebranding and wider adoption have since pushed this number into the tens of thousands). While some are properly authenticated, others are partially protected or completely open. Several exposed instances reveal configuration data, environment variables, and historical conversations. In the worst cases, command execution is enabled without effective access control.

This is not an edge case. It is a predictable outcome of deploying powerful agent infrastructure without defensive defaults.

Why Is an Exposed Clawdbot Control Interface So Severe?

Read-only access to Clawdbot Control already constitutes a major breach. Configuration dumps often include Anthropic API keys, Telegram bot tokens, Slack OAuth secrets, signing keys, and device-pairing metadata. Conversation histories can stretch back months, including private messages, attachments, and operational context.

Write or execution access escalates the situation dramatically. Clawdbot agents can send messages as the operator, inject content into ongoing conversations, and exfiltrate data through existing integrations in ways that resemble legitimate traffic. Because the agent mediates perception, attackers can selectively filter or modify responses, creating a man-in-the-middle effect at the cognitive layer.

This is not just data theft. It is identity, agency, and perception compromise.

How Do Common Clawdbot Misconfigurations Enable This?

Many observed exposures are rooted in familiar infrastructure mistakes rather than exotic vulnerabilities. One recurring pattern involves trust assumptions around localhost connections.

Clawdbot supports cryptographic device authentication using challenge-response mechanisms. However, in some configurations, connections originating from localhost are auto-approved. When the gateway sits behind a reverse proxy on the same host, external traffic may appear as loopback unless trusted proxies are explicitly configured.

In such cases, authentication is effectively bypassed. This is a classic proxy misconfiguration pattern, but the impact is amplified because the gateway controls an autonomous agent with persistent authority.

The issue is less about a single bug and more about unsafe defaults in a system that concentrates high-value capabilities.

Why Are AI Agents Like Clawdbot Structurally Hard to Secure?

Clawdbot exposes a broader problem facing autonomous agents as a category.

For an agent to be useful, it must read private messages, store credentials, execute commands, and maintain persistent state. Each requirement undermines assumptions that traditional security models rely on. Least privilege becomes difficult when the agent’s value is its broad access. Application sandboxing breaks down when the agent must operate across tools and platforms.

Conversation history itself becomes sensitive intelligence. Behavioral patterns, planning context, and social graphs are all embedded in stored interactions, yet are often treated as ordinary logs.

These are not implementation mistakes. They are structural trade-offs.

What Does Clawdbot Signal About the Future of AI Operations?

Clawdbot is not an outlier. It is an early manifestation of a broader shift toward agent-based computing. Autonomous systems with delegated authority will become normal, not exceptional.

The lesson is not to avoid these systems, but to treat them as privileged infrastructure. Agent gateways should be hardened like identity providers. Credential stores should be managed like secret vaults. Conversation history should be classified as sensitive data. And perception-layer attacks must be recognized as a real threat vector.

The assistant can be extraordinarily capable. But capability without control is indistinguishable from exposure.

The butler can manage your entire house. Just make sure the front door is locked.

Has Clawdbot Been Rebranded as Moltbot?

Yes. The Clawdbot project has been rebranded as Moltbot. The change was announced publicly by the team, who explained why the name was changed by citing a trademark-related request from Anthropic.

They stated that the new name reflects the concept of molting, a natural process associated with growth, and noted that the rename does not imply any change in the project’s scope, functionality, or direction.

As part of the update:
Clawdbot → Moltbot
Clawd → Molty

According to the announcement, the project’s activities and technical focus remain unchanged.

Supply Chain Risks Identified in the Clawdbot Ecosystem

Recent findings indicate that Clawdbot’s risk surface extends beyond exposed gateways and misconfigured deployments. New research highlights how its skill distribution model introduces supply chain risks that closely resemble long-standing issues observed in ecosystems such as npm and PyPI.

This issue was demonstrated by Jamieson O’Reilly, a security researcher, through a controlled experiment targeting ClawdHub, the public registry for Clawdbot skills. ClawdHub allows users to install third-party skills that extend agent capabilities, with execution occurring in the same operational context as the agent once permissions are granted. In practice, installing a skill becomes a high-impact trust decision.

As part of the experiment, a simulated but backdoored skill was published and made to appear legitimate by artificially inflating its download count to 4,000+, pushing it to the most downloaded skill on the platform. The download metric could be manipulated trivially, rendering popularity an unreliable trust signal.

Once promoted, real users installed and executed the skill. Within eight hours, 16 executions were observed across seven countries, where arbitrary commands ran on developer machines. While the payload was intentionally limited to proving execution, the same mechanism could have enabled credential theft, source code exfiltration, or long-term persistence.

The researcher explicitly compared this pattern to historical npm supply chain incidents, including event-stream and ua-parser-js, where attackers exploited implicit trust in package registries, maintainer reputation, and popularity indicators to achieve large-scale compromise. The ClawdHub experiment shows that these assumptions resurface when execution is abstracted behind convenience and trust signals are weak.

Several systemic issues emerge:

• Download counts function as easily gameable trust indicators
• Skill packages may contain executable logic not fully surfaced to users
• Permission prompts encourage habituation rather than scrutiny
• There is no effective pre-publication vetting or behavioral analysis

While individual flaws may be patched, the broader issue is architectural rather than specific to Clawdbot. AI agents concentrate high-value capabilities by design, and skill registries concentrate trust. When these converge, supply chain abuse becomes efficient rather than exceptional.

The lesson mirrors what the npm ecosystem learned years ago: as automation increases, trust models must mature faster than developer convenience, or attackers will inevitably exploit the gap.

Early Phishing and Impersonation Risks Around Clawd

As Clawdbot adoption grows, early-stage phishing and impersonation signals are already emerging. SOCRadar’s analysis shows that more than 50 domains containing the “clawd” keyword have been registered, a common early indicator of opportunistic abuse around popular open-source tools.

This pattern is well established in security research. Attackers typically register lookalike domains early, long before launching visible campaigns. These domains are later used for fake documentation, cloned install pages, or modified install scripts designed to capture API keys, bot tokens, or credentials. In ecosystems where users routinely copy commands, run scripts, and grant broad permissions, the risk surface expands quickly.

Moltbook Backend Exposure Enabled AI Agent Account Takeover

A newly disclosed security issue revealed that Moltbook, a social-style platform for AI agents, briefly exposed critical backend infrastructure that could allow full takeover of registered AI agents. The issue was identified by a security researcher during follow-up analysis of the ClawdBot and Moltbot ecosystem.

Moltbook was found to be running on Supabase with Row Level Security (RLS) either disabled or improperly configured, leaving a publicly accessible API endpoint exposed. The endpoint contained agent API keys, authentication tokens, verification data, and ownership mappings, effectively allowing anyone with the URL to impersonate any AI agent on the platform.

Because Moltbook agents operate autonomously and post publicly, this exposure carried significant abuse potential, including identity impersonation, misinformation, scam promotion, and reputational damage. The issue was not theoretical. With the exposed credentials, agent accounts could be modified and controlled without prior access.

The exposed database has since been closed, and remediation efforts are reportedly underway. However, the incident highlights a recurring risk in emerging AI agent platforms: high-privilege autonomous agents combined with insecure default backend configurations create outsized security impact, even from short-lived misconfigurations.

341 Malicious ClawHub Skills Found Stealing Data From OpenClaw Users

Recent findings confirm that the supply chain risks previously highlighted around ClawHub and OpenClaw are now being actively exploited.

A security review of 2,857 ClawHub skills identified 341 malicious skills designed to steal credentials, API keys, and crypto-related secrets from users. These skills posed as legitimate tools, including cryptocurrency trackers, Polymarket bots, YouTube utilities, auto-updaters, and Google Workspace integrations.

The malicious skills relied heavily on social engineering, hiding harmful behavior behind “Prerequisites” sections that instructed users to manually install additional components. On macOS, obfuscated shell scripts were used to deploy Atomic Stealer (AMOS), while Windows users were redirected to trojanized archives hosted on public repositories. Several samples also embedded reverse shell backdoors and exfiltrated secrets stored in ~/.clawdbot/.env.

Analysis shows shared command-and-control infrastructure across multiple skills, indicating coordinated campaigns rather than isolated abuse. This reinforces earlier assessments that AI agent marketplaces inherit the same systemic supply chain risks seen in ecosystems like npm and PyPI, amplified by the high-privilege nature of autonomous agents.