OpenClaw spread quickly because it is useful. It is risky for the same reason.

OpenClaw connects language models directly to where work happens: inboxes, chat, files, calendars, browsers, and system commands. Once an assistant moves from answering questions to taking actions, the security model changes. The core risk is not a bad response, but a real operation executed with real privileges based on input that can be influenced by others.

Learn more in the Foundations of AI Security Learning Lab Series - Register now

What is OpenClaw

OpenClaw is an open source agent assistant that runs on a user device or server and interacts through common enterprise and consumer messaging platforms. It integrates with external tools so it can take actions, not just generate text.

It gained attention under earlier names, including ClawdBot and MoltBot. The rapid rebranding also introduced confusion and impersonation risk, a common pattern when open source agent projects gain rapid adoption.

Why OpenClaw matters to enterprise security

• OpenClaw adoption often happens outside security review. Installations appear on personal devices, servers, or dev machines and connected to work accounts. Shadow IT with much higher risk because the agent can act.
• Execution is the inflection point. When an agent can call tools with write access, every message becomes a potential trigger, and every trigger can become a state change in a real system.
• Agents do not stop at answers. They read. They decide. They act.

OpenClaw threat model

• Message-driven execution
  The agent sits inside inboxes and chat systems where approvals, links, and secrets live. If the agent reads untrusted content containing a prompt injection, it can be compromised and take harmful actions. 
  
• Tool access with user permissions
  The agent controls calendars, browsers, file systems, shells, and SaaS apps with write access and often inheriting the same privileges as the installing user.
  
• Persistent and Exposed Control Surfaces
  The install sets up a gateway service that stays running, so it creates an always-on access path that needs to be locked down. Most users are not familiar with the right hardening steps and the gateway can end up exposed and unsecured. This is already occurring at scale, a high number of exposed gateways are in the wild.

Common OpenClaw security risks

• Prompt injection through everyday content attackers can place instructions in emails, messages, or linked content that the agent consumes. The risk expands as the agent becomes more useful. 
  
• Data exfiltration through legitimate channels The agent reads files and forwards content through chat or email surfaces that appear in ways that look like normal activity.
  
• Privilege creep as users connect more tools, tokens accumulate. Permissions expand, and no one revalidates blast radius.
  
• Endpoint and server compromise pathways If the agent runs locally with broad access, compromise can become host compromise. Zenity Labs called out the lack of sandboxing and permission control by default as a key risk factor.
  
• Impersonation and copycats, rebranding and forks confuse users. Attackers exploit trust in trending agent tools.
  
• OpenClaw is a symptom, not the disease. OpenClaw did not create this risk. It revealed it.

The same failure pattern appears across agent assistants.

• Agents act on behalf of users.
• Agents chain tools across systems.
• Agents store memory and context.
• Agents inherit permissions without lifecycle control.
• Agents blur intent and execution.

Security teams lose when they treat agents as chatbots. Security teams win when they treat agents as identities with execution paths.

OpenClaw exposed the pattern quickly. Copilot extensions, internal agents, and low code workflows repeat it at scale.

Evidence from real world abuse

ClawdBot research documents how agent assistants are coerced through message flows and tool access. Small visibility gaps become execution risk.

These findings apply across agent assistants. Prompt driven execution and chained actions create exposure wherever agents operate.

Sign up for real-time research updates from Zenity Labs

How to secure OpenClaw and agent assistants

Use this checklist to assess OpenClaw and agent assistant exposure

1. Agent inventory
   1. Identify agents, runtime locations, and connected message surfaces.
2. Ownership and accountability
   1. Assign a human owner to every agent and tool connection.
   2. Track which human or service identity the agent operates under.
3. Least privilege tool access
   1. Default to read-only connectors where possible
   2. Separate “read context” from “write actions.” If an agent needs to write, require explicit allowlists of actions or targets.
4. Put hard boundaries around execution
   1. Define which tools the agent can call, and which parameters are allowed
   2. Restrict where the agent can send data, especially external messaging and email destinations.
   3. Create guardrails for high-risk actions: exporting files, sharing links, creating OAuth tokens, changing permissions.
5. Step-level visibility
   1. What input triggered the agent
   2. What tool it invoked
   3. What arguments were passed
   4. What the tool returned
   5. What action was taken
6. Enforce policy at runtime, not just at configuration
   1. Evaluate agent actions at execution time, not just at deploy time
   2. Block or require approval for actions that violate policy, even if the agent is otherwise authorized
   3. Enforce rules on data movement, tool usage, and destination context (for example internal vs external)
   4. Continuous monitoring of agent behavior shifts through prompts, memory, models, and tools.
   5. Treat policy violations as security events, not application errors

How Zenity Secures Agent Assistants

Zenity secures agent assistants across discovery, governance, and threat protection.

Zenity maps agents, ownership, permissions, integrations, memory usage, and execution paths. Zenity enforces policy at the agent layer and blocks risky behavior before damage occurs.