OpenClaw Credential & API Key Management

1. Why Credential Management Matters

A compromised or leaked API key can lead to:

• Unbounded API costs - Attackers or buggy skills can burn through your Anthropic or OpenAI budget.
• Abuse of your agent - Stolen channel or gateway credentials can be used to send messages or run commands as your instance.
• Data exposure - Keys that grant access to cloud services (e.g. Gmail, calendar) can be used to exfiltrate data.

Security research (e.g. Snyk and The Register) has highlighted that a notable portion of ClawHub skills can leak credentials. Storing secrets outside config files and restricting what skills can access limits the blast radius. Combine credential hygiene with network isolation, skills auditing, and monitoring for defense in depth.

2. Environment Variables (Recommended)

OpenClaw and its channel adapters typically read API keys and tokens from environment variables. This keeps secrets out of config files that might be committed to version control or copied into backups.

2.1 Common Variables

Typical names (check the official documentation for your version):

• LLM providers: ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY (or GEMINI_API_KEY), DEEPSEEK_API_KEY
• Channels: TELEGRAM_BOT_TOKEN, DISCORD_BOT_TOKEN, SLACK_BOT_TOKEN, WHATSAPP_ACCESS_TOKEN, TEAMS_APP_ID, TEAMS_APP_SECRET

In your config file, reference the variable (e.g. ${ANTHROPIC_API_KEY} or the syntax your version supports) so the key never appears in the config itself.

2.2 Using a .env File

For local or Docker deployments, a .env file in the project or working directory is a common pattern:

# .env - never commit this file; add to .gitignore
ANTHROPIC_API_KEY=sk-ant-...
OPENAI_API_KEY=sk-...
TELEGRAM_BOT_TOKEN=123456:ABC-...
DISCORD_BOT_TOKEN=...

• Add .env to .gitignore so it is never committed.
• If you must keep a local file with secrets, restrict permissions (see Section 3).
• With Docker, pass .env via env_file: in docker-compose.yml or inject variables at runtime; do not bake secrets into images. See Docker Deployment and Docker Hardening.

3. File Permissions for Local Secret Files

If you store secrets in a file (e.g. a key file or a local .env), restrict access so only the process that runs OpenClaw can read it:

chmod 600 /path/to/.env
# Or for a key file:
chmod 600 /path/to/api-keys.txt

600 means read/write for the owner only; no access for group or others. Avoid storing secrets in world-readable locations (e.g. /tmp or shared directories) or in config files that get committed to git. For full guidance on what not to commit, see Security Checklist and Configuration File Structure.

4. Secrets Manager Integration

For production or enterprise deployments, use a dedicated secrets manager instead of (or in addition to) environment variables:

• HashiCorp Vault - Fetch secrets at startup and inject into the process environment or config.
• Cloud KMS / Secret Manager - AWS Secrets Manager, Google Secret Manager, Azure Key Vault: retrieve secrets at runtime and set env vars before starting the gateway.
• CI/CD secrets - GitHub Actions, GitLab CI, etc.: pass secrets as env vars into the job that runs or deploys OpenClaw; never log them.

Pattern: the host or orchestrator fetches secrets from the manager and sets environment variables (or writes a short-lived file with strict permissions) before launching OpenClaw. The OpenClaw process itself does not need direct access to the secrets manager; it just reads from the environment. This keeps key material out of config files and reduces exposure if the app is compromised.

5. API Spending Limits

Set usage or spending limits on your LLM and other API keys so that a leak or buggy skill cannot run up unbounded costs:

• Anthropic - In the Anthropic console, set usage limits or budget alerts.
• OpenAI - In the OpenAI dashboard, configure usage limits and billing alerts.
• Google / DeepSeek / others - Use the provider’s billing or quota settings to cap spend or requests.

Combine limits with monitoring and logging so you can spot unusual usage quickly. For cost planning, see our Cost Calculator and Model Provider Setup.

6. Key Rotation Schedule

Rotate API keys and tokens periodically and immediately if you suspect exposure:

• LLM keys - Create a new key in the provider console, update your env or secrets manager, restart OpenClaw, then revoke the old key.
• Channel tokens - Telegram (BotFather), Discord (Developer Portal), Slack (Reinstall app), WhatsApp (Meta Developer Portal), etc.: generate a new token, update config/env, restart, then revoke the old one.

A practical schedule: at least quarterly for high-value keys, or monthly in regulated or high-risk environments. After any incident or if a key appears in logs, repos, or third-party skills, rotate immediately. Document the rotation steps for each provider so your team can do it without delay. See Security Best Practices for the full maintenance schedule.

7. Skills and Credential Exposure

Third-party skills from the ClawHub marketplace can request or misuse credentials. Research (e.g. Snyk) has found some skills with credential leak risks. To reduce risk:

• Audit skills before installing; run openclaw security audit if available.
• Pin skill versions to avoid surprise updates that might introduce malicious code.
• Prefer storing credentials in environment variables so skills only get access when you explicitly pass them; avoid putting secrets in config that skills can read.

Full guidance: Skills Security and Known Vulnerabilities.

8. Common Mistakes to Avoid

9. Quick Reference Checklist

• ☐ All API keys and channel tokens stored in environment variables or a secrets manager (not in config in plain text).
• ☐ Any local secret file has permissions 600 (or stricter).
• ☐ .env and secret files are in .gitignore and never committed.
• ☐ Spending or usage limits set on LLM and other API keys.
• ☐ Key rotation process documented and performed on a schedule (and after any suspected exposure).
• ☐ Skills from ClawHub audited; credentials not exposed to untrusted skills unnecessarily.

For a full pre- and post-deployment list, use the Security Checklist.

Related Resources