Key Takeaways

• OpenClaw's explosive growth from side projects to 300,000+ GitHub stars created massive security debt. Originally assuming a trusted local environment, its security model was rapidly outpaced by real-world deployment complexity, accumulating 280+ GitHub Security Advisories and 15+ CVEs between November 2025 and March 2026.

• Historical analysis shows that the Gateway treated local network access as proof of identity, bypassing authentication checks that should have been required. Localhost origin, URL parameters, and OS app boundaries were each exploited to gain full orchestration authority - shell execution, filesystem access, browser automation, and multi-device control - making the blast radius effectively unbounded for most self-hosted deployments.

• Identity binding across 20+ messaging platforms proved structurally fragile, historically producing more than 60 allowlist bypass issues. Mutable attributes used for authorization, privilege-level conflation across interaction modes, and absent webhook verification created recurring bypass paths that granted attackers access to the full execution pipeline.

• Disclosed vulnerabilities repeatedly revealed divergence between policy validation and actual execution. Flag abbreviations bypassed exact-match deny lists, approved commands were not bound to file paths, and sandbox restrictions failed to propagate to child sessions or secondary endpoints - showing that enforcement must validate the final resolved form across all code paths.

• Local credentials, session histories, and agent memory stored were exposed through multiple disclosed vulnerabilities related to inconsistent boundary checks across modules. Path traversal and sandbox gaps appeared independently across multiple modules because each implemented its own validation logic rather than sharing a common boundary enforcement mechanism.

• The extension ecosystem became a primary supply chain attack vector at scale. Hundreds of malicious skills were found on ClawHub, alongside fake installers and lookalike npm packages. Unlike conventional supply chain attacks, agent skills can influence behavior through natural language, making them resistant to traditional scanning.

• Deployment misconfiguration posed risks equal to or greater than code-level bugs, with 135,000+ internet-exposed instances found across 82 countries. Disabled sandboxes, overly broad tool policies, and shared gateways across trust boundaries require no buggy code to exploit - a correctly functioning but carelessly deployed agent is indistinguishable from a compromised machine.

• Prompt injection poses a persistent, long-term threat that is hard to be fully resolved, with techniques spanning indirect injection, marker spoofing, state poisoning, and agent-to-agent exploitation. This cannot be addressed at the model level alone and requires layered system-level defenses, strict capability controls, and protection of persistent memory as an attack surface.

• For developers, security in OpenClaw-style agent systems must be a first-class design concern from day one - not a retrofit after growth. This means establishing formal threat models before building, hardening the control plane as an admin API rather than a convenience layer, enforcing immutable privilege inheritance for all spawned subprocesses, applying layered prompt injection defenses and ensuring sandbox enforcement covers every execution path - not just the primary one.

• For deployers, managing an OpenClaw-style agent is closer to managing a privileged employee than installing a set-and-forget tool - it demands continuous oversight, periodic audits, and strict access governance. Operators should bind to loopback, run under dedicated non-root accounts in isolated environments, enforce authentication and allow lists on all channels, enable sandboxing with strict tool policies, regularly audit agent state and configurations, and treat third-party extensions with the same scrutiny as untrusted executable code. For non-technical users, the safer choice is to wait for more mature, hardened versions rather than granting an autonomous agent broad access to personal or enterprise accounts today.

The rapid adoption of OpenClaw, an open-source autonomous AI agent framework, highlights a growing trend toward AI-driven assistants. However, this widespread integration has introduced significant security risks, including potential unauthorized actions, data exposure, and system compromises.

This report aims to provide a detailed review of the key security challenges that arose during the development and rapid adoption of OpenClaw, offering valuable security insights for the broader AI agent industry. Its primary goal is to deliver security design guidelines for developers building similar agent systems and to provide actionable risk awareness and mitigation strategies for end users, focusing on both development and deployment perspectives.

We present a comprehensive analysis of OpenClaw’s architecture and core components, covering ingress categories, internal modules, supply chain inputs, and external dependencies. Through a deep dive into its workflows, the assessment identifies inherent security vulnerabilities and attack surfaces. It evaluates the risks associated with each major component, analyzing representative vulnerabilities, common attack techniques, and emerging threat patterns.

This report is based on data and analysis available before March 18, 2026. Due to the fast-paced evolution of OpenClaw-style agent systems, their architectures, attack methods, and vulnerabilities are constantly shifting, and a stable phase has not yet been reached. Readers are encouraged to stay updated with our ongoing analysis for the most current information.

What is OpenClaw?

OpenClaw is a self-hosted AI assistant that integrates with communication channels like WhatsApp, Telegram, Slack, Discord, and Microsoft Teams. Unlike traditional chatbots, it can perform tasks like clearing inboxes, sending messages, and managing calendars, making it a highly capable, action-oriented tool. Its broad functionality has propelled it into mainstream tech conversations, earning significant attention in GitHub rankings, startup circles, and security briefings.

However, this power comes with risks. OpenClaw's deep system permissions and extensive API integrations create a large attack surface, increasing security vulnerabilities as its capabilities grow.

History and Growth

OpenClaw evolved quickly, starting as a WhatsApp relay called Warelay, becoming Clawdbot, then Moltbot, and finally settling on its current name in January 2026. The rebranding coincided with rapid growth, surpassing 300,000 stars and 58,000 forks on GitHub. This explosive rise outpaced its security architecture, leading to significant vulnerabilities as its user base and complexity increased. The result was accumulated security debt that has impacted its evolution.

Concerns

As OpenClaw's adoption grows, so do concerns about its security and operational risks. The primary concerns can be grouped into three categories:

1. AI Alignment and Control Risks: The autonomous nature of OpenClaw has led to unpredictable behaviors. A notable incident, as reported by TechCrunch, involved the assistant ignoring user stop commands and deleting emails aggressively, demonstrating the danger of giving LLM-driven agents destructive write-access without proper fail-safes.

2. Traditional Cybersecurity Vulnerabilities: OpenClaw’s role as a bridge between external inputs and local systems creates common attack vectors. SecurityWeek reported critical vulnerabilities, including local gateway hijacking, where malicious websites could exploit OpenClaw’s local presence to exfiltrate data or execute unauthorized commands.

3. Data Privacy and Compliance Risks: OpenClaw’s deep access to personal messages, calendars, and workspaces has raised regulatory concerns. Reuters reported that multiple government bodies and corporate IT departments have moved to ban or limit its use due to fears of data leakage and non-compliance with data protection regulations.

These concerns highlight the risks of granting AI such deep access to local systems. In the following sections, we will explore how OpenClaw’s architecture interacts, revealing security weaknesses and vulnerabilities in the process.

Architecture Overview

OpenClaw functions as a gateway-centered agent system. It’s designed to orchestrate external inputs, memory, and local system tasks efficiently. The core architecture includes several layers:

1. Gateway: Central control process that ingests signals (messages, commands, webhooks, etc.) and routes them to the appropriate agent and session.

2. Agent Runtime & Context Assembly: Assembles context, communicates with the LLM, and decides if specific tools are needed.

3. Execution & Capability: Executes actions like browser automation, file access, and messaging.

4. Shared Infrastructure: Manages persistent state, secrets, memory, and plugin extensions.

These components work together in a cyclical pipeline: Ingress → Routing & Session → Agent Runtime & Context Assembly → Execution & Capability → Delivery & Persistence.

However, this system introduces a security chokepoint. The seamless integration of untrusted inputs with the privileged Execution Layer creates vulnerabilities. When these boundaries blur, or the LLM is tricked into malicious actions, the entire system is compromised.

High-Level Diagram

A diagram below shows the high-level flow of how external inputs interact with OpenClaw’s internal layers and execution processes. For a more detailed visual representation, please refer to the schematic.

OpenClaw, as an event-driven agent OS, interacts with various ingress points, each of which represents a potential security risk. Understanding where inputs come from and how the system trusts these sources is crucial in identifying vulnerabilities. These ingress points are divided into three main categories:

1. Untrusted Content Ingress: External sources like Slack, Discord, Telegram, WhatsApp, Signal, iMessage, and HTTP webhooks. The system assumes that messages and payloads from these channels may be hostile or misleading, normalizing them into internal event envelopes before routing them for processing.
   
   Example: A Telegram DM with a PDF arrives. OpenClaw normalizes the message and sends it to the routing/session for further handling.
   
   

2. Trusted Control-Plane Callers: These are authenticated systems like the CLI, web UI, or paired device clients. They are allowed to control OpenClaw's operations, inspect state, or run actions. Any compromise of their credentials (e.g., stolen API tokens) results in full system access.

3. Internal Trigger Sources: These are system-initiated tasks, such as cron jobs and heartbeat check-ins. While not directly initiated by external actors, attackers who can manipulate the local state or database can exploit these triggers to gain persistent access or launch delayed attacks.

Internal Components and Trust Assumptions

1. Configuration and Policy: This layer serves as OpenClaw’s "policy brain." It defines system behavior through a dynamic ruleset that includes layered resolution, granular access controls, and hot-reloading. While powerful, its complexity can lead to misconfigurations, weakening the system’s security posture if not properly managed.

2. Gateway: The Gateway is the core daemon that orchestrates OpenClaw. It manages all incoming signals, controls communication channels, and dispatches workloads. The Gateway acts as the central hub for routing external and internal traffic, ensuring proper communication and execution of tasks.
   
   Security Challenge: The Gateway’s role in managing all external and internal communications creates a significant attack surface. Its core responsibilities—ingress management, control-plane hosting, and workload dispatching—must be closely monitored to prevent unauthorized access or misconfigurations.

In the following sections, we will examine these components in greater detail, focusing on how they interact and expose potential vulnerabilities in the OpenClaw architecture.

Routing and Session

OpenClaw’s architecture relies heavily on several interconnected components to function effectively, but these same components introduce significant security risks. Below, we break down the key layers of OpenClaw, focusing on their roles, potential vulnerabilities, and security implications.

Routing Layer

The Routing Layer acts as OpenClaw's "switchboard," determining which agent handles each incoming event and which session it belongs to. The routing logic operates on four core pillars:

1. Multi-agent Binding: OpenClaw supports multiple agents (e.g., “Personal” vs. “Work”), and the router assigns incoming messages based on rules for channels, groups, or senders.

2. Session Key Structure: Conversations are isolated using structured keys to ensure context is maintained and prevents cross-user data leakage.

3. Allowlists and Pairing: User interaction is governed by a "Pairing-Required" policy, where human approval is needed for new contacts before an agent will respond.

4. Command Handling: Control-plane commands (e.g., /reset, /status) are intercepted by the routing logic to ensure system-level actions are executed securely.

Security Risk: The routing layer's security relies on the integrity of Identity Binding. If an attacker can spoof a paired identity or bypass command-handling logic, they can gain unauthorized access to the system, potentially executing malicious actions.

Agent Runtime and Context Assembly

The Agent Runtime serves as the "brain" of OpenClaw, responsible for processing input, assembling context, and deciding which actions to take. It operates in a Think-Act-Observe cycle, with three core processes:

1. Execution Loop: Assembles context, calls the LLM, executes tools, and delivers results. Includes guardrails to prevent runaway loops.

2. Context Assembly & Skills: Merges agent identity, reusable instructions (skills), and session history to build the model’s prompt.

3. Subagent Architecture: Allows agents to spawn subagents for handling complex tasks, inheriting access from the parent agent.

Security Risk: The Agent Runtime is a primary target for Prompt Injection. Since it merges untrusted user input with system instructions and privileged skills, attackers can manipulate the system into executing unintended actions. The Subagent Design also introduces risks where a compromised agent or subagent can perform unauthorized operations across the system.

Execution and Capability

The Execution Layer represents the "hands" of OpenClaw, enabling the agent to execute various actions like file access, device control, and web interactions. Key tools in this layer include:

1. Sandbox & Automation: Docker for command execution and Playwright for browser automation, with bridges to prevent unauthorized access.

2. Node Invocation: OpenClaw can control paired devices (Mac, iPhone, Android) through WebSocket, enabling actions like GPS tracking and camera usage.

3. Scheduling & Automation: Allows the agent to manage recurring tasks such as daily email summaries.

4. Interactive UI (Canvas & A2UI): Pushes interactive content to paired devices, creating an "Agent-to-User Interface" (A2UI).

5. Multi-modal Pipeline: Processes non-textual data (e.g., images, audio, PDFs) and performs web searches.

Security Risk: The broad range of tools significantly increases the potential blast radius of a security compromise. If the sandbox and approval mechanisms are bypassed, OpenClaw can transform from a simple chatbot into a "system-wide intruder," with access to sensitive systems and devices.

State / Memory / Secrets

OpenClaw’s architecture allows it to store long-term memory, securely manage secrets, and integrate third-party plugins, but these features introduce significant security risks. Below, we explore how these components function and the vulnerabilities they create.

State Layer: Memory and Secrets Management

The State Layer ensures OpenClaw can remember past interactions and maintain long-term knowledge. It is organized into three pillars:

1. Ephemeral Session State: Stores metadata and conversation histories (structured logs), allowing the system to maintain continuity across short-term interactions.

2. Long-Term Memory & Embeddings: Uses a memory system with Markdown files and vector search (SQLite + BM25) to retain important facts and allow semantic retrieval in future sessions.

3. Secrets Management: Instead of storing raw credentials, OpenClaw uses a pointer-based reference system that resolves secret references into credentials only at runtime.

Security Risk: The memory layer poses a serious threat if attackers can poison long-term memory or embedding indexes, creating Persistent Indirect Injection. Additionally, since secrets are resolved into plaintext at runtime, any component able to read the memory or intercept tool calls could exfiltrate sensitive credentials.

Plugin and Extension System

The Plugin and Extension System allows third-party code to integrate into OpenClaw, expanding its capabilities. The system works through three mechanisms:

1. Universal Lifecycle: Plugins are discovered, loaded, and registered from multiple sources (npm, local directories, bundled assets).

2. Deep System Injection: Plugins can inject logic into any layer, from new messaging channels to custom context engines or exposing new HTTP/WebSocket routes.

3. Slot-Based Exclusivity: Critical components are slot-based to prevent conflicting plugin logic.

Security Risk: Plugins are a major vector for supply chain attacks. A malicious or vulnerable plugin, even if sourced from legitimate repositories, can silently exfiltrate user data or hijack the control plane. Since plugins run in-process within the same Node.js environment as the Gateway, they lack isolation, making them particularly dangerous.

Supply Chain Inputs

Supply Chain Inputs refer to external packages and content bundles that are integrated into OpenClaw during setup or configuration, not at runtime. These inputs include:

