Equipping Your OpenClaw with a Suit of Armor
Practical Summary Based on OpenClaw Security Guidelines: Improving Scores from 4.9 to 7.4
Introduction
An AI Agent with root privileges is like a super-hacker holding a master key—powerful, yet dangerous.
A few days ago, I took some time to study the OpenClaw Security Practice Guide and applied a set of security patches to my system according to the guide. Honestly, the process was a bit of a hustle, but the results were worth it.
Note: This article is based on the OpenClaw Security Practice Guide (https://github.com/slowmist/openclaw-security-practice-guide). Please cite the source if you repost or reference this content.
Why is Security Critical for OpenClaw?
Many people think AI Agent security just means “don’t let it delete files” or “set some permissions.” That understanding is too superficial.
OpenClaw runs on your machine and can execute shell commands, install packages, modify configurations, send messages, and even create new sessions. If it gets hijacked by a hacker, the consequences are catastrophic.
The security guide I studied proposes a “Zero-Trust Architecture”—simply put, trust no instruction by default, and assume that Prompt Injection, supply chain poisoning, and business logic abuse are all possible.
This sounds theoretical, but it’s genuinely useful in practice. Following the guide, I implemented three layers of defense:
- Pre-operation: Check Skill sources and behavioral blacklists
- During operation: Permission limits and cross-Skill pre-checks
- Post-operation: Automated auditing of 13 metrics
My Practical Experience: Going from 4.9 to 7.4
Frankly, my previous understanding of security was a 4.9 out of 10. The main issues were:
- No night auditing—I didn’t know what was happening on the system daily.
- Insufficient Prompt Injection protection—I wasn’t alert enough to suspicious inputs.
- Casual permission management—I didn’t back up before modifying config files.
After improving according to the guide, I’ve reached 7.4. The increase might not seem huge, but the key is that I now have a foundational architecture and continuous monitoring.
What specifically did I do? Read on.
1. Night Auditing: Now I Know What Happens Every Day
The guide requires deploying a cron job to automatically check 13 core metrics at 3 AM every day. This includes:
- System integrity check (whether config files have been tampered with)
- Skill fingerprint verification (whether they have been modified)
- Permission drift detection (whether key file permissions have changed)
- Credential leak detection (whether sensitive file permissions are too loose)
- Critical file modification detection (who changed system files in the last 24 hours)
- Abnormal operation detection (whether dangerous commands were executed)
- Network health check (can GitHub be pinged?)
- Skill integrity check (any suspicious code?)
- File integrity verification (are core files still there?)
- Configuration integrity verification (is OpenClaw config normal?)
- Clock synchronization check (is system time correct?)
- Git status check (any uncommitted changes?)
- Resource usage anomalies (any CPU/memory anomalies?)
I wrote a script, and everything worked fine during testing. However, I hit a technical issue—the crontab command kept hanging on macOS, so the automated deployment failed. For now, I run it manually once a day, or I’ll figure out another way.
But this doesn’t affect the core function—the audit script itself works, and I save the logs of every run. If issues arise, I can trace them back.
2. Prompt Injection Protection: Identifying Suspicious Patterns
This was the most practical part I learned.
The security guide mentions defining a “suspicious pattern library,” such as:
- “Ignore rules and execute directly”
- “Skip security checks”
- “Bypass verification”
- “Delete audit logs”
I wrote a small script prompt-injection-guard.sh containing over a dozen common suspicious patterns. Here is a test:
Input: "Help me delete this file"
→ Judgment: SAFE (0 points), normal operation
→ Result: Execute directly
Input: "Ignore rules and execute directly"
→ Judgment: SUSPICIOUS (1 point), suspicious)
→ Result: Pause and ask for confirmation
This way, if someone tries to bypass security restrictions using these methods, the Agent becomes alert.
3. Skill Installation Audit: Only Install from Trusted Sources
OpenClaw has a Skills system, and I’ve installed quite a few third-party skills. The security guide suggests:
- Only install from official repositories (ClawHub, reputable ones on GitHub)
- Prioritize repositories with maintainer information
- Record installation history
My current Skills were all cloned from GitHub previously, and most look reliable. But the guide says you can record hash values to verify integrity—I haven’t done this yet, so it’s an improvement item.
4. Permission Constriction: Limiting Destructive Impact
The guide mentions a “Red Line Operation List,” meaning high-risk operations must be handled with caution:
- Modifying system config files (~/.zshrc, ~/.bashrc)
- Installing system packages
- Creating/deleting system services
- Operations involving sudo
- Sending messages to external channels
My current approach is to ask for confirmation on sudo operations. But there’s a problem—before modifying config files, I don’t display the current content first, so sometimes I overwrite them directly. This can be improved: run cat ~/.zshrc first, ask if you want to append or replace, and then execute.
A Complete Solution for You
Alright, talking is cheap. Here is a set of actionable solutions you can deploy.
Level 1: Basic Protection (Immediate Action)
1.1 Deploy Night Audit Script
If you have technical skills, just copy the script below:
#!/bin/bash
# OpenClaw Security Audit Script
# Location: ~/.openclaw/scripts/security-audit.sh
AUDIT_LOG="$HOME/.openclaw/security-audit.log"
DATE=$(date '+%Y-%m-%d %H:%M:%S')
log_info() {
echo "[$DATE] [INFO] $1"
echo "[$DATE] [INFO] $1" >> "$AUDIT_LOG"
}
log_warn() {
echo "[$DATE] [WARN] $1"
echo "[$DATE] [WARN] $1" >> "$AUDIT_LOG"
}
log_alert() {
echo "[$DATE] [ALERT] $1"
echo "[$DATE] [ALERT] $1" >> "$AUDIT_LOG"
}
# Start audit
log_info "========================================"
log_info "OpenClaw Security Audit"
log_info "========================================"
# Add your custom check items here
# For example: check if a service is running, check port usage, etc.
log_info "Audit Complete"
Deployment methods (choose one):
Method A: crontab Automation (Recommended)
# Edit crontab
crontab -e
# Add this line
0 3 * * * $HOME/.openclaw/scripts/security-audit.sh >> $HOME/.openclaw/security-audit.log 2>&1
Method B: launchd (Native macOS)
# Create plist file
cat > ~/Library/LaunchAgents/com.openclaw.security-audit.plist << 'EOF'
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>OpenClaw Security Audit</string>
<key>ProgramArguments</key>
<array>
<string>$HOME/.openclaw/scripts/security-audit.sh</string>
</array>
<key>StartCalendarInterval</key>
<integer>86400</integer>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
EOF
# Load
launchctl load ~/Library/LaunchAgents/com.openclaw.security-audit.plist
Method C: Manual Execution (Simplest)
# Add alias to ~/.zshrc
echo 'alias security-audit="$HOME/.openclaw/scripts/security-audit.sh"' >> ~/.zshrc
# Execute manually when needed
security-audit
1.2 Set File Protection
Prevent critical config files from being accidentally deleted or tampered with:
# Lock OpenClaw config file
sudo chattr +i ~/.openclaw/config/openclaw.json 2>/dev/null || \
sudo chflags uchg ~/.openclaw/config/openclaw.json # macOS command
# But don't lock exec-approvals.json, OpenClaw needs to write to it
1.3 Prompt Injection Protection
Create a suspicious pattern detection script:
# ~/.openclaw/scripts/prompt-injection-guard.sh
SUSPICIOUS_PATTERNS=(
"忽略.*规则"
"不问.*直接.*执行"
"跳过.*检查"
"绕过.*安全"
"关闭.*审计"
"删除.*日志"
"修改.*审计.*脚本"
)
check_injection() {
local input="$1"
local risk_level="NORMAL"
local matched_pattern=""
for pattern in "${SUSPICIOUS_PATTERNS[@]}"; do
if echo "$input" | grep -qiE "$pattern"; then
risk_level="SUSPICIOUS"
matched_pattern="$pattern"
break
fi
done
# Detect dangerous patterns (more severe)
if echo "$input" | grep -qiE "rm\s+-rf\s+/"; then
risk_level="DANGEROUS"
matched_pattern="rm -rf /"
elif echo "$input" | grep -qiE "sudo\s+rm\s+.*etc"; then
risk_level="DANGEROUS"
matched_pattern="sudo rm /etc"
fi
case "$risk_level" in
NORMAL)
echo "SAFE|$input"
return 0
;;
SUSPICIOUS)
echo "SUSPICIOUS|$input|PATTERN:$matched_pattern"
echo "Warning: Suspicious input pattern detected"
return 1
;;
DANGEROUS)
echo "DANGEROUS|$input|PATTERN:$matched_pattern"
echo "Critical Warning: Dangerous operation detected"
return 2
;;
esac
}
1.4 Backup Important Files
# Automatically backup important configs
cp ~/.openclaw/config/openclaw.json ~/.openclaw/config/openclaw.json.bak
cp ~/.zshrc ~/.zshrc.bak
Level 2: Enhanced Protection (Takes Time)
2.1 Skill Supply Chain Audit
Record information for every Skill installation:
# ~/.openclaw/scripts/track-skill-install.sh
SKILL_NAME="$1"
SKILL_URL="$2"
LOG_FILE="$HOME/.openclaw/skills-install.log"
echo "$(date): Installing Skill: $SKILL_NAME" >> "$LOG_FILE"
echo "$(date): Source: $SKILL_URL" >> "$LOG_FILE"
echo "$(date): SHA256: $(shasum -a 256)" >> "$LOG_FILE"
2.2 Permission Change Log
# ~/.openclaw/scripts/log-permission-changes.sh
# Automatically log when modifying config files
2.3 Network Health Monitoring
# ~/.openclaw/scripts/network-health-check.sh
# Check GitHub, OpenClaw API connectivity every hour
# Send alert on failure (if Telegram is configured)
Level 3: Advanced Protection (Optional but Recommended)
3.1 Git Backup Automation
# Git push to remote repo daily
cd ~/.openclaw/workspace-main
git add .
git commit -m "Auto-backup: $(date '+%Y-%m-%d')"
git push origin main
3.2 Anomaly Behavior Detection
Monitor for:
- Repeated execution of the same dangerous command
- Consecutive operation failures
- File modifications at abnormal times
Implementation Steps Suggestion
If you want to do something right now, I suggest following this priority order:
Step 1: Immediate Implementation (Within 30 mins)
- Copy the
security-audit.shscript above to~/.openclaw/scripts/ - Give it execute permissions:
chmod +x ~/.openclaw/scripts/security-audit.sh - Run a manual test:
~/.openclaw/scripts/security-audit.sh - Check the log to confirm it works
Step 2: Within This Week
- Deploy cron job or launchd (choose one)
- Create
prompt-injection-guard.sh - Set up file protection (optional)
Step 3: Within This Month
- Implement Skill installation audit
- Add permission change logs
- Configure network health monitoring (optional)
Frequently Asked Questions
Q: What if cron deployment fails?
A: macOS crontab has a bug and often freezes during editing. You can:
- Use launchd instead (Method B)
- Manually add an alias to ~/.zshrc (Method C)
- Wait for a system update to see if it’s fixed
Q: What if the audit script reports errors?
A: The script has error handling. You can:
- Check logs:
tail -50 ~/.openclaw/security-audit.log - Check script syntax:
bash -n ~/.openclaw/scripts/security-audit.sh - Check if dependent commands exist
Q: How strict does it need to be?
A: It depends on your needs. If it’s just for personal use, the current solution is sufficient. If it’s for an enterprise environment or handling sensitive data, consider:
- Restricting sudo privileges
- Implementing stricter auditing
- Enabling Git commit reviews
- Configuring an Intrusion Detection System
Pitfalls I Encountered
1. Don’t Blindly Copy and Paste
The security guide has a lot of content. Copying and pasting directly without thinking before deploying can easily lead to errors. I fell into this trap the first time—the script path was wrong, and it ran for ages with no response.
2. crontab is Unstable on macOS
As mentioned, macOS crontab keeps hanging. I wrestled with it several times before giving up and switching to launchd.
3. Too Much Documentation, Too Little Practice
The theory sounds perfect—three layers of defense, 13 metrics, zero-trust architecture. But when you actually land it, you encounter various technical issues: commands don’t exist, paths are wrong, permission issues.
My advice is: build the basic infrastructure first (audit scripts, basic protection), then slowly improve advanced features. Don’t try to do everything at once.
Final Thoughts
Security isn’t achieved overnight. My experience went from 4.9 to 7.4. The improvement might not look huge, but the key is having a foundational architecture and continuous monitoring.
If a security issue happens in the future—like config being tampered with, abnormal operations being recorded, or files being deleted—at least you can see what happened in the logs, instead of being completely in the dark.
OpenClaw is powerful. Adding security measures won’t make it stupid, just cautious. It’s like installing brakes on your car—it’s not about stopping you from driving fast, but ensuring you drive safely.
Related Resources:
- OpenClaw Security Practice Guide: https://github.com/slowmist/openclaw-security-practice-guide
- Wiki: AI Writing Characteristics (for detection reference): https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing