Introduction: Why OpenClaw Security Matters Right Now

OpenClaw is changing how businesses automate workflows. It connects to APIs, runs browser actions, and handles internal tools. But here’s the problem: most security teams aren’t ready for it.

AI agents like OpenClaw don’t fit neatly into traditional security models. They operate with human permissions. They execute tasks on their own. And they process untrusted content as input. All of this happens outside the view of your existing security tools.

This guide gives you a complete OpenClaw security controls checklist. We’ll cover everything from initial setup to production hardening. You’ll learn about real vulnerabilities, including a 1-click RCE found in January 2026. We’ll walk through specific configurations, tool restrictions, and audit processes. By the end, you’ll have a clear path to running OpenClaw safely in your environment.

Understanding the OpenClaw Security Model

Before you can secure OpenClaw, you need to understand how it thinks about security. The core concept is what the documentation calls “scope-first: personal assistant security model.”

What Makes OpenClaw Different From Traditional Software

Traditional applications have clear boundaries. A user clicks a button, and the app does one thing. OpenClaw doesn’t work that way.

An AI agent makes decisions. It interprets requests. It chains together multiple actions to complete a task. This flexibility is powerful, but it creates new attack surfaces.

Consider this scenario: A user asks OpenClaw to “summarize the latest sales report.” Sounds harmless, right? But the agent might:

• Access file systems to find the report
• Read sensitive data in the document
• Send information to external services for processing
• Cache data in logs that persist on disk

Each step introduces risk. And traditional security tools won’t catch any of it.

The Gateway and Node Trust Concept

OpenClaw uses a gateway architecture. Think of the gateway as the front door to your agent. It controls who gets in and what they can do.

The gateway has several key settings:

• Mode: Can be “local” or “remote”
• Bind: Controls network interface binding
• Auth: Handles authentication methods

Here’s a basic secure configuration:

gateway: { mode: “local”, bind: “loopback”, auth: { mode: “token”, token: “replace-with-long-random-token” } }

This setup binds the gateway to localhost only. It requires token authentication. No remote access without explicit configuration.

Trust Boundary Matrix Explained

The OpenClaw documentation includes a trust boundary matrix. This tells you what to trust and what to verify.

This matrix guides your hardening decisions. Components with low trust need more controls.

What’s NOT a Vulnerability by Design

The OpenClaw team is clear about certain behaviors. Some things that look like security issues are actually intentional design choices.

These include:

• Agents can read files in their workspace
• Session logs are stored on disk by default
• Tools can execute code when explicitly enabled

Understanding these design decisions helps you focus on real risks. Don’t waste time “fixing” things that work as intended.

Running the Built-In Security Audit

OpenClaw includes a built-in security audit tool. Run this first. Before you do anything else.

Quick Check: OpenClaw Security Audit Command

The audit command scans your configuration and flags potential issues. It’s fast and catches common mistakes.

The audit checks several areas at a high level:

• Gateway configuration – Is it bound to localhost?
• Authentication settings – Are tokens strong enough?
• Tool permissions – Which tools are enabled?
• File system access – Is workspace isolation on?
• Execution policies – Can code run without approval?

Think of this audit as your first line of defense. It won’t catch everything, but it catches the obvious stuff.

Understanding Audit Results

The audit returns findings in categories. Each finding has a severity level.

Critical findings need immediate attention. These are things like:

• Gateway bound to public interface without auth
• Execution security set to “allow”
• Admin tools enabled for all users

High findings should be fixed soon. Examples include:

• Weak or default tokens
• Sandboxing disabled
• Audit logging turned off

Medium findings are worth addressing but less urgent. Low findings are informational.

Creating Your Audit Schedule

Don’t run the audit once and forget about it. Configurations change. New risks emerge.

A good schedule looks like this:

• Run audit before any production deployment
• Run audit after configuration changes
• Run audit weekly as a baseline check
• Run audit after OpenClaw updates

Automate this if possible. Add it to your CI/CD pipeline. Make it part of your deployment checklist.

Security Audit Glossary

The audit uses specific terms. Here’s what they mean:

• DM Scope: Direct message scope. Controls how sessions are isolated.
• Tool Profile: Preset collection of enabled tools.
• Workspace Only: Restricts file access to agent’s workspace.
• Elevated Mode: Allows admin-level tool access.

