I've been deploying several OpenClaw agents across a few Kubernetes namespaces for different projects (some MLOps pipelines, some general orchestration). The agents currently authenticate to external services using API keys stored as Kubernetes Secrets. This static approach is becoming a management burden and a security concern as we scale.

My goal is to implement an automated secrets rotation policy. I've reviewed the documentation on agent identity and the brief mention of external secret managers, but I'm seeking practical implementation patterns from the community. Specifically:

* What is the recommended pattern for injecting rotated secrets into a running agent without causing downtime or failed operations? Should the agent have a sidecar that watches for secret updates, or is there a built-in mechanism to reload credentials?
* Has anyone successfully integrated OpenClaw with a secrets backend like HashiCorp Vault, AWS Secrets Manager, or even the Kubernetes External Secrets operator? I'm particularly interested in the authentication bootstrap problem—how does the agent initially get the credentials to talk to the vault?
* Are there any observable metrics or health checks in Prometheus that can reliably indicate an agent is running with stale or failing credentials, so a rotation can be triggered or alerted on?

For context, here's a simplified version of my current agent deployment spec showing the static secret mounting:

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: openclaw-orchestrator
spec:
template:
spec:
containers:
- name: agent
image: openclaw/agent:latest
env:
- name: API_KEY
valueFrom:
secretKeyRef:
name: service-api-key
key: token
```

I am testing a proof-of-concept using a Vault sidecar and the Vault Agent injector, but the orchestration of the actual rotation timeline and agent response feels brittle. I'm curious about lessons learned from others running in production.