I've seen a few threads here asking about secrets management for agent systems. Most of the advice is "use environment variables" or "put it in a config file," which is fine until you're dealing with dynamic credentials, short-lived tokens, or multi-tenant deployments. Hard-coded secrets are a static liability.

I just finished integrating OpenClaw with HashiCorp Vault for a production deployment. The goal was to have agents retrieve their own short-lived API keys at runtime, with automatic renewal and revocation. No secrets on disk, no long-lived credentials in memory.

Here’s the step-by-step approach that actually works, focusing on the actual attack surface at each stage:

* **Threat Model First:** We assumed the Vault server itself was trusted, but the network between the agent and Vault was not (hence TLS). The agent's host was considered potentially compromised, so we needed to limit the blast radius of any stolen credential.
* **Authentication:** We used the Kubernetes auth method for agents running in our K8s cluster. Each pod gets a JWT from its service account, which it presents to Vault. Vault maps that JWT to a role and policies.
* Alternative: AppRole is viable for non-K8s, but you have to secure the RoleID and SecretID bootstrap phase carefully.
* **Agent Policy:** The Vault policy granted to the agent was ruthlessly minimal: `path "secret/data/agents/*" { capabilities = ["read"] }` and `path "secret/creds/agent-role" { capabilities = ["read"] }`. No create, update, delete, list.
* **The Integration Pattern:** The agent's initialization sequence does not start its main loop until it:
1. Contacts Vault (using the K8s JWT or AppRole) to get a token.
2. Uses that token to fetch its operational secrets (e.g., an API key for a third-party service) from a pre-defined path.
3. Starts a background thread that renews the Vault token (if using a renewable token) and re-fetches the operational secret before it expires.
* **Critical Detail:** The secret engine was `kv-v2` for static configs, but for dynamic secrets (like database credentials), we used the appropriate secrets engine (e.g., database). The agent never sees the root credential; it gets a leased, short-lived set.

The main wins:
* Credential rotation is handled by Vault's lease system.
* A compromised token gives access to one agent's secrets, not the entire `secret/` tree.
* Revocation is central and immediate in Vault.

The main pain points:
* You now have a Vault dependency for agent startup. Your initialization logic and error handling needs to be robust.
* Monitoring Vault token TTLs and lease durations is critical. An agent with expired credentials is a broken agent.

What are others using? I see a lot of chatter about AWS Secrets Manager or Azure Key Vault—same principles apply, but I'm curious about the specific failure modes people have encountered with those.