Problem

Currently, API keys and tokens are stored directly in openclaw.json config files. This has several issues:

• Security risk: Secrets in plaintext config files
• Version control: Can't safely commit configs to git
• Rotation difficulty: Changing secrets requires config edits and restarts
• Compliance: Many enterprises require centralized secrets management
• Audit trails: No visibility into who accessed what secrets

Proposed Solution

Add native support for external secrets management systems:

Supported Providers

1. AWS Secrets Manager
2. HashiCorp Vault
3. Azure Key Vault
4. Google Cloud Secret Manager
5. Environment variables (existing, but formalize)

Config Syntax

{
  "channels": {
    "slack": {
      "botToken": "${aws:openclaw/slack/bot-token}",
      "appToken": "${vault:secret/openclaw/slack/app-token}"
    }
  },
  "tools": {
    "web": {
      "search": {
        "apiKey": "${env:BRAVE_API_KEY}"
      }
    }
  }
}

Features

• Lazy loading: Fetch secrets only when needed
• Caching: Cache with TTL, refresh periodically
• Fallback: If provider unavailable, fail gracefully with clear error
• Audit logging: Log secret access (not values, just which secrets)

Use Cases

• Enterprise deployments: Compliance with security policies
• CI/CD: Inject secrets at deploy time without storing in repos
• Secret rotation: Automatic pickup of rotated credentials
• Multi-environment: Different secrets per environment (dev/staging/prod)

Implementation Ideas

• Provider plugins (similar to channel plugins)
• String interpolation in config loader
• AWS IAM role support (no credentials needed on EC2)
• Vault token via env var or file

Impact

High — Essential for enterprise adoption, security best practices, and compliance requirements.

Note: Currently secrets like API keys must be redacted from public issues/PRs (security rule), this would eliminate that risk entirely.