Know these terms. They’ll appear throughout your security work.

Hardening Gateway Configuration

The gateway is your main security control point. Get this right, and you’ve solved half your problems.

Binding and Network Isolation

The first decision: where can the gateway be reached?

For personal use, bind to loopback only:

gateway: { bind: “loopback” }

This means only local connections work. No network access. No remote attacks possible.

For team deployments, you might need network access. In that case, use a reverse proxy with TLS.

Reverse Proxy Configuration

Never expose OpenClaw directly to the internet. Always put it behind a reverse proxy.

Your reverse proxy should handle:

• TLS termination (HTTPS)
• Rate limiting
• Request filtering
• Access logging

Popular options include Nginx, Caddy, or Traefik. Each has good documentation for this use case.

HSTS and Origin Notes

If you’re running OpenClaw over HTTP (even locally), be careful. The documentation warns about this.

HTTP means:

• No encryption for credentials
• Possible request tampering
• Session hijacking risks

For any non-local deployment, use HTTPS. Enable HSTS headers. Set proper origin policies.

Authentication Methods

OpenClaw supports token-based authentication. This is your primary access control.

Strong token practices:

• Generate tokens with at least 32 random characters
• Store tokens securely (not in version control)
• Rotate tokens regularly
• Use different tokens for different environments

The configuration looks like this:

auth: { mode: “token”, token: “your-32-plus-character-random-token-here” }

Don’t use simple passwords. Don’t reuse tokens across deployments. Treat these like API keys.

Insecure or Dangerous Flags Summary

Some flags should never be enabled in production. The documentation calls these out specifically.

Review your config for these flags. If any are enabled, have a documented reason and additional controls.

Control UI Over HTTP Considerations

The OpenClaw control UI provides management access. This is a sensitive interface.

Recommendations for the control UI:

• Don’t expose it to public networks
• Require authentication for all access
• Log all UI interactions
• Consider IP allowlisting

Many security incidents start with exposed admin interfaces. Don’t let OpenClaw be one of them.

Tool Permissions and Least Privilege

Tools are where OpenClaw does real work. They’re also where most security risks live.

Understanding Tool Profiles

OpenClaw groups tools into profiles. Each profile has a different risk level.

The “messaging” profile, for example, is lower risk:

tools: { profile: “messaging” }

It includes tools for communication but excludes dangerous ones like file system access or code execution.

Other profiles offer more power but more risk. Choose the minimum profile that meets your needs.

Tool Deny Lists

Even within a profile, you can block specific tools. This is your fine-grained control.

A production-ready deny list might look like this:

deny: [“group:automation”, “group:runtime”, “group:fs”, “sessions_spawn”, “sessions_send”]

Let’s break this down:

• group:automation – Blocks automated workflow tools
• group:runtime – Blocks code execution tools
• group:fs – Blocks file system tools
• sessions_spawn – Prevents creating new sessions
• sessions_send – Prevents sending to other sessions

This list blocks the most dangerous capabilities. Adjust based on your actual needs.

Reducing Tool Blast Radius

Even allowed tools should have limited impact. This is the “blast radius” concept.

Strategies to reduce blast radius:

• Enable sandboxing for all tool runs
• Restrict file access to workspace only
• Require approval for sensitive actions
• Set timeouts on tool execution

The goal: if something goes wrong, the damage is contained.

Execution Security Settings

The exec setting controls code execution. This is one of your most important security decisions.

Options include:

• deny – No code execution allowed
• ask – Requires user approval each time
• allow – Runs code without approval (dangerous)

For most deployments, use this configuration:

exec: { security: “deny”, ask: “always” }

This blocks automatic execution but allows it with explicit approval. It’s a good balance of security and usability.

Elevated Mode Risks

Elevated mode gives agents admin-level capabilities. It should almost never be enabled.

When elevated mode is on, agents can:

• Access system-level tools
• Modify configurations
• Bypass normal restrictions

Keep it disabled:

elevated: { enabled: false }

If you think you need elevated mode, you probably need a different architecture instead.

Node Execution (system.run) Controls

The system.run capability lets agents execute system commands. This is extremely powerful and dangerous.

Default to blocking it. If you must enable it:

