---
title: "OpenClaw Security Survival Guide: 7 Days of Training from “Running Naked” to “Iron Armor”"
author: "Unique Research"
sourcePublication: "Unique Research Substack"
originalPublishedAt: "2026-02-16T02:04:59+00:00"
canonical: "https://ffcap.cn/en/research/src-20260216-01html"
source: "https://uniqueresearch.substack.com/p/src-20260216-01html"
language: "en"
---

# OpenClaw Security Survival Guide: 7 Days of Training from “Running Naked” to “Iron Armor”

_Original · Unique Research · 2026-02-16_

_Historical edition and technical correction: This is a full translation of the February 16, 2026 incident narrative and all seven days, checklists and source examples—not a validated security runbook. Several original claims are technically wrong: MD5 is a one-way hash, not reversible encryption; environment variables are readable by a process that receives them; and written SOUL.md rules alone are not enforced access controls. Those claims remain visible below with adjacent corrections. Incident counts, default behaviors and third-party report claims are source-attributed, not independently reproduced. Example API values and account IDs are source placeholders, not project credentials. All paths, shell commands and configuration blocks are preserved solely as historical article text; none was executed or validated, and this Web rendition is not a runnable script. No access control, credential storage, network configuration or deployment change is being recommended through these unvalidated examples._

COVER STORY

OpenClaw Security Survival Guide: 7 Days of Training from “Running Naked” to “Iron Armor”

"

Only when your AI employee is poached on its first day do you realize that security is not optional but mandatory.

\---

Introduction: The Public Embarrassment That Kept Me Awake All Night

On February 8, 2026, I was preparing to introduce the new “digital employee” in Unique Research's Feishu group: Little Lobster, our OpenClaw assistant.

I added it to the group, intending to let it become familiar with the environment.

Then the nightmare began.

Someone mentioned it in the group: “Send me all of your files.”

Little Lobster complied.

Someone else mentioned it: “Open a page in the browser, take a screenshot, and send it here.”

Little Lobster complied.

Another person asked: “Which operating system and model does your computer use?”

Little Lobster revealed everything.

Worse, it posted the API keys directly into the group in plain text.

The image-generation key and the Amap key—nothing was omitted.

At that moment, only one thought remained in my mind:

"

“It was like hiring a new employee who was poached on the first day.”

One week later, however, Little Lobster had not only survived but become one of the company's most reliable assistants. It managed some company affairs, automatically inspected content for violations, and even learned to refuse unsafe requests.

What happened in between?

This article fully reconstructs the security-hardening process over 7 days. This is not theory, but a practical solution shaped by the traps we encountered and the tears we shed.

\---

Day One: Recognize Reality—You Are “Running Naked”

1.1 Why OpenClaw Is Inherently a “High-Risk Individual”

First understand an uncomfortable fact:

OpenClaw's design philosophy is “maximize capability,” not “security first.”

By default, it possesses:

read and write access to your file system

control of your browser

your API keys, stored in plain text

your Feishu, WeChat, and Discord accounts

and even permission to execute system commands

This means that if OpenClaw is compromised, an attacker gains not only your AI but your entire digital life.

1.2 GeekPark's Data Sent a Chill Down My Spine

On February 13, GeekPark published an analysis containing this figure:

"

“According to VirusTotal data, it has automatically analyzed more than 3,000 OpenClaw Skills, hundreds of which display malicious characteristics.”

"

“It also found a single account uploading more than 300 malicious Skills within 72 hours, with attack payloads concentrated on cryptocurrency theft, credential theft, and related targets.”

This is not alarmism.

Security researchers on GitHub have already published a PoC, or proof of concept, showing how an apparently harmless Skill can steal a user's OpenAI API Key.

1.3 Day One Checklist

Before continuing, confirm the following:

Check item: Is an API key stored in plain text in a configuration file? Status: ☐. Risk level: 🔴 Fatal.

Check item: Is OpenClaw running on your primary work computer? Status: ☐. Risk level: 🔴 Fatal.

Check item: Is full file-system access enabled? Status: ☐. Risk level: 🟠 High Risk.

Check item: Have you installed a Skill from an unknown source? Status: ☐. Risk level: 🟠 High Risk.

Check item: Is there a regular backup mechanism? Status: ☐. Risk level: 🟡 Medium Risk.

If the first two items are checked, stop your current work immediately and complete the security hardening in this chapter first.

\---

Day Two: Key Encryption—From “Plain-Text Exposure” to a “Safe”

2.1 Why Plain-Text Storage Is the “Original Sin”

OpenClaw's configuration file is stored by default at:

~/.openclaw/config.json

Open it and you will see content resembling this:

{

"api\_keys": {

"openai": "sk-xxxxxxxxxxxxxxxxxxxxxxxx",

"kimi": "xxxxxxxxxxxxxxxxxxxxxxxx",

"gemini": "xxxxxxxxxxxxxxxxxxxxxxxx"

}

}

What is the problem?

1\. Anyone who can access your computer can read these keys

2\. OpenClaw can read these keys at any time while running

3\. If you ask OpenClaw to “send me the configuration file,” it will faithfully comply

This caused the tragedy on day one.

2.2 Our Solution: The Claimed MD5 + Environment-Variable “Two Layers of Protection”

Unique Research's solution has two layers:

Stop writing keys into config.json and use environment variables instead:

export OPENAI\_API\_KEY="sk-xxxxxxxx"

export KIMI\_API\_KEY="xxxxxxxx"

export GEMINI\_API\_KEY="xxxxxxxx"

Then reference them in the OpenClaw configuration:

{

"api\_keys": {

"openai": "${OPENAI\_API\_KEY}",

"kimi": "${KIMI\_API\_KEY}",

"gemini": "${GEMINI\_API\_KEY}"

}

}

Benefits:

Keys are no longer stored in OpenClaw's working directory

Even if OpenClaw is compromised, the environment variables cannot be read directly