1. Plugin Packages: Installed from npm, local directories, or compressed archives. They are validated and installed into the extensions directory, running in the same process as the Gateway without sandbox isolation.

2. Skill Distribution Sources: Skills, reusable instruction bundles, are distributed through several sources, including ClawHub Marketplace, and can be integrated into OpenClaw through various directories.

Security Risk: The use of external plugins and skills presents a supply chain vulnerability. Malicious or compromised plugins and skills can execute harmful actions, exfiltrate data, or manipulate system behavior. The absence of isolation and the reliance on allowlists and provenance warnings make this an ongoing security challenge.

In summary, while OpenClaw's memory, plugin, and extension system enhance its functionality, they also create significant attack surfaces that malicious actors can exploit. The integration of external components without sufficient isolation and security checks opens the door for potential data breaches, credential theft, and system hijacking.

Hook Packs

OpenClaw’s extensible architecture, which includes support for hook packs, external dependencies, and local runtimes, offers powerful functionality but also presents significant security risks. Below, we examine these components and their associated vulnerabilities.

Hook Packs: Event-Driven Automation

Hook Packs are standalone automation bundles that extend OpenClaw’s event-driven behavior. They allow event handlers for a wide range of system events, such as new commands, session activities, or agent lifecycle events. These packs are installed as npm packages or directories with a manifest declaring which events they handle.

Security Risk: Hook packs can be used to build automation chains (e.g., logging messages to external analytics), but they introduce a risk of malicious handlers. A compromised or malicious hook could manipulate OpenClaw’s event-driven responses, potentially logging sensitive data or triggering unauthorized actions.

External Dependencies and Runtime Neighbors

OpenClaw interacts with several external services and local runtimes at runtime, creating multiple security risks through its reliance on third-party providers.

LLM Providers

OpenClaw supports a wide range of Large Language Model (LLM) providers, including OpenAI, Anthropic, Google Gemini, and others. These providers generate text and decisions for the agent, and OpenClaw treats them as interchangeable backends.

Security Risk: The reliance on multiple remote providers introduces potential threats related to provider compromise or manipulation. Since the LLM handles critical decision-making and communication, attackers could exploit vulnerabilities in the backend services to inject malicious code or instructions.

Embedding and Memory Providers

OpenClaw uses various embedding providers to convert text into vector representations for semantic search. This layer supports several systems like OpenAI, Google Gemini, and Ollama, feeding into a hybrid search engine for context retrieval.

Security Risk: Embedding and memory providers present a vector for Prompt Injection. Malicious embeddings could manipulate OpenClaw’s search and memory systems, influencing the agent’s behavior in unforeseen ways. Moreover, compromised providers could feed false or harmful information into OpenClaw’s decision-making process.

External Content and Remote Services

OpenClaw fetches remote resources through external content providers, including search engines like Brave and Google. The system handles content cleaning and context-grounding before sending data to the LLM.

Security Risk: External content is a major attack vector, as it directly influences the LLM’s context window. This makes it susceptible to Prompt Injection attacks and malicious payload execution. Despite the processing safeguards (like URL validation and SSRF protection), the untrusted nature of external content presents an ongoing security challenge.

Local Host and Workspace Resources

OpenClaw operates within a confined workspace directory, containing bootstrap files, identity data, and long-term memory. A file bridge is used to map these logical paths to isolated volumes, preventing unauthorized access to the host filesystem.

Security Risk: If the file bridge or path-guards are bypassed, OpenClaw could gain access to sensitive data outside its designated workspace. Additionally, vulnerabilities in sandboxing or boundary-checking mechanisms could allow an agent to escape its workspace, leading to potential system compromise.

Local Runtimes and Sidecars

Beyond the core Gateway, OpenClaw utilizes several satellite runtimes (e.g., Docker, Playwright for web automation, Canvas Host for interactive UI content, SQLite for memory indexing). These sidecars communicate with the Gateway via internal endpoints and IPC channels.

Security Risk: The use of multiple runtimes introduces complexity and increases the attack surface. Misconfigurations or vulnerabilities in sidecars could allow attackers to gain access to internal communications or execute unauthorized actions within OpenClaw’s distributed environment.

OpenClaw’s Security Architecture

OpenClaw, the fastest-growing open-source AI agent platform, has quickly become one of the most scrutinized projects in the AI community. Since its November 2025 launch, it has amassed over 280 GitHub Security Advisories, 100 CVEs, and multiple ecosystem-level attacks. The vulnerabilities span every layer of its architecture—ranging from gateway hijacking to prompt injection—highlighting that an AI agent with shell access, messaging integration, and a plugin marketplace demands a level of security far beyond what a "hobby project" can sustain.

These security issues cluster around a few critical boundaries in the OpenClaw architecture: local control planes, identity and routing, execution and sandbox enforcement, local state and secret handling, extension and supply-chain surfaces, and deployment assumptions. Below is a closer look at the Gateway and Control Plane, the most critical attack surface, and some of the most damaging vulnerabilities discovered.

Gateway and Control Plane: The Weakest Link

The Gateway’s control plane is the central point of entry to OpenClaw’s ecosystem, overseeing HTTP/WebSocket endpoints, Control UI, canvas-facing endpoints, local relays, and node pairing flows. A breach at this layer grants operator-level privileges, providing full access to shell execution, filesystem control, messaging, and device invocation.

Between January and March 2026, three significant vulnerabilities revealed a recurring weakness in the Gateway: it mistakenly treated proximity—such as localhost origin, browser context, or URL parameters—as a substitute for authentication. This flaw opened multiple pathways for attackers to exploit operator credentials and gain full control of the agent.

Representative Vulnerabilities

1. ClawJacked (Browser-to-Local Gateway Takeover)
   This vulnerability exploited a fundamental flaw in OpenClaw’s trust assumptions about local connections. The Gateway relaxed several controls for localhost connections, including rate limiting and origin validation. A malicious JavaScript embedded in the webpage could initiate a WebSocket connection to the local Gateway, brute force the gateway password without rate limiting, and silently pair with the device. This gave attackers full access to the agent control plane. The patch in 2026.2.25 fixed this by enforcing strict origin validation, applying rate limits to localhost password attempts, and blocking silent pairing for untrusted browser clients.

2. CVE-2026-25253 (Token Exfiltration via Untrusted gatewayUrl)
   OpenClaw trusted a gatewayUrl value from the URL query string and automatically established a WebSocket connection, sending the authentication token without user confirmation. Attackers could craft a malicious link to redirect the connection to a compromised endpoint, capturing the authentication token and gaining access to the victim’s OpenClaw instance. OpenClaw addressed this issue in version 2026.1.29 by adding a gateway URL confirmation modal to prevent automatic token exchange.

3. GHSA-rchv-x836-w7xp (macOS Dashboard Credential Leakage)
   OpenClaw’s macOS Dashboard flow exposed Gateway authentication credentials to browser-controlled surfaces. The macOS app appended the shared Gateway token and password to the Dashboard URL query string when opening the Control UI, allowing the credentials to be imported and stored in browser localStorage. The fix in 2026.3.7 removed password propagation from URLs, moved token transport to safer fragments, and scrubbed legacy stored credentials.

These vulnerabilities underscore the critical importance of securing the control plane and authentication mechanisms in AI agent platforms. While OpenClaw’s rapid growth has been impressive, these security flaws demonstrate the need for rigorous security measures when building systems with privileged access to users' devices, files, and messaging systems.

Pattern

OpenClaw's rapid growth has been overshadowed by a series of severe vulnerabilities, particularly in how it handles gateway and control plane security and identity binding. These flaws expose the platform to serious threats where improperly authenticated or authorized requests can escalate privileges, gaining unauthorized access to sensitive functions and data. The underlying pattern in these vulnerabilities stems from implicit trust assumptions in deployment properties, leading to mismatched authorization and privilege escalation.

Control Plane Vulnerabilities: Trust Assumptions and Access Control Failures

The core pattern behind OpenClaw’s vulnerabilities lies in the implicit trust placed on environmental properties, such as network location, URL context, or OS-level app boundaries. For example, OpenClaw's Gateway treated local connections (localhost), URL parameters, and browser contexts as inherently trustworthy, neglecting proper authentication checks. This led to several significant vulnerabilities, including:

1. ClawJacked (Browser-to-Local Gateway Takeover)
   The Gateway’s relaxed controls for localhost connections allowed attackers to exploit rate-limiting flaws and silent pairing to take control of the Gateway. This vulnerability highlighted the severe consequences of assuming trust based on network origin. Fix: Enforced strict origin validation and rate limits on localhost connections (2026.2.25).

2. CVE-2026-25253 (Token Exfiltration via Untrusted gatewayUrl)
   OpenClaw trusted a gatewayUrl parameter from the URL query string, automatically establishing a WebSocket connection and exposing the authentication token to attackers. Fix: Added a confirmation modal for gateway URL confirmation (2026.1.29).

3. GHSA-rchv-x836-w7xp (macOS Dashboard Credential Leakage)
   The macOS Dashboard exposed authentication tokens in URL parameters, storing them in browser localStorage. Fix: Tokens were moved to safer fragments and legacy tokens were scrubbed (2026.3.7).

These vulnerabilities were not isolated bugs, but rather indicative of a structural flaw: an overreliance on implicit trust in network and OS-level properties, leading to easily exploitable access points.

Routing and Identity Binding: Authorization Failures Across Platforms

In an agent system like OpenClaw, identity binding—the process of validating who the sender is and determining what they are authorized to do—has critical security implications. OpenClaw integrates with over 20 messaging platforms (WhatsApp, Telegram, Slack, Discord, and more), each with different identity formats, mutability guarantees, and verification mechanisms. Misinterpretations of these identities and authorization contexts have led to 60 allowlist bypass advisories as of March 2026.

Representative vulnerabilities include:

1. GHSA-v773-r54f-q32w (Slack DM Authorization Drift)
   OpenClaw’s Slack slash-command handler failed to validate the sender’s identity properly when Direct Message (DM) policy was set to open. This flaw allowed any user to invoke privileged commands, bypassing the intended allowlist checks. Fix: The logic was updated to compute permissions explicitly, defaulting to unauthorized unless confirmed (2026.2.14).

2. GHSA-mj5r-hh7j-4gxf (Telegram Mutable Username in Allowlist)
   OpenClaw’s Telegram integration mistakenly trusted mutable @username strings for authorization, which could be reassigned or recycled. An attacker exploiting this could interact with the system as an authorized user by hijacking a recycled username. Fix: Authorization logic now matches on immutable numeric user IDs instead of usernames (2026.2.14).

3. GHSA-rq6g-px6m-c248 (Google Chat Cross-Account Misrouting)
   Google Chat webhook targets and paths were misrouted when account contexts were ambiguous, allowing a message to be processed under the wrong authorization context. Fix: Routing layer was updated to ensure events are correctly bound to the right account context (2026.2.14).

4. GHSA-chm2-m3w2-wcxm (Google Chat Mutable Email in Allowlist)
   OpenClaw allowed Google Chat emails to be used in allowlist checks, but since email addresses are mutable within Google Workspace (e.g., recycled aliases), attackers could bypass the allowlist by taking over a recycled email. Fix: Matching was tightened to prefer immutable resource identifiers over emails (2026.2.14).

These vulnerabilities illustrate that trust assumptions in network contexts, URL parameters, and mutable identity attributes—especially in a multi-platform agent system—can be exploited to devastating effect. While these flaws were patched in subsequent releases, they reveal a deeper issue in OpenClaw's security architecture: insufficient authentication and authorization checks for every layer, from the gateway and control plane to the routing and identity binding systems.

As AI agents like OpenClaw evolve, security rigor must be prioritized to prevent unauthorized access and privilege escalation. The OpenClaw case serves as a cautionary tale for developers.

Execution, Approvals, and Sandbox: Bypassable Boundaries

OpenClaw's security framework relies on a sequence where each tool invocation is validated by a policy gatekeeper before execution. However, repeated breakdowns in this sequence—ranging from approval logic to sandbox enforcement—have led to multiple vulnerabilities. These flaws compromised the system’s ability to ensure that the runtime only executed validated commands, allowing attackers to bypass security controls and execute unauthorized actions.

Representative Vulnerabilities

1. GHSA-gv46-4xfq-jv58 (Remote Code Execution via Forged Approval Values)
   This vulnerability allowed authenticated gateway clients to bypass node execution approval mechanisms. By sending untrusted command parameters with forged approval fields, attackers could make the receiving node treat the command as already approved and execute arbitrary system commands.
   Fix: In 2026.2.14, the system was updated to strip untrusted approval-related fields before forwarding requests, restricting execution parameters to trusted values.

2. GHSA-943q-mwmv-hhvh (Unapproved Tool Execution via Auto-Approval)
   Two issues combined to bypass the human-in-the-loop approval process. The /tools/invoke endpoint didn’t block sensitive tools like sessions_spawn or sessions_send, and the Agent Control Policy (ACP) client auto-approved certain operations based on naive substring matching. This allowed attackers to spawn unconstrained agent sessions or inject malicious prompts into workflows.
   Fix: In 2026.2.14, high-risk tools were denied over HTTP, and ACP permission handling was hardened to prevent auto-approval of sensitive operations.

3. GHSA-3c6h-g97w-fg78 (Bypass of Safe Command Flag Checks)
   OpenClaw's "allowlist mode" intended to block unsafe commands like sort --compress-program=sh, but the validation logic only checked for exact string matches. This allowed attackers to bypass the restriction by using abbreviated or incomplete flags (e.g., sort --compress-prog=sh), which would still resolve to unsafe commands.
   Fix: In 2026.2.23, the system was updated to match flag prefixes and fail closed on unknown options, ensuring safer execution.

4. GHSA-q399-23r3-hfx4 (Command Approval Rebinding)
   This vulnerability allowed attackers to substitute a malicious binary after a command was approved by the user. The approval was not cryptographically bound to the actual file path, allowing attackers to rebind the path post-approval and execute arbitrary binaries.
   Fix: A cryptographic binding mechanism was introduced, and the system now verifies that approved binaries are from trusted paths (2026.3.1).

5. GHSA-p7gr-f84w-hqg5 (Sandbox Escape via Sessions_Spawn)
   This flaw allowed sandboxed sessions to spawn child processes in an agent with sandboxing disabled (sandbox.mode=off), effectively escaping confinement and gaining full system access.
   Fix: Enforced sandbox inheritance for cross-agent spawns in 2026.3.1, ensuring that spawned processes respect sandbox restrictions.

