How OpenClaw’s Flawed Design Philosophy Left Organizations Exposed to Active Attacks

Ben Marr, a security engineer at Intruder, explains how a flawed design philosophy in OpenClaw left organizations open to active attacks. This article originally appeared in Insight Jam, an enterprise IT community that enables human conversation on AI.

Over 25,000 instances of OpenClaw (formerly known as Clawdbot and Moltbot) are currently exposed on the internet. API keys and sensitive data are being stored in plain-text files, and attackers are actively exploiting them. Security researchers at Intruder recently released insights on widespread exploitation targeting OpenClaw, and found that the attacks were made possible by architectural choices that prioritized deployment convenience over fundamental security protections. The fallout demonstrates how user-friendly design decisions can expose individuals to credential theft, trigger injection attacks, and result in full instance compromise across major cloud platforms.

OpenClaw launched in late 2025, and it quickly gained significant hype, with the agent branded as a “super-helpful digital helper.” Within days, it became one of the fastest-growing open-source projects in GitHub’s history. OpenClaw’s popularity stems from its functionality: beyond typical AI assistants like Siri or Alexa, users often run OpenClaw on their computers and ask it to complete mundane tasks, from answering emails to taking notes.

Despite the excitement of its functionality, major security concerns have arisen. The fundamental problem derives from OpenClaw’s user-friendly design. While the platform does include verification pairing and security settings to lock down access, the suggested starter configuration leaves these features disabled by default. OpenClaw enables non-technical users to deploy tasks and connect sensitive services (such as email accounts, social media platforms, and personal files) without enabling these critical protections.

OpenClaw’s security documentation is extensive but impractical, leaving users with an overwhelming array of options and little clear guidance. There are no enforced firewall configurations, no credential verification mechanisms, no plugin sandboxing, and no AI safety controls to prevent prompt manipulation or unauthorized commands.

Attacks are being actively exploited through the following vectors:

Exposed credentials

Users are misconfiguring cloud instances, leading to publicly accessible API keys, authentication tokens, and, in some cases, entire configuration files containing sensitive credentials.

Prompt injection attacks

OpenClaw instances connected to platforms such as email accounts, WhatsApp, Signal, and X are exposing private information when external users compose specific prompts in replies. OpenClaw’s developers deliberately decided to bypass guardrails by default (as part of its “easy AI” framework), creating a massive attack surface when users integrate their social media accounts. There have been several cases where attackers have stolen API keys, emails, and internal system information through social engineering at OpenClaw itself.

Malicious “skills” distribution

Threat actors are distributing backdoored plugins through community channels. Recent research from Koi identified 341 malicious OpenClaw skills targeting the platform’s users. These plugins masquerade as legitimate functionality extensions while executing credential-harvesting, data-exfiltration, and botnet-recruitment operations.

Insufficient AI guardrails

OpenClaw lacks sufficient safety controls. There have been multiple instances where the platform has posted sensitive information, exfiltrated data, and executed commands, all without user authorization.

The situation is urgent. Organizations running OpenClaw with default configurations should treat their deployments as compromised and take immediate action.

First, disconnect from the platform by revoking all service integrations (particularly those that have access to email and social media accounts and proprietary data). Administrators need to audit server configurations for exposed files and regenerate all authentication credentials (such as API keys, tokens, and passwords) that may have been accessible. Implementing network controls to restrict instance access exclusively to trusted IP ranges is critical, as is removing all third-party plugins and examining them for malicious behavior from verified sources before any potential reinstallation. Lastly, reviewing access logs across all connected services will help identify indicators of unauthorized activity.

The OpenClaw incident underscores a critical collision between user-friendly AI deployment and security-by-default principles. As organizations increasingly adopt AI assistants into their workflows, security teams must recognize that these tools represent a new and evolving attack surface. The rush to adopt AI capabilities cannot come at the expense of API security fundamentals of credential management, access controls, and continuous monitoring. Organizations must establish clear policies around AI assistant deployment, mandate security reviews before integration, and treat API keys with the same rigor as other credentials. The future of cybersecurity depends on building these guardrails into the foundation, and not implementing them after compromise.