-
Notifications
You must be signed in to change notification settings - Fork 23
Description
Context
KiloClaw currently only supports secrets that are predefined in the Secret Catalog (packages/secret-catalog/src/catalog.ts). Users cannot add arbitrary secrets like custom API keys for MCP servers or third-party tools. The SecretsPatchSchema validates that all keys must be in ALL_SECRET_FIELD_KEYS, rejecting anything not in the catalog.
The goal is to let users specify arbitrary secret key-value pairs that get encrypted, stored, and injected as environment variables into their container — using the same security pipeline as catalog secrets.
Approach: Open-Ended Env Var Injection
Users add arbitrary KEY=VALUE secrets that get injected as encrypted env vars. To wire a secret into an OpenClaw config path, users reference it via SecretRef syntax in their openclaw.json:
{ "source": "env", "provider": "default", "id": "MY_API_KEY" }
This works for any of OpenClaw's 45 supported credential paths (e.g., models.providers.*.apiKey, tools.web.search.apiKey, channel tokens, etc.). It also works for non-SecretRef use cases like MCP server env vars and custom tool integrations.
We do NOT restrict users to only OpenClaw's supported credential paths. Env vars are useful beyond SecretRef — MCP servers, custom tools, and scripts all read env vars directly. The UI will include inline help explaining SecretRef syntax and linking to the OpenClaw docs so users know how to connect their secrets to config paths.
OpenClaw's unsupported credentials (9 paths like channels.matrix.accessToken, hooks.token, OAuth tokens) are not our concern — those are rotating/session tokens that don't fit SecretRef's read-only model. Users can still set env vars for those if they want; OpenClaw just won't resolve them as SecretRefs.