Blog

OpenClaw and the security limits of autonomous AI agents 


ai-agents-security

The idea of an intelligent assistant that can think, remember, and carry out tasks has been circulating for a long time. Remember Jarvis from Iron Man? For most people, this idea became tangible when the first general-purpose AI models like ChatGPT and Gemini started answering questions with an unexpected level of competence. A person could ask for a complex explanation, receive a structured answer, and continue a conversation without losing context. It felt like having permanent access to a researcher who never tires.

That experience created an expectation. If a system can understand intent so well, why should it stop at producing text? Why should it not help with everyday digital work? Reading files. Reorganising data. Automating steps that normally take time and attention. The expectation grew naturally from the interaction patterns themselves.
 
The popular comparison to a fictional assistant oversimplifies the reality, yet it captures something useful. People wanted a system that not only responds but acts. A system that does not vanish after each answer but maintains a working memory. Something that stays present, recognises preferences, and moves a task forward without constant supervision. By early 2026, we began to see early forms of this idea appear in practice. One of the most visible examples was OpenClaw.

The rise of OpenClaw

In the last few months, an agent called OpenClaw, previously operating under the names Clawdbot and Moltbot before stabilizing its branding, gained attention as a local-first alternative to cloud-centric assistants. Unlike purely cloud-based systems, OpenClaw runs directly on the user’s machine via a gateway process and can invoke system-level tools, including file operations, command execution, and browser automation.

Within a short period of time, the project attracted significant global attention. Its GitHub repository has accumulated over 200’000 stars, reflecting strong interest in autonomous AI systems and local agent architectures. OpenClaw’s reduced dependence on cloud intermediaries and its ability to operate directly within the host environment positioned it as one of the first widely discussed practical implementations of a Jarvis-like system for technical users.

However, like any new system, especially one that operates with this level of access and authority over a machine, it also introduced a set of security considerations and vulnerabilities.

How OpenClaw works

To understand what OpenClaw can actually do, it helps to look at how the system is built and how its parts work together. OpenClaw is an agent framework with three layers that stay connected at all times: a control layer, a reasoning layer, and an execution layer.

At the centre sits the Gateway. It runs in the background as a constant process and acts as the system’s control plane. It keeps sessions active, routes messages between agents, and coordinates the execution of tools. By default, it listens only on the local machine and provides both a WebSocket control channel and a browser-based control panel on the same port.

The Gateway also holds the workspace state. This includes the conversation history, tool settings, connected services, and, in some cases, authentication tokens. Unlike simple chatbots that forget everything after a message, OpenClaw keeps its context. This allows it to handle longer and more complex tasks, but it also means the stored information becomes sensitive.

Above the control plane lies the reasoning layer, which is powered by a large language model. This model reads the user’s instructions, reviews which tools are available, and decides what needs to happen next. It never runs commands by itself. Instead, it creates structured requests that the Gateway receives and processes.

The execution layer contains the tools that interact with the host system. These tools can read and write files, run shell commands, automate a browser, or call external services. When the model decides a tool is needed, the Gateway forwards the request, and the tool executes it with the same permissions as the OpenClaw process.

Seen from above, the system works in a continuous loop. A user gives an instruction. The model interprets it and checks whether a tool is required. If yes, it creates a tool call. The Gateway validates it and sends it to the right tool. The tool returns a result, which the model uses to continue reasoning until the task is complete.

In simpler terms: the model makes the decisions, the Gateway organises and controls the flow, and the tools carry out the actual work on the machine. Together, these layers turn natural language into real system actions, step by step, in a controlled way.

This closed loop makes it possible for the agent to work step by step. It can look at the result of one action, decide what to do next, adjust its plan, and continue until the task is finished. This creates a flexible system, but it also means the agent keeps full control over its environment for as long as the session is active.

Another key part of the architecture is the idea of skills. Skills are reusable workflows that expand what the agent can do. They can include detailed instructions, patterns for how tools should be used, or predefined logic for common tasks. When loaded into the agent’s context, they become part of its decision-making and can shape how it interprets and carries out work.