6. GHSA-h9g4-589h-68xv (Unauthorized Browser Control via Missing Authentication)
   The sandboxed browser's local HTTP bridge server lacked proper authentication, allowing any process on the machine to enumerate tabs, retrieve CDP WebSocket URLs, and control browser sessions.
   Fix: Enforced authentication on the sandbox browser bridge server and prevented non-loopback binds in 2026.2.14.

Sandbox Policy Enforcement Failures

1. Tool Access Bypass in Sandboxed Environments
   The /tools/invoke endpoint failed to merge sandbox-specific policies when building the tool list, allowing tools that were forbidden in sandboxed environments to remain accessible.
   Fix: Policy enforcement was strengthened to prevent access to disallowed tools in sandboxed contexts.

2. TOCTOU Race Condition in Sandbox Path Assertion
   A Time-of-Check-to-Time-of-Use (TOCTOU) race condition in the assertSandboxPath function allowed attackers to swap a regular file with a symlink, enabling escape from the sandbox even when workspaceAccess was set to none.
   Fix: In 2026.3.1, the race condition was mitigated by improving the path assertion logic and preventing symlink-based escapes.

OpenClaw’s security issues are primarily rooted in the breakdown of approval and validation logic, as well as failures in sandbox enforcement. These vulnerabilities allowed attackers to bypass safeguards, leading to serious consequences, such as remote code execution, sandbox escapes, and privilege escalation. While many of these issues have been patched in recent updates, they underscore the critical need for more robust security mechanisms when handling tool invocations, command approvals, and sandboxing in AI agents.

Filesystem, Local State, and Secrets: Exposure Through Multiple Ways

OpenClaw’s workspace accumulates a large number of sensitive assets, including conversation histories, OAuth tokens, API keys, and configuration files that dictate the agent’s permissions. However, its broad filesystem access—including read/write capabilities and session management tools—creates critical security vulnerabilities. The combination of sensitive assets and extensive filesystem control makes boundary enforcement essential. Any escape from the intended workspace can expose sensitive data, and vulnerabilities in OpenClaw have demonstrated significant lapses in this security model.

The vulnerabilities in this layer are primarily grouped into three categories: path traversal through weak boundary validation, inconsistent sandbox policy enforcement, and unsafe credential handling. These flaws allowed attackers to escape from the defined workspace and access sensitive files, execute arbitrary code, and bypass sandbox protections.

Representative Vulnerabilities

1. Path Traversal: Weak Boundary Validation

Several vulnerabilities allowed arbitrary read and write operations outside the designated workspace, exposing sensitive assets like transcripts, tokens, and configuration files:

• GHSA-r5fq-947m-xm57 (Path Traversal in Sandbox): This vulnerability allowed files to be written or deleted outside the workspace when the filesystem sandbox was not applied.
  Fix: In 2026.2.14, workspace containment was enforced to prevent this issue.

• GHSA-56pc-6hvp-4gv4 (Configuration File Include Vulnerability): Path resolution in configuration file includes allowed absolute paths, directory traversal, and symlink attacks.
  Fix: In 2026.2.17, path resolution was restricted to the config directory, enforcing strict containment.

• GHSA-64qx-vpxx-mvqf (Session File Path Vulnerability): Untrusted session file paths allowed arbitrary file writes outside the designated sessions directory.
  Fix: In 2026.2.12, path resolution was confined to the sessions directory.

• GHSA-4564-pvr2-qq4h (OAuth Credential Handling via Shell Command): OpenClaw mishandled OAuth token insertion into shell commands, allowing an attacker to inject arbitrary commands into the system.
  Fix: In 2026.2.14, execSync was replaced with execFileSync, removing shell interpretation and preventing command injection.

2. Sandbox Boundary Issues: Inconsistent Policy Enforcement

Multiple vulnerabilities were caused by inconsistent enforcement of sandbox boundaries, leading to bypasses of workspace-only restrictions and unauthorized file access:

• GHSA-qcc4-p59m-p54m (Dangling Symlink Bypass): Dangling symlinks bypassed the workspace-only write boundaries.
  Fix: In 2026.2.26, symlink resolution was improved to ensure paths were contained within allowed directories.

• GHSA-9f72-qcpw-2hxc (Native Prompt Image Auto-Load): Image auto-loading in the prompt did not enforce sandbox rules, allowing access to files outside the workspace.
  Fix: In 2026.2.24, stricter workspace boundary checks were implemented for native prompt image loading.

• GHSA-33hm-cq8r-wc49 (Sandbox Media Path Validation): Temporary paths under os.tmpdir() were not validated against the sandbox root, allowing for out-of-sandbox reads or exfiltration.
  Fix: In 2026.2.24, temporary path validation was tightened, restricting access to OpenClaw-managed roots.

3. Unsafe Credential Handling

Inconsistent handling of credentials and privileged operations exposed OpenClaw to risks of credential leakage and unauthorized actions:

• GHSA-4564-pvr2-qq4h (OAuth Token Injection via Shell): OAuth tokens were mishandled by passing untrusted values to privileged shell operations, allowing arbitrary code execution.
  Fix: Replaced execSync with a safer alternative that doesn't interpret input as shell commands.

Security Pattern and Root Causes

The root cause of these vulnerabilities stems from insufficient boundary enforcement. Different parts of OpenClaw accessed sensitive resources and files but applied inconsistent validation checks. For example, path resolution in file tools, session management, and configuration includes was not centrally governed, leading to separate traversal vulnerabilities in each component. Similarly, sandbox policies were enforced inconsistently across modules, such as file tools, image loaders, and media pipelines, where the weakest check became the effective boundary.

Credential handling followed a similar pattern, where OAuth tokens and other sensitive data were passed to privileged operations without adequate sanitization, creating opportunities for unauthorized access and command execution.

Extensions, Skills, and Supply Chain: Poison Ecosystem At Scale

OpenClaw, designed as an extensible platform, allows users to add plugins, skills, hook packs, and other components. While this extensibility is a key feature, it also increases the platform’s attack surface by incorporating code and artifacts that are not part of the core system. Malicious extensions, fake installers, and plugin vulnerabilities present significant security risks within OpenClaw’s ecosystem, as demonstrated by several high-profile incidents.

Representative Vulnerabilities

1. Malicious Skills

Malicious payloads have been commonly disguised as setup prerequisites for skills within OpenClaw’s ClawHub marketplace. Researchers at KOI identified hundreds of malicious skills that lured users into downloading password-protected ZIP archives or fetching obfuscated URLs that bypassed security scanners. Once executed, these payloads could steal sensitive data, including passwords and cryptocurrency wallet credentials, or install backdoors within otherwise legitimate codebases.

Security Risk: Unlike conventional supply chain attacks, these malicious skills operate within OpenClaw’s privilege boundary and can influence the agent’s behavior through natural language. While VirusTotal-based scanning has been introduced to flag suspicious skills, prompt injection attacks remain a significant threat that behavioral analysis tools may not fully detect.

2. Fake Installer/NPM Package

Beyond the core product, the surrounding distribution ecosystem—including GitHub and npm—has proven to be a vector for fake OpenClaw installers. Attackers have exploited trust in search results and software repositories to distribute malicious lookalike packages. These fake installers do not compromise the OpenClaw codebase directly but instead target users through social engineering, convincing them to download malicious components masquerading as official installers.

Security Risk: The broader trust chain around how OpenClaw is discovered and installed is vulnerable. Fake installers undermine the integrity of the installation process, shifting the security focus from the codebase itself to how OpenClaw is distributed.

3. Plugin Vulnerabilities

Plugins in OpenClaw—used to extend the platform’s functionality—have been the source of multiple vulnerabilities:

• GHSA-qrq5-wjgg-rvqw (Plugin Path Traversal): This vulnerability allowed plugins to escape the extensions directory and write files outside it by using improperly validated metadata.
  Fix: The issue was addressed in 2026.2.1 by validating installation paths before file writing.

• GHSA-4rj2-gpmh-qq5x (Voice-Call Plugin Allowlist Bypass): This flaw allowed attackers to bypass the voice-call plugin’s allowlist by using empty caller IDs or suffix-based matching.
  Fix: Fixed in 2026.2.2 by rejecting missing caller IDs and requiring exact matching.

• Nextcloud Talk Plugin Vulnerabilities: The Nextcloud Talk plugin contained several severe vulnerabilities, including CVE-2026-28474 (allowlist bypass via display name spoofing) and CVE-2026-28470 (command injection), which led to authentication bypasses and remote code execution.
  Fix: These issues were addressed in the plugin’s update 2026.2.6.

Security Risk: These vulnerabilities highlight the risks of insufficient input validation, access control bypass, and command injection within plugins. Improperly validated plugin parameters or insecure coding practices allow attackers to leverage OpenClaw’s extensive functionality to execute unauthorized operations.

Root Cause: Risks Introduced by the Extension Ecosystem

The core issue lies in the risks introduced by OpenClaw’s extension ecosystem, where external components—including skills, plugins, and hook packs—can alter the agent runtime. These extensions can introduce malicious logic, backdoors, or unauthorized actions once installed. Fake installers and lookalike npm packages exploit social engineering to distribute attacker-controlled components, further expanding the attack surface. Security flaws in plugins, such as improper input validation or access control issues, expose the agent’s privileged functionality to malicious actors.

Deployment Assumptions and Trust Model: Correct Code, Dangerous Outcomes

While OpenClaw’s source code may be free of traditional vulnerabilities, real-world risks arise from improper configurations, weak security guarantees, and reliance on language models (LLMs) to make security-critical decisions. These risks—though not listed in vulnerability databases—have caused more widespread damage in practice than many CVEs. They stem from three key patterns: exposure of the agent to the internet, sharing the agent across trust boundaries, and default configurations that grant maximum power with minimal friction.

Representative Bad Practices and Risks

1. Exposed Instance: OpenClaw Infrastructure on Public Networks

When OpenClaw infrastructure is exposed to public networks without proper access control, unauthorized users can interact with the gateway and take control of the agent. A 12-day scan window by Bitsight revealed over 30,000 internet-exposed instances. Further research by SecurityScorecard's STRIKE team found 135,000+ instances across 82 countries, with over 15,000 exposed to remote code execution (RCE).

Security Risk: Exposing OpenClaw to the internet without proper security controls makes it vulnerable to unauthorized access and remote exploitation. This risk is significant because OpenClaw can perform powerful actions, including shell access, filesystem read/write, and credential management.

2. Disabled Sandbox and Overly Broad Tool Policies

OpenClaw allows sandboxing to be disabled, which means commands executed via the exec tool run directly on the host system rather than in an isolated environment. This exposes the host filesystem, environment variables, and local resources to unintended access. Even with sandboxing enabled, overly broad tool policies—such as an unrestricted tools.exec.policy: allow-all—can grant the agent the same destructive capabilities as running without a sandbox.

Security Risk: Disabling the sandbox or misconfiguring tool policies makes OpenClaw a powerful system intruder with full access to sensitive local resources, effectively removing any boundaries between the agent and the host system.

3. Shared Gateway Mixed-Trust Risk

OpenClaw's own documentation highlights the issue: when multiple untrusted users message the same agent, they share delegated tool authority. For example, in a shared Slack workspace, if multiple users interact with an OpenClaw bot, all users effectively gain the same privileges, including shell execution and file access. This is fine for personal use, but it can be catastrophic when deployed in shared infrastructure environments.

Security Risk: In mixed-trust environments, where untrusted users share the same agent instance, the lack of fine-grained access control can lead to significant risks. This allows unauthorized access to privileged actions, such as credential retrieval or execution of system commands.

4. Dangerous Break-Glass Configurations

Many of OpenClaw’s most dangerous configurations are initially set for legitimate purposes, such as troubleshooting a plugin or testing a new integration. For example, disabling the sandbox, turning off exec approvals, or binding to 0.0.0.0 for external access can be useful during development. However, if these settings persist in a production environment, they become catastrophic security flaws.

Security Risk: These break-glass configurations can remain unchecked and inadvertently expose sensitive resources or allow unrestricted access, making the system vulnerable to exploitation.

LLM Provider Risks

Most of the risks in OpenClaw assume that the language model (LLM) powering the agent behaves as intended. However, OpenClaw relies heavily on the LLM for security-critical decisions, such as selecting tools, constructing arguments for shell commands, interpreting approval workflows, and content filtering. This creates a unique category of risk that traditional software does not encounter.

• Underpowered Models: If an operator selects a cheaper, faster, or less capable model, the agent may misinterpret instructions, select the wrong tools, or fail to detect prompt injection attempts.

• Inconsistent Model Results: Even a capable model can produce inconsistent results. The same prompt, context, and tool set can lead to different tool calls in successive runs, potentially exposing the agent to unpredictable behavior.

Security Risk: The lack of deterministic behavior in LLMs creates an inherent risk in security-critical decisions. Misinterpreted instructions or failed security checks can lead to inconsistent tool calls, granting unintended access or executing malicious operations.

Pattern: Lack of Strictly Enforced Security Guarantees

The root cause of many of OpenClaw’s security issues is the lack of strictly enforced security guarantees. Security controls often depend on deployment configurations and can be disabled or weakened by the operator. Misconfigurations, such as exposing OpenClaw instances to the internet, using underpowered models, or granting overly permissive tool policies, can degrade or completely bypass security controls.

• Exposed instances and mixed-trust environments can lead to unauthorized access and escalation of privileges.

• Disabled sandboxes and overly broad tool policies eliminate critical boundaries that are meant to protect the system from potential attacks.

• Break-glass configurations can remain active in production environments, creating vulnerabilities that are easy to exploit.

Prompt Injection

OpenClaw’s deep integration with messaging platforms and automation tools significantly broadens its attack surface. The agent routinely ingests content from various external sources, such as emails, chat messages, web pages, and API responses. Given that these inputs cannot be assumed trustworthy, malicious content embedded in them can manipulate the agent’s reasoning and cause it to perform unintended actions. Due to the inherent limitations of language models, prompt injection attacks remain a major security risk—one that cannot be fully mitigated at the model level but requires robust defensive system design and strict control measures.

Representative Attack Techniques

1. Indirect Injection Through External Content (Email/Web Pages/Docs/Chat)

One of the most common attack techniques is indirect prompt injection, where attacker-controlled instructions are embedded in external content the agent processes during its normal workflows. The agent may be tasked with summarizing, triaging, or responding to information, but malicious text embedded within the content can override the user’s original intent.

Common attack vectors include:

• Automated inbox processing: Using email hooks (e.g., Gmail, Workspace) that ingest emails with hidden malicious instructions.