• Limit allowed commands to a whitelist
• Run in a sandboxed environment
• Log every execution with full command details
• Set strict timeouts

Remember: an agent with system.run is essentially a remote shell. Treat it with that level of caution.

Sandboxing and Isolation

Sandboxing is your safety net. When other controls fail, sandboxing limits the damage.

Docker as the Default Sandbox Backend

OpenClaw uses Docker for sandboxing by default. This is documented as the “sandbox-isolated tools” feature.

The sandbox configuration lives under:

agents.defaults.sandbox

Docker sandboxing provides:

• Process isolation from the host
• Network restrictions
• File system boundaries
• Resource limits (CPU, memory)

Make sure Docker is properly configured on your host. A misconfigured Docker daemon can undermine all your sandbox controls.

Enabling Sandbox for Tool Runs

Not all tools run in the sandbox by default. You need to enable this explicitly for high-risk tools.

Best practice: enable sandboxing for:

• Any tool that processes external data
• Code execution tools
• File system tools
• Network tools

The overhead is worth the protection. A sandboxed tool that fails safely is better than an unsandboxed tool that compromises your system.

Network Isolation for Agents

Agents shouldn’t have unrestricted network access. Limit what they can reach.

Network isolation strategies:

• Run agents in dedicated network segments
• Use firewall rules to restrict outbound connections
• Block access to internal services unless explicitly needed
• Log all network activity for review

A compromised agent with network access can pivot to other systems. Isolation prevents this.

Session Isolation: The dmScope Setting

Sessions should be isolated from each other. The dmScope setting controls this.

The recommended setting is:

session: { dmScope: “per-channel-peer” }

This means each channel and peer combination gets its own isolated session. User A’s conversation with the agent is separate from User B’s.

Without proper session isolation, users might access each other’s data. This is especially important in shared environments.

Workspace File Isolation

File system isolation is controlled by the workspaceOnly setting:

fs: { workspaceOnly: true }

When enabled, agents can only access files in their designated workspace. They can’t read your home directory, system files, or other sensitive locations.

This is a basic but important control. Keep it enabled unless you have a specific, documented reason to disable it.

Channel Security: Slack, WhatsApp, and More

OpenClaw connects to various communication channels. Each channel has its own security considerations.

Shared Slack Workspace: Real Risk

The OpenClaw documentation specifically calls out Slack workspaces as a risk area.

In a shared Slack workspace, multiple users can interact with the agent. This creates problems:

• Users might access data they shouldn’t see
• Messages from one user could affect another’s session
• Malicious users could probe the agent for vulnerabilities

If you’re using OpenClaw in Slack, think carefully about who has access to the workspace.

Company-Shared Agent: Acceptable Pattern

Despite the risks, company-shared agents can work. The key is proper configuration.

An acceptable pattern includes:

• Strong session isolation (per-channel-peer)
• Limited tool access
• No sensitive data processing
• Audit logging enabled

The documentation suggests this is acceptable when combined with proper controls. But “acceptable” isn’t the same as “recommended.”

WhatsApp Channel Configuration

WhatsApp has its own security settings:

channels: { whatsapp: { dmPolicy: “pairing”, groups: { “*”: { requireMention: true } } } }

Let’s break this down:

• dmPolicy: “pairing” – Requires a pairing process for direct messages
• requireMention: true – Agent only responds when explicitly mentioned in groups

The requireMention setting is important for groups. Without it, the agent could respond to every message, creating noise and potential security issues.

Shared Inbox Quick Rule

The “shared inbox quick rule” is a simple guideline: if multiple people share an inbox, reduce agent capabilities.

This means:

• Fewer tools enabled
• No sensitive data access
• Stricter approval requirements
• More aggressive logging

Shared access increases risk. Compensate with tighter controls.

Strangers and Public Rooms

One community discussion warns about “strangers/public rooms access to high-risk” tools.

Never give public users access to powerful tools. This should be obvious, but it’s worth stating explicitly.

For public-facing agents:

• Use the most restrictive tool profile
• Disable all file system access
• Block code execution completely
• Rate limit aggressively
• Monitor for abuse patterns

Public agents are constantly being probed. Assume attackers will find every weakness.

Logging, Monitoring, and Audit Trails

You can’t secure what you can’t see. Logging and monitoring are essential for OpenClaw security.

