OpenClaw Security & Privacy: What You Need to Know Before Running an AI Agent

Running an autonomous AI agent on your machine is a fundamentally different risk profile than using a chatbot. When you give an agent the ability to read files, execute code, browse the web, and call APIs, you are handing it real power — and real power needs real guardrails.

This guide covers what OpenClaw does (and does not do) to keep your system and data safe. No hype, no fear — just the practical tradeoffs you should understand before running it.

The core risk: agents take actions

A chatbot produces text. An agent produces actions. That difference is everything from a security perspective.

When you run an OpenClaw agent, it can:

• Read and write files on your machine (within configured paths)
• Execute arbitrary code (Python, JavaScript, Bash)
• Make network requests to external services
• Access environment variables (which may contain API keys)
• Interact with databases

Each of these capabilities creates an attack surface. The question is not "is it perfectly safe?" — nothing is. The question is: what controls exist, and are they sufficient for your use case?

OpenClaw's permission model

OpenClaw uses a layered permission system:

Tool-level permissions

Each tool can be individually enabled or disabled in the config:

tools:
  file_system:
    enabled: true
    allowed_paths: ["/home/user/projects"]
    denied_paths: ["/etc", "/var", "~/.ssh"]
  code_execution:
    enabled: true
    languages: [python, javascript]
    timeout: 30
  web_browsing:
    enabled: false  # Disabled entirely
  api_calls:
    enabled: true
    require_confirmation: true

Action confirmation

When confirm_actions is set to true, the agent will pause before executing any potentially destructive action and ask for your approval:

Agent wants to execute: rm -rf ./build/
Allow? [y/N]

This is the most important safety feature for local use. Keep it on.

Path restrictions

File system access can be scoped to specific directories. The agent cannot read or write outside the allowed paths. This is enforced at the tool level before the underlying system call.

Runtime isolation

Sandboxed code execution

When sandbox: true is configured, OpenClaw runs generated code in a restricted environment:

• Separate process — Code runs in a child process, not in the agent's main runtime
• Resource limits — CPU time, memory, and disk usage are capped
• Network restrictions — Outbound network access can be blocked in sandbox mode
• Filesystem scope — The sandbox only sees the allowed workspace directory

Docker isolation

Running OpenClaw in Docker provides a stronger isolation boundary:

• The agent cannot access your host filesystem (unless you mount it)
• Network access can be restricted via Docker's network policies
• Resource limits are enforced by the container runtime
• You can run disposable containers that are destroyed after each session

This is the recommended approach for running untrusted or experimental agents.

Data exposure risks

What data can the agent see?

By default, the agent can access:

1. Files in allowed paths — Everything you grant access to
2. Environment variables — Including API keys if they are set in your shell
3. Command output — Results of any shell commands it executes
4. Network responses — Data from any API calls or web requests it makes

What data leaves your machine?

This depends on your model configuration:

Sensitive data mitigation

If you work with sensitive codebases or data:

1. Use a local model — Ollama keeps everything on your machine
2. Restrict paths carefully — Only grant access to the specific directories needed
3. Disable web browsing — Prevents any data from being sent to external sites
4. Review the execution log — openclaw history shows every action and data flow
5. Use Docker — Run the agent in a disposable container with no access to your broader filesystem

Network security

Outbound connections

By default, OpenClaw makes outbound connections for:

• Model API calls — To your configured LLM provider
• Web browsing — If enabled, to any URL the agent decides to visit
• API tool calls — To any endpoint the agent decides to call

Risks to consider

• Data exfiltration — A malicious or confused agent could send sensitive data to an external server via web browsing or API calls
• Prompt injection — If the agent reads untrusted content (web pages, user inputs), that content could manipulate the agent's behavior
• Supply chain risks — Third-party plugins could contain malicious code

Mitigations

• Disable web browsing for sensitive projects
• Use require_confirmation: true for API calls
• Only install plugins from trusted sources
• Monitor outbound network traffic if running in a sensitive environment

Comparison: OpenClaw vs. a controlled application

If you are deciding between running OpenClaw as-is versus building a more controlled system, here is how the security posture differs:

For internal use and development, OpenClaw's security model is reasonable. For a product that handles user data, you need more.

Practical security checklist

Before running OpenClaw on any important project, go through this checklist:

Configuration

• Set confirm_actions: true
• Set sandbox: true for code execution
• Scope allowed_paths to only the directories you need
• Add sensitive directories to denied_paths (~/.ssh, ~/.aws, etc.)
• Set a reasonable max_iterations limit (25 or less for new setups)
• Set a timeout to prevent runaway agents

Environment

• Do not run OpenClaw as root
• Use a dedicated directory for agent workspaces
• Consider running in Docker for additional isolation
• Keep API keys in a separate secrets manager, not shell environment variables

Monitoring

• Review openclaw history after each session
• Monitor network traffic if handling sensitive data
• Check tool call logs for unexpected file access or API calls

Updates

• Keep OpenClaw updated — security patches ship regularly
• Review changelogs before updating to understand what changed
• Test updates in a non-critical environment first

When OpenClaw's security model is not enough

There are legitimate cases where OpenClaw's built-in security is insufficient:

• Multi-user products — You need per-user isolation, auth, and access control
• Regulated industries — Healthcare, finance, and government require compliance frameworks
• Customer-facing applications — Users should never interact directly with an unguarded agent runtime
• High-value data — Source code, credentials, and PII need stronger boundaries than config-file permissions

In these cases, you want a system where security is designed into the architecture — not bolted on via config flags.

From the maker

Need tighter control over your AI stack?

AnotherWrapper gives you a production-ready foundation with Supabase auth, row-level security, API route protection, and isolated AI integrations. Build a secure product without starting from zero.

See the security architectureView Demo Apps

“Tried a couple different boilerplates but AnotherWrapper is super polished and the unified dashboard feature sold me on it.”

Farez

·

Ex-AWS / Warner Bros, 8yr in tech

Verified on Discord

Trusted by 2,000+ founders · One-time payment · Lifetime updates

Bottom line

OpenClaw's security is good enough for local development and personal use, especially with the right configuration. But it is not a production security architecture.

If you are using OpenClaw to automate your own workflows, configure it carefully, run it in Docker, and review the logs. If you are building a product for other people, you need a proper application layer with auth, isolation, and audit trails.

Security is not a feature you add later. It is a design decision you make at the beginning.

Frequently asked questions

Does OpenClaw send my data to external servers?

It depends on your model configuration. If you use a cloud model (OpenAI, Anthropic), your prompts and tool results are sent to that provider. If you use Ollama with a local model, nothing leaves your machine. Web browsing and API tools also make external requests when enabled.

Can OpenClaw access my SSH keys or credentials?

Only if you grant access to those directories. By default, add ~/.ssh, ~/.aws, ~/.config, and any credentials directories to your denied_paths config. The file system tool respects path restrictions, but sandboxing adds an additional safety layer.

Is it safe to run OpenClaw on a production server?

OpenClaw is designed for local development use. Running it on a production server requires Docker isolation, strict path restrictions, disabled web browsing, and careful monitoring. For production AI products, build a purpose-built application with proper security architecture.

Related reading:

• What is OpenClaw? — Full overview of the framework
• How to Install OpenClaw — Setup with proper security configuration
• OpenClaw Alternatives — Compare options including more controlled approaches