OpenClaw Self-Audit: The Prompt That Checks Your Own Security Setup

Most people set up OpenClaw, lock things down as best they can, and never check again. Meanwhile, configs drift, updates change settings, and new integrations introduce gaps.

There's a better way: ask your bot to audit itself.

This works because OpenClaw has access to its own configuration. It can read openclaw.json, check running processes, inspect file permissions, verify firewall status, and report back. You send one prompt, you get a structured security report with a score. Fix what's flagged, run it again.

Here's the complete OpenClaw self-audit prompt and how to interpret the results.

---

Why Self-Auditing Works

The agent has access to:

• Its own config file (openclaw.json)
• The running process environment (what user is it running as?)
• System state (is UFW active? Is Fail2ban running?)
• File permissions on its own config files
• Docker configuration (is sandboxing enabled?)
• Environment variables (are there hardcoded keys in config?)

This makes your agent capable of doing a genuine security scan of its own setup — not a superficial one, but an actual read of the system state that matters.

An ex-Cisco security engineer who wrote one of the primary OpenClaw security guides built this 12-point check into the official hardening process. It's step 8 of 13.

---

The Full 12-Point Audit Prompt

Copy and paste this directly to your OpenClaw bot:

Audit your own security setup. Check:
1. Are you running as root? (you shouldn't be)
2. What port is the gateway on? (shouldn't be 8080, should be a custom port)
3. Is the gateway bound to "loopback"? (good) or "0.0.0.0"? (bad)
4. Is Tailscale configured with "mode": "serve" and "allowTailscale": true?
5. Is there an allowFrom list in the config? (there should be)
6. Are DM and group policies set correctly? (dmPolicy: pairing, groupPolicy: disabled)
7. Is UFW enabled? What ports are open?
8. Is Fail2ban running?
9. What are the file permissions on openclaw.json? (should be 600)
10. Are there any API keys hardcoded in config files? (they should be in .env)
11. Is Docker sandboxing configured for subagents?
12. Are sandbox capabilities dropped with "capDrop": ["ALL"]?

Give me a security score out of 10 and tell me what to fix.

Your agent will run through each check, report the result, and give you a score. Fix what's flagged, then run it again.

---

What Each Check Is Looking For

1. Running as root

Good: Process runs as openclaw or any non-root user
Bad: Process runs as root
Why it matters: Root compromise = total server compromise. The attacker can do anything.

2. Gateway port

Good: Any port from 10000–65535 that's not 8080
Bad: Port 8080 (the default)
Why it matters: Automated scanners target default ports. An unlisted port blocks 99% of automated attacks.

3. Gateway bind

Good: "bind": "loopback" — only listens on localhost
Bad: "bind": "0.0.0.0" — listens on all interfaces, publicly reachable
Why it matters: If bound to all interfaces, anyone who finds your port can reach the gateway directly.

4. Tailscale configuration

Good: "mode": "serve" and "allowTailscale": true in gateway config
Bad: No Tailscale config, or Tailscale installed but not serving through it
Why it matters: Tailscale is the single most impactful security measure — it makes your server invisible to the public internet.

5. Allowlist (allowFrom)

Good: "allowFrom": ["tg:YOUR_USER_ID"] populated with your actual ID
Bad: No allowFrom, or allowFrom is empty
Why it matters: Without an allowlist, any Telegram user who finds your bot can send it commands.

6. DM and group policies

Good: "dmPolicy": "pairing", "groupPolicy": "disabled"
Bad: Default policies, or groupPolicy not set to disabled
Why it matters: Group chat access means everyone in the group can control your agent.

7. UFW status

Good: UFW active, deny (incoming) as default, only SSH open
Bad: UFW inactive, or default incoming set to allow
Why it matters: Open ports are attack surfaces. Deny-by-default means everything is closed unless explicitly opened.

8. Fail2ban

Good: Fail2ban service is active and running
Bad: Fail2ban not installed, or service is stopped
Why it matters: Fail2ban auto-bans IPs after 3 failed SSH attempts. Disables brute-force attacks automatically.

9. openclaw.json permissions

Good: -rw------- (600) — owner read/write only
Bad: Anything more permissive (644, 664, 777)
Why it matters: If the config is world-readable, any user on the system can read your gateway password and key references.

10. Hardcoded API keys

Good: Keys are in .env file, config uses environment variable references
Bad: Keys are directly in openclaw.json or SOUL.md
Why it matters: Hardcoded keys can be read by anyone who accesses the config, including subagents and logged output.

11. Docker sandboxing

Good: Sandbox mode configured in agents.defaults
Bad: No sandbox config, or sandbox mode is off
Why it matters: Without Docker sandboxing, a prompt-injected subagent has access to your host files and secrets.

12. capDrop ALL

Good: "capDrop": ["ALL"] in Docker config
Bad: capDrop missing, or only some capabilities dropped
Why it matters: capDrop ALL removes all Linux capabilities from the container. A subagent can't escalate privileges, can't modify the network stack, can't access hardware. It's a sealed box.

---

Interpreting the Score

9–10/10: Solid setup. Address any flagged items but you're in good shape.

7–8/10: A few gaps. The flagged items represent real risk — prioritize them.

5–6/10: Multiple gaps. The audit found things that could result in actual compromise. Fix these before adding new integrations.

Below 5/10: Basic security isn't in place. Don't add any external integrations until this improves. Work through Johann's 13-step guide systematically.

The score is a snapshot, not a grade. What matters is closing the gaps.

---

Running the Audit as a Monthly Habit

Most users run the self-audit once during initial setup and then forget about it. The more useful pattern: run it monthly, especially after:

• Adding a new integration or skill
• Updating OpenClaw to a new version
• Changing any aspect of your server configuration
• Granting new permissions to the agent

Security setups don't stay in the state you left them. Monthly audits catch drift before it becomes a problem.

---

Automating the Audit in the Daily Cron

The self-audit prompt can be embedded in your daily security cron for ongoing monitoring:

Set up a monthly cron job on the first of each month that runs the full 12-point security self-audit and messages me the results with the score.

Or fold a lightweight version into the daily audit:

Include in the daily 9am audit: check if root is running, verify gateway port isn't 8080, and confirm Fail2ban is active. Flag anything that fails.

The full 12-point audit is thorough enough for monthly runs. The daily cron can handle the quick checks that matter most.

[→ See also: How to Set Up a Daily Security Audit Cron Job in OpenClaw] [→ See also: The 13-Step OpenClaw Security Checklist Every User Needs in 2026]

---

Key Takeaways

• OpenClaw can audit its own security setup because it has access to its own config, running processes, system state, and file permissions.
• The 12-point self-audit checks everything that matters: root status, port, bind address, Tailscale, allowlist, group policy, UFW, Fail2ban, file permissions, hardcoded keys, Docker sandboxing, and capDrop.
• Score interpretation: 9–10 is solid; 5–6 needs immediate attention; below 5 means don't add new integrations until it improves.
• Run the full audit monthly, and after any significant configuration change or update.
• Automate the quick checks in the daily cron, and the full 12-point audit on a monthly schedule.
• Fix what's flagged, then run the audit again. The goal is a clean report, not just a completed prompt.