Local Session Logs Live on Disk

OpenClaw stores session logs locally by default. The documentation notes: “local session logs live on disk.”

This has implications:

• Logs may contain sensitive conversation data
• Anyone with disk access can read them
• Logs persist until explicitly deleted

Protect your log files. Set proper file permissions. Consider encryption at rest.

What to Log for Security

Not all logs are equal. For security, focus on:

• Authentication attempts (success and failure)
• Tool invocations with parameters
• File access operations
• Configuration changes
• Error conditions

These logs help you detect attacks and investigate incidents.

Full Audit Logging for High-Risk Actions

The Valletta Software guide emphasizes “full audit logging” as a hardening priority.

High-risk actions need detailed logs:

• Who requested the action
• What the action was
• When it happened
• What parameters were used
• What the result was

Store these logs securely. Consider sending them to a central logging system where they can’t be tampered with.

Detecting Prompt Injection Attempts

Prompt injection is a growing attack vector. Your logs can help detect attempts.

Look for patterns like:

• Unusual formatting in user messages
• References to system prompts
• Attempts to change agent behavior
• Repeated requests with slight variations

Build detection rules for these patterns. Alert your security team when they trigger.

Context Visibility Model

The “context visibility model” defines what information agents can see and share.

In your logging, track context flows:

• What context did the agent have for each action?
• Did context leak between sessions?
• Was sensitive context exposed to unauthorized users?

This helps identify configuration problems and potential data leaks.

Credential and Secret Management

OpenClaw often needs credentials to do its work. How you manage these credentials affects your overall security.

Credential Storage Map

The documentation mentions a “credential storage map.” This is a reference to where different credentials are stored.

Know where your credentials live:

• Configuration files (avoid when possible)
• Environment variables (better)
• Secret management systems (best)
• Hardware security modules (for high-security needs)

Map out every credential OpenClaw uses. Document where each one is stored.

Published Package Dependency Lock

The security documentation mentions “published package dependency lock.” This relates to supply chain security.

When OpenClaw installs packages:

• Use locked dependency files
• Verify package signatures
• Audit new dependencies before adding them
• Monitor for known vulnerabilities

Supply chain attacks are real. An compromised package can undermine all your other security controls.

Token Rotation Practices

API tokens and authentication tokens should be rotated regularly.

A good rotation schedule:

• Gateway tokens: every 90 days
• External API keys: based on provider recommendations
• After any suspected compromise: immediately

Automate rotation when possible. Manual processes get forgotten.

Secrets in Configuration Files

Never commit secrets to version control. This is basic security hygiene.

Better approaches:

• Use environment variables for secrets
• Reference external secret stores
• Use template files with placeholders
• Implement pre-commit hooks to catch accidental commits

If you’ve ever committed a secret, assume it’s compromised. Rotate it immediately.

Integration API Security

OpenClaw integrates with external APIs. Each integration is a potential security risk.

For each API integration:

• Use least-privilege access (minimal scopes)
• Store credentials securely
• Monitor for unusual usage patterns
• Have a revocation plan if compromised

Your OpenClaw security is only as strong as your weakest integration.

Deployment and Host Trust

Where you run OpenClaw matters as much as how you configure it.

Installation in Isolated Environments

The Medium security guide recommends: “Installed in isolated” environments.

This means:

• Dedicated VMs or containers for OpenClaw
• No shared services on the same host
• Network segmentation from other systems
• Minimal software installed

Isolation limits the impact of a compromise. If OpenClaw is breached, attackers shouldn’t be able to pivot to your database server.

Hardened Baseline in 60 Seconds

The documentation mentions a “hardened baseline in 60 seconds.” This is a quick-start secure configuration.

The example configuration provided covers:

• Local gateway binding
• Token authentication
• Per-channel session isolation
• Messaging tool profile
• Blocked dangerous tool groups
• Workspace-only file access
• Denied execution security
• Disabled elevated mode

Start with this baseline. Adjust only when you have a specific need and understand the security implications.

Dynamic Skills: Watcher and Remote Nodes

Dynamic skills add flexibility but also risk. These include watchers and remote nodes.

Watchers can:

• Load new skills automatically
• Execute code from external sources
• Modify agent behavior at runtime