• Web browsing workflows: Agent retrieves and summarizes web pages, which may include malicious instructions embedded in seemingly benign content (via browser automation or user-supplied URLs).

• Collaborative tools: Shared documents, ticket threads, or communication platforms that the agent reads for context, with injected instructions hidden in these operational contexts.

Malicious content may include:

• Social engineering attempts (e.g., impersonating a colleague or administrator).

• Fake "system" or "error" messages demanding remediation actions.

• Instructions directing the agent to execute unauthorized commands or use certain tools.

• Attempts to establish persistence by modifying agent files or scheduled tasks.

2. Wrapper/Marker Bypass and Authority Spoofing

To mitigate prompt injection, OpenClaw wraps external inputs in explicit boundary markers, marking them as untrusted data. However, attackers can still bypass these safeguards by exploiting the fuzzy matching tendencies of models, which treat certain content as authoritative even if it is tampered with.

Common techniques for bypassing boundary protection:

• Near-miss markers: Slight modifications of boundary strings—such as typos, spacing changes, or Unicode homoglyphs—can evade sanitization while still appearing as legitimate control blocks to the model.

• Authority spoofing: Injected text mimics trusted sources (e.g., system errors, policy messages), making the model treat attacker-controlled instructions as authoritative.

Mitigation: OpenClaw introduced a countermeasure that adds a unique random ID to external-content wrapper tags to prevent spoofing. However, research by Veganmosfet shows that this countermeasure does not fully address the underlying prompt injection risks.

3. Sandwich Injection

Sandwich injection is a technique that exploits prompt boundary confusion by inserting a trusted-looking block of content between two external content blocks. The model misinterprets the middle segment as the user’s instruction and executes it.

Example structure of the attack:

• Harmless-looking content

• Fake end marker

• Trusted user message segment (misinterpreted as legitimate)

• Resumes the external content wrapper

This attack essentially tricks the model into executing injected malicious instructions while appearing to follow the user’s intent.

4. Persistence via State Poisoning

Malicious instructions can also be written into the persistent agent state so that they are automatically reloaded in future sessions. These attacks aim to establish durable control by modifying files or configurations that OpenClaw loads into its system prompt or runtime environment, making the payload reappear even after a restart or session renewal.

Key persistence surfaces include:

• Agent memory/always-loaded files: Writing attacker-controlled instructions into files like HEARTBEAT.md, SOUL.md, or MEMORY.md, which OpenClaw loads into the system prompt on each session. These instructions may run periodically (by default, every 30 minutes).

• Creating new integrations: An attacker may create a new chat integration (e.g., a Telegram bot) with an allowlist entry for themselves. Once the attacker has access to this integration, they can modify the SOUL.md file or even set up OS-level scheduled tasks to repeatedly inject malicious logic.

Log Poisoning

OpenClaw’s reliance on external content sources and its integration with autonomous agents introduces significant security risks, particularly from contextual injection and agent-to-agent exploitation attacks. These techniques leverage the model's inherent limitations in distinguishing between trusted and untrusted data, enabling attackers to inject malicious instructions that manipulate the agent’s behavior, often without detection. These vulnerabilities expose the system to a range of malicious activities, including data leakage, unauthorized actions, and the spread of exploitative content.

Representative Attack Techniques

1. Contextual Injection via System Logs

This technique involves contextual prompt injection, where attacker-controlled input is embedded into system logs and later reintroduced into the model’s reasoning context. The attacker crafts requests that contain malicious text in fields like WebSocket headers. If these fields are logged without proper sanitization, the malicious content becomes part of the diagnostic data stored in the gateway logs. If the agent later reads these logs for troubleshooting or debugging, the poisoned entries are reintroduced into the agent’s reasoning and may be interpreted as legitimate instructions.

• Example Vulnerability: GHSA-g27f-9qjv-22pm
  This vulnerability allowed attacker-controlled input to persist in system logs, effectively poisoning the agent’s reasoning when the logs were read.
  Fix: In 2026.2.13, header values were sanitized and truncated before being written to the gateway logs to prevent this form of injection.

Security Risk: This attack highlights the importance of sanitizing diagnostic data before it’s logged and later analyzed. The agent’s reliance on logs for debugging and troubleshooting can unintentionally expose the system to prompt injection attacks if malicious data is stored without proper validation.

2. Agent-to-Agent Exploitation

Agent-to-agent exploitation involves attackers publishing posts or comments designed specifically for autonomous agents to read. These posts contain hidden instructions that cause agents to perform unintended actions, such as leaking sensitive data, reposting malicious content, triggering crypto transfers, or following links to additional malicious threads.

• Example Attack Vector: Moltbook, a social media platform for autonomous agents, was targeted by attackers who published bait posts that lured agents into reading additional threads. These threads contained hidden prompt-injection payloads that exploited agents into executing malicious actions, including re-sharing the exploitative content.

Security Risk: This exploitation technique takes advantage of external content sources that agents process without fully validating or sanitizing the input. By embedding malicious instructions within normal content, attackers can manipulate agent behavior, spreading the attack to other agents and platforms.

Root Cause: Lack of Reliable Separation Between Trusted and Untrusted Data

The root pattern in both contextual injection and agent-to-agent exploitation is the lack of reliably enforced separation between untrusted inputs and the agent’s trusted context. OpenClaw labels external content through prompt formatting, but the boundaries between trusted and untrusted data are often defined by textual structure, which attackers can mimic or slightly alter. This means that the model may misinterpret untrusted, attacker-controlled data as legitimate instructions, leading to security vulnerabilities.

Key Issues:

• Insufficient sanitization of diagnostic data, allowing malicious entries to persist in logs and be reprocessed by the agent.

• Untrusted content from external sources being processed without proper validation, leading to the model executing malicious instructions embedded in seemingly harmless data.

• Misuse of content discovery paths in agent-to-agent interactions, where posts or comments intended for legitimate purposes are weaponized to spread malicious payloads.

Development Recommendation

Comprehensive Security Measures for OpenClaw: A Threat Model and Best Practices for Safe Deployment

To ensure the security and integrity of OpenClaw, developers should implement a comprehensive set of practices, including threat modeling, formal security models, and robust controls across all system layers. Given the combination of high-privilege tool execution and LLM reasoning in agent frameworks like OpenClaw, special attention must be paid to indirect control paths where attacker-controlled inputs can manipulate the agent’s behavior and trigger privileged operations.

Key Security Practices for OpenClaw

1. Establish a Threat Model

A thorough threat model is essential for understanding the security risks within OpenClaw. The model should:

• Define system trust boundaries: Identify the parts of the system that should only interact under strict, trusted conditions.

• Identify attack surfaces: Recognize the components of OpenClaw, including its messaging integrations, tool execution, and external dependencies, that could be exploited.

• Map data flows: Ensure that data moving across the agent pipeline, from external inputs to internal system components, is validated and secured to prevent unauthorized influence over critical agent decisions.

Recommendation: Given the system’s extensive control over local resources and high-level integrations, the threat model should account for prompt injection and other indirect influences that manipulate the agent’s reasoning and trigger privileged operations.

2. Establish Formal Security Models

To validate that OpenClaw meets its intended security properties, developers should establish formal security models. These models capture:

• Core system behavior, trust boundaries, and authorization rules.

• Invariants: Security properties that must always hold true (e.g., no unauthorized command execution or data access).