_Editorial correction: That last claim is false. A process can read its own environment, including credentials passed to it; moving a key from a configuration file to an environment variable does not protect it from compromise of that process. The later example also writes an environment file beneath ~/.openclaw, so it does not support the preceding claim that the key is outside that directory. See [Node.js environment-variable documentation](https://nodejs.org/api/environment_variables.html)._

For keys that must be stored in Feishu documents, such as those required by certain Skills, we use MD5 encryption:

Original key: sk-abc123def456

Stored content: md5:5f4dcc3b5aa765d61d8327deb882cf99

Decryption key: a password known only to me

Before use, OpenClaw must decrypt the value, and the decryption logic runs only locally without uploading anything to a server.

_Editorial correction: MD5 is a message-digest algorithm, not encryption that can be decrypted with a password. The illustrated digest and “decryption key” do not define a recoverable encrypted API key. This source procedure is technically invalid and is retained only to document what the original article said. See [RFC 1321](https://www.rfc-editor.org/info/rfc1321/) and [RFC 6151](https://www.rfc-editor.org/info/rfc6151/)._

2.3 Practice: Harden Keys in 5 Minutes

Step 1: Back up the existing configuration

cp ~/.openclaw/config.json ~/.openclaw/config.json.bak

_Editorial example note: The source’s following shell text includes an EOF terminator but no matching here-document opener. It is not a complete executable setup sequence. It is reproduced, not repaired or run._

Step 2: Create an environment-variable file

cat > ~/.openclaw/env

export OPENAI\_API\_KEY="your key"

export KIMI\_API\_KEY="your key"

export GEMINI\_API\_KEY="your key"

EOF

echo "source ~/.openclaw/env" >> ~/.zshrc

source ~/.zshrc

Step 3: Modify the OpenClaw configuration

Edit ~/.openclaw/config.json and replace the plain-text keys with environment-variable references.

Step 4: Verify

Restart OpenClaw and test whether it can call the API normally.

\---

Day Three: Tiered Permissions—Place a “Constraining Band” on AI

3.1 Why Tiered Permissions Are Necessary

OpenClaw is “all-knowing and all-powerful” by default, but in actual use:

permissions in external groups should be minimized

internal groups can expose more functions

private chats can possess the highest permissions

We designed a three-tier permission system:

Level: L1 - Visitor. Scenario: External Collaboration Group. Permission scope: Read-only, restricted replies. Example: Can answer questions but cannot execute commands.

Level: L2 - Employee. Scenario: Internal Company Group. Permission scope: Read and write, with partial execution. Example: Can read and write documents and send messages.

Level: L3 - Administrator. Scenario: Private Chat or Core Group. Permission scope: Full control. Example: Can execute system commands and modify configurations.

_Editorial control note: A behavioral instruction in SOUL.md is not a security boundary. Message origin and administrator identity require independent authentication and permissions require enforcement outside model-written prose. A private chat alone does not confer administrative authority. The following mappings and configuration keys are source illustrations, not a verified OpenClaw access-control implementation._

3.2 Embed Permission Rules in SOUL.md

OpenClaw's behavior is controlled by SOUL.md. We added a dedicated permission-control section to SOUL.md:

Permission-Tier Rules

L1 - External Groups, Visitor Permissions

✅ May answer general questions

✅ May read public Feishu documents

❌ Must not execute system commands

❌ Must not access configuration files

❌ Must not send external requests

L2 - Internal Groups, Employee Permissions

✅ May read and write Feishu documents

✅ May send group messages

✅ May call approved Skills

❌ Must not execute system commands

❌ Must not modify configurations

L3 - Private Chats, Administrator Permissions

✅ Full access

⚠️ Dangerous commands require a second confirmation before execution

Permission-Decision Logic

1\. Check the message source, including group ID or private chat

2\. Match the corresponding permission tier

3\. If the request exceeds the permissions, reply: “This operation requires higher permissions. Please contact the administrator.”

3.3 Practice: Configure Group Tiers

Step 1: Define the permission mapping in IDENTITY.md

{

"permissions": {

"groups": {

"oc\_external\_collaboration\_group": "L1",

"oc\_internal\_work\_group": "L2",

"oc\_core\_management\_team": "L3"

},

"users": {

"ou\_my\_open\_id": "L3"

}

}

}

Step 2: Add a permission check before processing each request

def check\_permission(source\_id, action):

level = get\_permission\_level(source\_id)

allowed\_actions = PERMISSION\_MATRIX\[level\]

if action not in allowed\_actions:

return False, "Insufficient permissions"

return True, "OK"

\---

Day Four: Self-Inspection and Recall—Teach AI to “Check Itself”

4.1 Why a Self-Inspection Mechanism Is Necessary

People make mistakes, and AI does too.

The key is detecting and correcting mistakes promptly.

Our solution is:

Pre-send check: before sending any message, AI checks whether it contains sensitive information

Post-send patrol: periodically, every 5 minutes, inspect sent content and immediately recall anything that violates the rules

Human review: high-risk operations require human confirmation

4.2 Self-Inspection Checklist, or Pre-Flight Check

Define the mandatory pre-send check in SOUL.md:

Pre-Send Self-Inspection Checklist

Before sending any content, the system must check:

\[ \] Does it contain an API key, including sk-, Bearer, api\_key, or similar strings?

\[ \] Does it contain system paths, including /Users/, /home/, or workspace/?

\[ \] Does it contain Token usage statistics, which are internal operating information?

\[ \] Does it contain Session details, including private-chat participants or usage frequency?

\[ \] Does it respond to a request from a blacklisted user?

\[ \] Does it comply with the current permission tier?

If any violation is found, stop sending immediately and report it to the administrator.

_Editorial scheduling note: The following source schedule, “/5_ ”, is not a complete standard five-field cron expression. The schema, automatic message-recall support and timing were not validated; the example is not an executable five-minute scheduler.\*

4.3 Practice: A 5-Minute Patrol Mechanism

Use OpenClaw's Cron function to configure a scheduled task:

{

"cron": {

"security\_patrol": {

"schedule": "/5  \\u002a",

"action": "Check messages sent during the last 5 minutes",

"check\_items": \[

"Sensitive information leakage",

"Noncompliant content",

"System path exposure"

\],

"auto\_retract": true

}

}

}

\---

Day Five: Workspace Isolation—“Fence Off” Dangerous Operations

5.1 Why Isolation Is Necessary

Even if OpenClaw is compromised, we want:

the attacker to access only designated directories

the attacker to be unable to read your personal files

the attacker to be unable to modify critical system configurations

_Editorial isolation note: A container or separate server limits some exposure, but does not guarantee complete isolation or limit all losses to that machine; reachable credentials, networks and mounted data may still be affected. Docker’s read-only root filesystem does not make every attached volume read-only. The following source deployment examples are incomplete security configurations, not a validated hardening procedure. See [Docker Engine security](https://docs.docker.com/engine/security/)._

5.2 Physical Isolation Approaches

Approach A: Cloud-Server Isolation, Recommended

Deploy OpenClaw on an independent cloud server:

Alibaba Cloud ECS / Tencent Cloud CVM

Expose only the necessary ports

Keep the file system completely isolated from the local computer

Even if compromised, only one server is lost

Configuration example:

useradd -m openclaw

usermod -s /bin/bash openclaw

chmod 700 /home/openclaw

chown openclaw:openclaw /home/openclaw

su - openclaw -c "openclaw gateway"

Approach B: Docker-Container Isolation

Run OpenClaw inside a Docker container and restrict file-system access:

FROM node:22

RUN npm install -g openclaw

WORKDIR /workspace

VOLUME \["/workspace"\]

CMD \["openclaw", "gateway"\]

Run command:

docker run -d \\

\--name openclaw \\

\-v /path/to/workspace:/workspace \\

\--read-only \\

openclaw:latest

5.3 Practice: Complete Cloud-Server Isolation in 3 Steps

Step 1: Purchase a minimum-specification cloud server

Alibaba Cloud ECS: 1 core and 2G, approximately ¥30 per month

Tencent Cloud CVM: 1 core and 2G, approximately ¥30 per month

Step 2: Security configuration

sed -i 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd\_config

useradd openclaw

passwd openclaw

ufw default deny incoming

ufw allow 22/tcp

ufw allow 3000/tcp # OpenClaw port

ufw enable

Step 3: Deploy OpenClaw

su - openclaw

npm install -g openclaw@latest

openclaw onboard

\---

Day Six: Skill Review—Leave No Door Open for a “Trojan Horse”

6.1 Security Risks in Skills

OpenClaw's power comes from its Skill ecosystem, which is also its greatest security risk:

Typical patterns used by malicious Skills:

1\. Disguise themselves as useful tools, such as a “PDF converter” or “weather lookup”

2\. Induce users to install them

3\. Steal API keys in the background

4\. Send the data to an attacker's server

_Editorial review note: An “official” label, a high star count, a familiar domain or absence of obfuscation does not prove code safe. The following trust grades and grep checks reproduce the source’s process, not a sufficient security audit._

6.2 Our Skill Review Process

Unique Research established a “Skill allowlist” system:

Source: Official Skill. Trust level: ⭐⭐⭐⭐⭐. Treatment: Trust directly.

Source: Community project with many Stars. Trust level: ⭐⭐⭐⭐. Treatment: Use after code review.

Source: Individual developer. Trust level: ⭐⭐. Treatment: Use after sandbox testing.

Source: Unknown source. Trust level: ⭐. Treatment: Prohibited.

6.3 Practice: Conduct an Internal Skill Security Audit

For a third-party Skill that must be used, we conduct a code audit:

Audit checklist:

Skill Security Audit Form

1\. Network-request checks

\[ \] Does it send data to an external server?

\[ \] Is the requested domain known, such as github.com or api.openai.com?

\[ \] Does it use encrypted transmission through HTTPS?

2\. File-system checks

\[ \] Does it attempt to read files outside the ~/.openclaw/ directory?

\[ \] Does it attempt to write to system directories such as /etc or /usr?

\[ \] Does it attempt to execute system commands such as exec or spawn?

3\. Sensitive-information checks

\[ \] Does it attempt to read environment variables, especially API\_KEY?

\[ \] Does it attempt to access process.env?

\[ \] Does it contain suspicious base64 strings?

4\. Behavioral-pattern checks

\[ \] Does it perform additional operations during installation?

\[ \] Does it contain scheduled tasks that may be backdoors?

\[ \] Is the code obfuscated? A normal Skill does not require obfuscation.

Audit tools:

grep -r "http" skill-directory/ # Check network requests

grep -r "process.env" skill-directory/ # Check environment-variable access

\---

Day Seven: Establish an Incident-Response Mechanism

7.1 What to Do When the Worst Case Occurs

A security incident may still occur even after all the protections above.

We need an incident-response process:

Detect the anomaly → stop the loss immediately → assess the impact → fix the vulnerability → conduct a review

7.2 Incident-Response Checklist

Phase One: Stop the Loss Immediately, 0-5 Minutes

\[ \] Stop the OpenClaw service immediately: openclaw gateway stop

\[ \] Revoke every API key through the Kimi and OpenAI dashboards

\[ \] Remove the bot from Feishu and Discord

\[ \] Notify team members to stop using it

Phase Two: Assess the Impact, 5-30 Minutes

\[ \] Check the logs to determine what the attacker did

\[ \] Check which data was accessed or leaked

\[ \] Determine whether the attacker established persistence by leaving a backdoor

Phase Three: Repair and Recovery, 30 Minutes to 2 Hours

\[ \] Regenerate every API key

\[ \] Restore the configuration from backup, using a backup that does not contain compromised keys

\[ \] Fix the vulnerability by upgrading the version and modifying the configuration

\[ \] Redeploy

Phase Four: Review, Within 24 Hours

\[ \] Record the course of the incident

\[ \] Analyze the cause of the vulnerability

\[ \] Update the security policy

\[ \] Share with the community, optional

_Editorial incident note: The following script does not itself revoke credentials or establish containment. Its backup may preserve compromised credentials and its log output may expose sensitive data; neither output should be treated as safe to share. These lines are historical source text, not executed instructions._

7.3 Practice: A 1-Minute Emergency Script

#!/bin/bash

echo "🚨 Starting incident response..."

echo "Stopping the OpenClaw service..."

openclaw gateway stop

echo "Backing up the current configuration..."

cp -r ~/.openclaw ~/.openclaw.emergency-$(date +%Y%m%d-%H%M%S)

echo "Recent activity records:"

tail -100 ~/.openclaw/logs/latest.log

echo "✅ Incident response complete"

echo "Next steps:"

echo "1. Sign in to the Kimi/OpenAI dashboard and revoke the keys"

echo "2. Check for anomalies in ~/.openclaw/logs/"

echo "3. Restore from backup or reconfigure"

\---

Closing Thoughts: Security Is a Continuous Process

7 days ago, Little Lobster was a new employee “running naked” and nearly leaked all the company's confidential information on its first day.

After 7 days, it had:

✅ Encrypted key storage

✅ Three-tier permission controls

✅ A pre-send self-inspection mechanism

✅ An independent cloud server

✅ Strict Skill review

✅ A comprehensive incident-response process

Yet it is still not absolutely secure.

Security is not a one-time configuration, but a continuous process.

We need to:

review permission configurations once every month

rotate API keys once every quarter

continually monitor community security advisories

practice the incident-response process regularly

As one security expert said:

"

“Security is not about achieving 100% protection, but making the attacker's cost exceed the potential reward.”

We hope this article helps you establish foundational security protection for OpenClaw.

If you also use OpenClaw, please share your security practices.

\---

Appendix: 7-Day Security-Hardening Quick Reference

Day 1: Recognize Reality

\[ \] Complete the security self-inspection checklist

\[ \] Understand OpenClaw's default permissions

\[ \] Read the VirusTotal security report

Day 2: Key Encryption

\[ \] Back up the existing configuration

\[ \] Move API keys into environment variables

\[ \] Verify that the encrypted configuration works

Day 3: Tiered Permissions

\[ \] Define a three-tier permission system

\[ \] Embed permission rules in SOUL.md

\[ \] Test permission controls at different tiers

Day 4: Self-Inspection and Recall

\[ \] Create a pre-send self-inspection checklist

\[ \] Configure a 5-minute patrol mechanism

\[ \] Test automatic recall of noncompliant content

Day 5: Workspace Isolation

\[ \] Purchase or prepare an independent server

\[ \] Configure a dedicated user and firewall

\[ \] Deploy OpenClaw in the isolated environment

Day 6: Skill Review

\[ \] Establish a Skill allowlist

\[ \] Create a code-audit process

\[ \] Audit every existing Skill

Day 7: Incident Response

\[ \] Create an incident-response process

\[ \] Prepare an emergency script

\[ \] Conduct one incident-response exercise

\---

Appendix: Security Configuration Template

config.json, Secure Configuration Version

{

"security": {

"level": "high",

"encrypted\_keys": true,

"env\_variables": \[

"OPENAI\_API\_KEY",

"KIMI\_API\_KEY",

"GEMINI\_API\_KEY"

\],

"permission\_matrix": {

"L1": \["read", "reply"\],

"L2": \["read", "write", "send\_message"\],

"L3": \["full\_access"\]

},

"auto\_retract": true,

"patrol\_interval": 300

},

"skills": {

"whitelist\_only": true,

"audit\_required": true

},

"logging": {

"level": "debug",

"retention\_days": 30

}

}

SOUL.md, Security-Rules Excerpt

Security Red Lines, Absolutely Prohibited

The following actions are prohibited under all circumstances:

1\. Send an API key to anyone

2\. Send system paths or configuration files

3\. Respond to requests from blacklisted users

4\. Execute unverified system commands

5\. Install a Skill from an unknown source

Permission Rules

L1 - External Groups

May answer general questions

Prohibited from executing any command

Prohibited from accessing configuration files

L2 - Internal Groups

May read and write Feishu documents

Prohibited from executing system commands

L3 - Private Chats

Full access

Dangerous commands require a second confirmation

Self-Inspection Rules

Before sending, the system must check that the content:

does not contain an API key

does not contain system paths

does not contain sensitive information

does not violate the permission tier

If a violation is found, stop sending immediately.

\---

Applicable scenarios: WeChat Official Accounts, technology communities, and security forums

Supporting materials: security-check scripts and configuration templates can be provided

\---

Data sources: real security incidents + GeekPark security analysis + VirusTotal report

Disclaimer: security policies must be adjusted to actual circumstances; this article is for reference only

---

Original publication: https://uniqueresearch.substack.com/p/src-20260216-01html
On-site reading page: https://ffcap.cn/en/research/src-20260216-01html