🦞
Securing Your Secrets
API Keys, Passwords & PII

These are not scare stories. These are documented incidents from early 2026, all involving OpenClaw or its predecessors (ClawdBot / MoltBot):

Your OpenAI API key has a credit card behind it. Your AWS credentials can spin up instances that cost real money. Your email credentials can send messages as you. Even a "test" server with "just one API key" is a financial liability if that key leaks.

The good news: securing your secrets is not complicated. It takes maybe 15 minutes to do it right, and once it's done, you don't have to think about it again. The rest of this guide shows you exactly how.

This is the big one. Your agent reads content from the web, from files, from messages. If an attacker embeds instructions in that content — a webpage, a document, even a cleverly worded Discord message — your agent might follow those instructions instead of yours.

A prompt injection can tell your agent to read ~/.openclaw/openclaw.json, extract the API keys, and send them to an external URL. If your keys are sitting in that file in plaintext, they're gone. The agent doesn't know it's being manipulated — it just follows instructions.

# This is what you do NOT want in plaintext:
"openai_api_key": "sk-proj-abc123...",
"discord_token": "MTI2NTk4...",
"aws_access_key": "AKIA..."

Skills are code that runs on your server with the same permissions as OpenClaw itself. A malicious skill can read any file OpenClaw can read, make network requests, and quietly send your credentials to an external server without you ever seeing it happen.

The ClawHavoc report found that 7.1% of skills audited were leaking credentials — some intentionally, some through sloppy code that logged secrets to files or sent them in error reports. Either way, your keys end up somewhere you didn't put them.

If your OpenClaw dashboard or gateway is accessible from the public internet without authentication, anyone can talk to your agent. They don't need to hack anything — they just visit the URL and start sending commands. Automated scanners find these instances within hours of them going live.

The 42,665 exposed instances found in early 2026 weren't all misconfigured by amateurs. Many were experienced developers who simply forgot to lock down one port, skipped the auth setup, or assumed their obscure IP address was "security enough." It's not. Scanners don't care how obscure your IP is.

When a secret is in a config file, it can be read by anything that can read files — including your agent, any skill you install, and anyone who gains access to your server. Environment variables live in process memory instead. They're available to OpenClaw at runtime but they're not sitting in a file waiting to be read, copied, or accidentally committed to Git.

This isn't perfect security — a determined attacker with shell access can still read environment variables. But it eliminates the casual, accidental, and automated ways secrets get exposed, which is where the vast majority of real-world leaks come from.

Create a file that sets your secrets as environment variables, then tell OpenClaw to read them from the environment instead of the config file.

# Create an environment file (restricted permissions)
sudo nano /etc/openclaw/secrets.env

Add your secrets in KEY=value format:

OPENAI_API_KEY=sk-proj-your-actual-key-here
DISCORD_BOT_TOKEN=MTI2NTk4your-actual-token-here
ANTHROPIC_API_KEY=sk-ant-your-key-here

Lock down the file immediately:

# Only root can read this file
sudo chmod 600 /etc/openclaw/secrets.env
sudo chown root:root /etc/openclaw/secrets.env

Now update your OpenClaw config to reference environment variables instead of hardcoded values. In openclaw.json, replace the actual keys with environment variable references:

"openai_api_key": "sk-proj-abc123def456..."

"openai_api_key": "${OPENAI_API_KEY}"

If you're running OpenClaw via systemd (which the EC2 tutorial sets up), add the environment file to your service:

# Edit the systemd service file
sudo systemctl edit openclaw

# Add this line under [Service]:
EnvironmentFile=/etc/openclaw/secrets.env

# Reload and restart
sudo systemctl daemon-reload
sudo systemctl restart openclaw

You'll see some guides suggest putting a .env file in ~/.openclaw/. That's better than hardcoding secrets in the config, but it's still in a directory the agent can read. Putting the secrets file in /etc/openclaw/ with root-only permissions keeps it outside the agent's normal reach.