• Model checking: Verifying the system’s security properties across possible system states to ensure it operates within its defined constraints, providing machine-checked assurance of its security.

3. Control Plane Security

The local control plane should be treated like an admin API rather than a local convenience layer. Key actions include:

• Explicit and non-bypassable operator authentication: Do not rely on network location or loopback origin as security boundaries. Secure device pairing and authentication flows should be enforced.

• Separation of UI, operator API, and automation RPC paths: Ensure that these do not collapse into a single trust domain, making the system more vulnerable to external exploitation.

Recommendation: Tighten access controls to prevent unauthorized users from interacting with the agent, and enforce strict separation of duties within the control plane.

4. Channel Access Control

Enforce strict access control over who and which channels can trigger agent actions. This is critical in environments with multiple users or shared access, such as:

• Restricting interactions to trusted users and contexts.

• Scoped permissions for actions triggered in shared environments to prevent unsolicited inputs from compromising the agent.

5. Local Data Protection

To ensure local data protection, developers should:

• Validate externally supplied paths and resource references after canonical resolution, ensuring access is restricted to intended directories.

• Redact sensitive information in logs, minimizing the exposure of sensitive data.

• Use dedicated secret management systems to protect credentials and sensitive data, ensuring they are never stored in the agent’s accessible filesystem.

6. Extension Ecosystem Security

The extension ecosystem (plugins, skills, hook packs) should be treated as security-critical components:

• Security verification: Conduct static analysis and controlled runtime inspection of external modules before they are accepted into the runtime environment.

• Capability checks: Ensure that a plugin’s declared capabilities align with its actual execution behavior.

• Input validation: Treat inputs from extensions as untrusted, and validate them before they influence key system components like filesystem paths, routing logic, or authorization decisions.

7. Prompt Injection Protection

To mitigate prompt injection attacks:

• Sanitize inputs and implement layered defenses, such as input validation and guardrails, to prevent untrusted data from being interpreted as model instructions.

• Separate external content from system instructions clearly to reduce the risk of misinterpretation.

• Semantic firewalls: Use advanced tools to analyze external inputs and flag suspicious segments before they influence the agent’s behavior.

8. Agent Memory and Context Protection

Agent memory and context are sensitive attack surfaces and should be protected against poisoning:

• Validate memory updates: Ensure that stored context does not introduce unintended instructions or malicious behaviors that could influence subsequent agent actions.

• Regularly audit memory to prevent gradual accumulation of malicious influence from external inputs.

9. Enforce Privileged Access Controls and Policies

Strict controls should be implemented over high-risk capabilities such as command execution, filesystem access, and external network actions:

• Policy checks: Ensure privileged operations are gated through explicit allowlists or confirmation mechanisms.

• Immutable execution privilege tree: Ensure that any derived agent, script, or spawned sub-process inherits the most restrictive constraints of its parent, reducing the impact of model-level failures.

10. Execution Protection

Enforce sandboxing across the entire execution surface, covering system calls, file reads, and network access:

• Comprehensive sandboxing: Ensure that every operation, not just primary execution paths, is contained within a secure boundary.

• Execution monitoring: Continuously monitor and log execution traces to detect anomalous behavior, allowing for post-execution analysis.

• Reversible environments: Where feasible, actions should be executed in environments that allow for automated rollback, limiting the blast radius of any detected malicious activity.

• Human review: High-risk actions should require human approval before execution to prevent unauthorized system modifications. 

Best Practices for Secure Deployment and Use of OpenClaw

While OpenClaw is a powerful and flexible AI agent platform, it also poses significant security risks if not properly managed. Due to its frequent updates and evolving codebase, the project may introduce unknown vulnerabilities that could compromise user systems. To ensure safe deployment and use, especially for enterprise IT administrators and advanced developers, it is essential to follow best practices for hardening infrastructure, enforcing access control, and protecting sensitive data. For ordinary users, it is recommended to wait for more mature, hardened versions before installing OpenClaw and avoid granting it broad access to personal or enterprise accounts.

Infrastructure Hardening

To secure OpenClaw infrastructure and limit exposure to potential attacks, follow these steps:

1. Avoid exposing the gateway to the public internet: Bind OpenClaw to the loopback interface or a private interface. If remote access is necessary, use a private network such as Tailscale.

2. Run OpenClaw under a dedicated non-root account: Prevent running the agent with elevated privileges to reduce the potential damage in case of an attack.

3. Run OpenClaw in an isolated environment: Use a VPS, dedicated host, or container rather than running OpenClaw on the primary workstation. This limits its access to critical system resources.

4. For mixed-trust environments, isolate trust boundaries: Run agents under separate gateways, OS users, or hosts to prevent unauthorized interactions between agents from different trust levels.

5. Restrict filesystem permissions: Set the OpenClaw runtime directory permissions to 700 to ensure only authorized users can access or modify sensitive files.

Authentication and Access Control

Robust authentication and strict access controls are essential for minimizing the risk of unauthorized access:

1. Ensure gateway authentication is enabled: Properly configure authentication and rotate credentials regularly to prevent unauthorized users from gaining access.

2. Lock down who can trigger the bot: Use allowlists and pairing to restrict who can interact with the agent. Avoid using open policies unless public access is explicitly intended.

3. Require mentions in groups: Prevent the bot from responding to ambient group chat messages by configuring it to only react to mentions.

4. Use separate service accounts: Assign least privilege to external integrations (e.g., GitHub, Google) by using separate service accounts for each integration.

Tool and Capability Restrictions

To prevent OpenClaw from executing dangerous or unauthorized actions, configure strict tool and capability policies:

1. Enable sandboxing: Isolate tool execution to prevent access to sensitive system resources.

2. Enforce strict tool policies: Disable high-risk tools unless explicitly required for specific tasks. This limits the impact of compromised tools.

3. Define security guardrails: Use agent instruction files (e.g., AGENTS.md) to establish guidelines that help shape the model's behavior and prevent unauthorized actions.

Secret and Sensitive Data Protection

To protect sensitive data and credentials, it is crucial to follow these practices:

1. Avoid embedding secrets in configuration files: Use OpenClaw’s secret management system to store credentials and keep them out of the agent’s reachable filesystem.

2. Do not store plaintext secrets in agent instruction files such as AGENTS.md or SOUL.md.

3. Keep sensitive logging protections enabled: Ensure the logging.redactSensitive setting remains active during normal operation to protect sensitive information from being logged.

Extension and Supply Chain Security

The extension ecosystem, including plugins and third-party skills, introduces additional risks. To mitigate these risks:

1. Review risk warnings before installing third-party skills: Carefully assess the risks on ClawHub before installing any skill. Only install extensions from trusted sources.

2. Check security scanning results: If available, review the security scanning results on the skill page to identify potential vulnerabilities.

3. Review skill documentation carefully: Watch for suspicious instructions, especially those that ask users to run shell commands, download binaries, or execute external programs during setup or usage.

Monitoring and Operational Security

Ongoing monitoring and regular audits are critical to maintaining OpenClaw’s security in a production environment:

1. Run security audits regularly: Perform security audits, particularly after any configuration changes or network exposure, to identify potential vulnerabilities.

2. Keep OpenClaw updated: Given the rapid pace of development, ensure that OpenClaw is regularly updated to incorporate the latest security patches.

3. Audit the agent’s stored state: Periodically review the agent’s state to detect unexpected changes or abnormal behavior that might indicate a compromise.