How to securely store API keys for AI agents
Never leave keys in plaintext config files or environment variables baked into an image. Store each secret in an encrypted vault scoped to its owner, inject it only at runtime, rotate it on a schedule, and grant the agent the narrowest scope it needs.
An AI agent that does real work accumulates secrets fast: an LLM provider key, OAuth tokens for Gmail and Calendar, a Telegram bot token, maybe a payment or booking integration. Each one is a credential that can spend money, read your mail or impersonate you. The default that most quick-start guides reach for, dropping everything into a .env file or a config block, is exactly the pattern that leaks.
The goal is straightforward: secrets should be encrypted at rest, available to the agent only at the moment it needs them, and easy to revoke without rebuilding anything.
How it works
A few principles cover almost every case.
- Encrypt at rest in a dedicated store. Use a secrets manager or an encrypted vault rather than a file on disk. The agent reads the secret through the store’s API; the value is never written to your repository or your container image.
- Inject at runtime, never bake in. Mount or fetch secrets when the process starts. Anything baked into an image or committed to source control is effectively published.
- Scope narrowly. Request only the OAuth scopes and API permissions the task requires. A key that can only read calendars cannot drain a budget.
- Rotate and revoke. Set an expiry, rotate on a schedule, and make sure revoking a single credential does not take the whole agent down. For Google access, OAuth tokens are revocable from your Google Account independently of the app.
If you self-host OpenClaw, this is your responsibility to wire up: a secrets backend, runtime injection, rotation. It is very doable, but it is part of the ongoing self-host maintenance and a common source of self-hosting security risk.
Worked example
How the same set of secrets is handled across approaches.
| Practice | Plaintext .env (don’t) | Self-hosted vault (DIY) | Liv user vaults (managed) |
|---|---|---|---|
| Storage | File on disk, often committed | Encrypted store you run | Encrypted per-user vault |
| Injection | Loaded into env at boot | Fetched at runtime | Fetched at runtime |
| Rotation | Manual, often forgotten | You schedule it | Handled for you |
| Blast radius if leaked | All secrets exposed | Scoped to that vault | Scoped to one user’s vault |
| Your ops burden | None, until it leaks | You own it all | None |
Common questions
Are environment variables safe enough for secrets?
They are better than committing keys to source, but env vars can leak through logs, crash dumps and child processes. A dedicated encrypted store is the stronger default.
What is a per-user vault?
An encrypted store scoped to a single user, so one person’s credentials are isolated from everyone else’s. Liv uses this model, which keeps the blast radius of any incident small.
How often should I rotate API keys?
On a schedule that matches the sensitivity: high-value keys quarterly or sooner, and immediately on any suspected exposure. Automate it so it actually happens.
What if I give an agent my Gmail credentials directly?
Don’t. Use Google OAuth instead, so no password is shared and access stays revocable.
Where do API keys leak most often?
Committed config files, build logs, screenshots and over-broad scopes. Narrow scope and runtime injection close most of those gaps.
Is a managed service automatically more secure?
No, but it can remove whole classes of mistake by handling encryption and rotation for you. Weigh that against the security risks of self-hosting.