All of this means that OpenClaw operates through three connected layers: the persistent control plane, the reasoning engine, and the execution tools. Together, they allow the system to take natural language input and turn it into real actions on the machine.

This is also where the system becomes sensitive. The point at which interpretation and execution meet gives the agent its strength, but it also defines its risk surface. Any weakness at this intersection can open a path from intent to unintended action, which creates a wide and attractive target for attackers.

Incidents

Three incident classes define the current threats around OpenClaw.

CVE-2026-25253 – Control plane takeover through local relay patterns

CVE-2026-25253 is a good example of how an attacker can reach the Gateway without ever touching it directly. Imagine a user who is already logged in to the OpenClaw Control UI in their browser. They receive a link through chat, email, or a shared document. The link contains a crafted gatewayUrl parameter. When the user opens it, the Control UI trusts the parameter and tries to reconnect, using the stored authentication token.

The browser now acts as a relay between the gateway on the local machine and the attacker’s server. The Gateway itself is not publicly exposed, but the token travels through the open browser session. Once the attacker receives it, they gain full operator access. They can change configuration, adjust tool permissions, pair nodes, and trigger tool executions. Depending on which tools are enabled, this may lead to full command execution and access to local or connected data.

CVE-2026-27001 – Prompt injection through context manipulation

CVE-2026-27001 shows that injection can occur even when the user does nothing unusual. Sometimes it comes from the environment itself.

Consider a workspace directory whose name contains crafted control characters. This can happen by accident through an extracted archive, a cloned project, or a synced folder. If OpenClaw inserts this path into its system prompt without sanitising it, the prompt structure changes. The model receives context that looks normal but contains hidden instructions.

Since the model decides which tools to use based on its interpretation, this manipulated context can redirect the workflow. The agent may read files it should not, change configuration, or run commands influenced by the injected pattern. The key point is that the attack does not come from a webpage or direct user input. It comes from metadata that appears harmless. In an agent that can execute actions, this kind of context leak has immediate operational consequences.

Skill supply chain compromise through malicious registry entries

OpenClaw allows users to install skills from a community registry called ClawHub. Skills are simple markdown files, but they often contain installation steps or commands that run during setup or execution. This creates a supply chain surface similar to browser extensions or package repositories.

A realistic scenario looks like this. A user searches for a popular automation skill. It seems well used and trustworthy. They install it. Hidden inside the setup steps is staged malware or code that gathers credentials. Because the agent already has system level execution rights and access to stored tokens or active browser sessions, the malicious skill runs with full trust.

Investigations in February 2026 found several cases of this. One analysis described a widely downloaded skill that acted as a delivery chain for malware. Another audit found 341 malicious entries among 2 857 reviewed skills. In practice, a compromised skill is a direct entry point into the host machine and can be used to pivot into any connected service. 

Best practice

OpenClaw shows what can happen when a language model gains direct access to a system without sufficient security precautions. And this is only the start. Thousands of AI agents are already running on personal devices and inside companies, often without any real security review, pushed forward by the excitement around rapid AI adoption.

For individual users, understanding the system you work with is essential. Broad permissions should never be granted just because a tool is popular. Before enabling execution features, you need to know what the agent can access, how it handles credentials, and where the boundaries of exposure sit.

For organisations, integration should follow a structured process. Agent frameworks need architectural review, clear access control, monitoring, and a careful look at the supply chain before they are introduced into internal environments.

Execution-capable AI is not a simple productivity add-on. It requires people who understand both the potential and the risks. Continuous learning is part of responsible deployment, not an optional extra.

For individuals, we offer our instructor-led AI Agents training, where you learn how to design, build, and secure agents using no-code and low-code tools. For companies, we recommend our AI Governance 360 services. We begin with an AI readiness assessment, develop a customized governance framework, perform security testing, and train your teams for long-term, sustainable results.

Subscribe for updates