openclaw - 💡(How to fix) Fix Enhancement: Allow vault/exec secret references in auth.profiles apiKey [1 comments, 2 participants]

Summary

Allow vault/exec secret references (e.g. OpenBao, HashiCorp Vault) to be used as the apiKey source in auth.profiles, the same way they are already supported in tools, channels, gateway, skills, and messages.

Problem to solve

When mode: "api_key" is set in auth.profiles, openclaw hard-codes a lookup to file:filemain:/anthropic/apiKey (and equivalent for other providers). This means:

1. The config schema rejects vault reference objects in auth.profiles.<provider>.apiKey with Unrecognized key: "apiKey"
2. If filemain is not configured, startup fails: SecretProviderResolutionError: Secret provider "filemain" is not configured (ref: file:filemain:/anthropic/apiKey)

Users who have fully migrated to an exec-based vault provider (OpenBao, Vault, etc.) are forced to keep a separate plaintext JSON file just for provider API keys, even though every other secret in the system is vault-sourced. This defeats the purpose of centralized secrets management and creates a confusing inconsistency with no documentation warning.

Proposed solution

Extend the auth.profiles config schema so that apiKey accepts a secret reference object, consistent with how all other secret fields work:

"auth": {
  "profiles": {
    "anthropic:default": {
      "provider": "anthropic",
      "mode": "api_key",
      "apiKey": {
        "source": "exec",
        "provider": "openbao",
        "id": "secret/moneypenny/anthropic"
      }
    },
    "google:default": {
      "provider": "google",
      "mode": "api_key",
      "apiKey": {
        "source": "exec",
        "provider": "openbao",
        "id": "secret/moneypenny/google"
      }
    }
  }
}

The secret resolution path already exists — it just needs to be permitted in the auth profile schema. The filemain fallback should remain for backwards compatibility but should not be the only option.

Alternatives considered

No response

Impact

Affected: Any user deploying openclaw with a vault-based secrets provider (OpenBao, HashiCorp Vault) who wants to eliminate plaintext credential files — especially production and multi-agent deployments.

Severity: Blocks full vault migration — forces a plaintext fallback file regardless of vault configuration.

Frequency: Every startup, every deployment, every new agent added to the instance.

Consequence: Users must maintain a separate auth-keys.json file containing plaintext AI provider API keys. This file sits outside the vault, creating an inconsistent security posture and additional operational overhead. As more agents and AI providers are added to an openclaw instance, the number of keys that must be managed outside the vault grows.

Evidence/examples

No response

Additional information

No response