If you use dynamic skills:

• Verify the source of all skills
• Run skills in sandboxed environments
• Log skill loading and execution
• Have approval processes for new skills

Remote nodes are similar. They extend OpenClaw’s capabilities but require careful trust management.

January 2026 CVE: Lessons Learned

The Valletta Software guide mentions “a real CVE (January 2026) showed 1-click RCE in OpenClaw, found by an AI pentester.”

This tells us several things:

• OpenClaw has had serious vulnerabilities
• AI-powered security testing is finding real issues
• Staying updated is critical

Keep OpenClaw updated. Watch for security advisories. Have a patching process ready.

OS-Level Hardening

Don’t forget the host operating system. OpenClaw’s security depends on it.

OS hardening basics:

• Keep the OS updated
• Disable unnecessary services
• Configure proper user accounts
• Enable host-based firewall
• Use disk encryption

A secure OpenClaw configuration on a compromised OS provides no real protection.

For CISOs: Building an AI Agent Security Program

Individual controls matter. But CISOs need a program-level view.

Asset Inventory: The Foundation

The Zenity guide notes that “CIS Critical Security Controls identify asset inventory as the foundation for all other controls.”

For OpenClaw, asset inventory means:

• How many OpenClaw instances are running?
• Where are they deployed?
• What channels are they connected to?
• What tools do they have access to?
• What data can they access?

You can’t secure what you don’t know exists. Start with a complete inventory.

Documenting Actions and Systems

The Zenity checklist recommends: “Document all actions and systems tied to the agent.”

This documentation should include:

• Every external system the agent connects to
• Every action the agent can take
• Data flows in and out of the agent
• Business processes the agent supports

This documentation is essential for risk assessment and incident response.

The Eight Critical Controls

The Zenity guide outlines “eight critical controls that form the foundation for AI agent security.”

These controls address the unique risks of AI agents:

• Control 1: Asset discovery and inventory
• Control 2: Access management and authentication
• Control 3: Tool and capability governance
• Control 4: Data access controls
• Control 5: Execution environment security
• Control 6: Logging and monitoring
• Control 7: Incident response procedures
• Control 8: Continuous assessment and improvement

Build your program around these controls. They address the specific challenges AI agents create.

Addressing the Policy Gap

The Zenity guide observes that OpenClaw “is increasingly being adopted across enterprises, often faster than security policies and controls can adapt.”

You need policies for:

• Who can deploy AI agents
• What approvals are required
• What configurations are acceptable
• How incidents should be handled

Don’t let adoption outpace governance. Update your policies to address AI agents explicitly.

Operating Outside Traditional Controls

The Zenity analysis notes that OpenClaw operates “outside centralized security controls while maintaining access to enterprise systems.”

This is a fundamental challenge. Your existing security tools may not see OpenClaw activity.

Solutions include:

• Dedicated monitoring for AI agent activity
• Integration with SIEM systems
• Custom detection rules for agent behaviors
• Regular security reviews and audits

If your security operations center can’t see OpenClaw, they can’t protect it.

The Attack Surface Shift

AI agents create new attack surfaces. They blur boundaries between user intent and machine execution.

Traditional security assumes humans make decisions. AI agents make decisions on their own. This changes the threat model.

Consider attacks like:

• Prompt injection through untrusted content
• Social engineering the agent directly
• Exploiting autonomous decision-making
• Manipulating agent behavior through context

Your security team needs training on these new attack vectors.

Complete OpenClaw Security Controls Checklist

Here’s your comprehensive checklist. Use it for new deployments and periodic reviews.

Pre-Deployment Checklist

Logging and Monitoring Checklist

Credential Management Checklist

Channel Security Checklist

Host and Network Checklist

Governance Checklist

Conclusion

OpenClaw security isn’t optional. It’s not something you can add later. Start with the hardened baseline configuration. Run the built-in audit before every deployment. Lock down tools to the minimum your use case needs.

AI agents blur the line between users and automated systems. Traditional security controls weren’t built for this. Use this checklist to close the gaps. Review your configuration regularly. Stay updated on vulnerabilities. And remember: security is a process, not a destination. Your OpenClaw deployment is only as secure as your ongoing commitment to keeping it that way.

Frequently Asked Questions About the OpenClaw Security Controls Checklist