Locker Vault — Secrets Management for OpenClaw Agents

Why This Skill Exists

Agents that handle credentials face three risks: leaking secrets in logs/files, making redundant API calls that slow down processing, and losing access when credentials rotate. This skill eliminates all three by establishing a single pattern: every credential lives in Locker's vault, is accessed through a cached client, and is referenced by ID — never by value.

The cache layer is particularly important. Without it, every time an agent needs a credential during a conversation (which can happen dozens of times in a single session), it would make a round-trip CLI call to Locker. The cache holds decrypted values in-memory for a configurable TTL, dramatically reducing latency and API load while still respecting rotation schedules.

Core Principles

These aren't arbitrary rules — they protect the business and the customer:

1. Vault is the single source of truth. Credentials are created, read, updated, and deleted exclusively through Locker. No .env files, no hardcoded values, no environment variables with raw secrets.

2. References, not values. When an agent creates a config file, cron job, script, or integration, it stores vault://SECRET_KEY_NAME (the vault reference) — never the actual token/password. At runtime, the vault-client resolves the reference.

3. Cache before call. The vault-client maintains an in-memory cache with configurable TTL. Repeated reads for the same secret within the TTL window return instantly from cache — no CLI subprocess, no network call, no latency.