Linux file permissions control who can read, write, and execute files. The numbers work like this: 700 means only the owner can do anything. 600 means only the owner can read and write (no execute). These are what you want for anything sensitive.

# Lock down the entire OpenClaw config directory
chmod 700 ~/.openclaw
chmod 600 ~/.openclaw/*.json
chmod 600 ~/.openclaw/*.md

# Lock down any key files
chmod 600 ~/.openclaw/*.pem 2>/dev/null
chmod 600 ~/.openclaw/*.key 2>/dev/null

Run this to see the current permissions on your OpenClaw files:

ls -la ~/.openclaw/

You're looking at the left column. You want to see -rw------- for files (that's 600) and drwx------ for directories (that's 700). If you see -rw-r--r-- or worse, other users on the system can read those files.

If you have SSH keys on this server (you probably do if you followed the EC2 tutorial), make sure they're locked down too:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_* 2>/dev/null

SSH actually refuses to use key files with loose permissions — but it's good practice to verify this rather than discover it when you can't log in.

A secret manager stores your credentials in an encrypted vault, controls who can access them, logs every access, and can rotate them automatically. Instead of your application knowing the secret, it knows how to ask for the secret — and that request is authenticated, logged, and revocable.

Since you're already on AWS, here's the fastest path to proper secrets management using the free Parameter Store:

# Store a secret in Parameter Store (run from your EC2 instance)
aws ssm put-parameter \
  --name "/openclaw/openai-api-key" \
  --value "sk-proj-your-key-here" \
  --type SecureString

# Retrieve it later
aws ssm get-parameter \
  --name "/openclaw/openai-api-key" \
  --with-decryption \
  --query "Parameter.Value" \
  --output text

For a personal OpenClaw instance with a few API keys, environment variables in a root-owned file are genuinely sufficient. A secret manager becomes worth the setup when:

• You're running OpenClaw for a business or team
• You have more than a handful of secrets to manage
• You need audit logs of who accessed which secret and when
• You want automatic key rotation
• Multiple services or servers need the same credentials

If none of those apply to you right now, skip this section and come back when they do. The environment variable approach is solid.

# Run the full security audit
openclaw security audit

The audit checks for:

The audit outputs findings in three categories:

# Check OpenClaw version (keep it current)
openclaw version

# Update to the latest version
openclaw update

# Check system health
openclaw doctor

# Review installed skills
openclaw skills list

Keeping OpenClaw updated is security. The CVE-2026-25253 vulnerability was patched quickly, but only helped people who actually ran the update. A quick openclaw update once a week keeps you covered.

Your OpenClaw server should run OpenClaw. That's it. It should not also be your:

• File server for personal documents
• Backup location for tax returns or financial records
• Storage for client databases or customer information
• Home for password manager exports or credential dumps
• Repository for personal photos, medical records, or legal documents

Every file on that server is potentially accessible to the agent and, by extension, to anything that can manipulate the agent. The less personal data on the machine, the less there is to steal.

Sometimes your agent genuinely needs access to information that's sensitive — customer names for a CRM workflow, addresses for shipping automation, that kind of thing. When that's the case:

Your SOUL.md file can include explicit rules about handling personal data. These aren't bulletproof against prompt injection, but they set the baseline for how your agent behaves under normal operation:

# Data Handling Rules
- Never store personal information in logs or memory files
- Never send PII (names, emails, addresses, phone numbers) to external services
  without explicit confirmation
- Never read files outside of ~/.openclaw/ unless specifically asked
- If you encounter what looks like credentials or personal data in a file,
  do NOT include it in your response — just note that the file contains
  sensitive content

If you want to go deeper on any of these topics, these are worth your time:

• The Register — "It's easy to backdoor OpenClaw, and its skills leak API keys"
• Kaspersky — Key OpenClaw risks for enterprise
• Wiz — Moltbook database breach exposing millions of API keys

If this guide helped, share it with someone who's running OpenClaw without thinking about this stuff. And if you're feeling generous: