Stop putting AI agent
API keys in .env files.
.env works for one developer and one process. It stops working the moment you have five agents, two environments, and a teammate who pasted the file into Slack by accident.
Every agent project starts with a .env file. It's the path of least resistance. Drop LOOMAL_API_KEY and OPENAI_API_KEY and STRIPE_KEY and five OAuth tokens into one file, load them at process start, get on with the actual work.
The reason every security checklist tells you not to do this is not theoretical. Environment variables leak through channels you don't notice: CI logs, container image layers, crash reports, gitignored files that weren't gitignored quite early enough, and well-meaning screen shares. The fix isn't to be more careful. The fix is to use a thing that was designed to hold secrets.
All the ways .env leaks
Pasted into Slack to help a teammate debug. Committed to git by accident and rewritten out of history but still visible in forks. Baked into a Docker layer as ENV instructions. Dumped when the process crashes and the crash reporter captures environment. Printed in a tracing span that logged the full process env. Visible in /proc/<pid>/environ to any other user on the host.
None of these are hypothetical. Each is the cause of at least one notable breach you've read about in the last two years. The common thread is that .env trusts every part of the system that can read a process's environment, which is a much larger set than you'd like.
Why 'just use a secrets manager' isn't quite enough for agents
Secrets managers (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager) solve the storage problem. They don't solve the scoping problem. An agent that can read every secret in the manager is no safer than one that reads from .env — just with extra steps.
For agents, the property you want is per-identity scoping. Each agent has its own vault that only it can read; secrets for agent A are not visible to agent B even if both run in the same process. Revoking agent A revokes its vault entries. This isn't how generic secrets managers are typically deployed; it has to be built on top.
The Loomal version
Each Loomal identity has its own AES-256 encrypted vault. The agent's API key is the only credential needed to read from it — one secret to bootstrap the identity, then secrets by label from the vault after that. No process environment variable holds anything sensitive except that one API key, which itself is scoped to an identity you can revoke in one click.
For TOTP, the secrets never return in plaintext — only the derived six-digit code does. This is a real improvement over keeping otpauth:// URIs in .env, which is unfortunately common.
FAQ
What about loading secrets from AWS Secrets Manager at process start?
Better than .env, worse than per-agent scoping. The agent has whatever permissions its IAM role grants, which is usually broader than the specific secrets it actually uses. A per-identity vault is tighter by construction.
Isn't the Loomal API key itself in .env?
Yes — one bootstrap secret is unavoidable. The difference is that a single Loomal API key revoke invalidates every credential in its vault. A leaked .env file with twelve secrets requires twelve separate rotations.
Can I use the Loomal vault for non-agent workloads?
It's optimized for agent use cases — scoped, revocable, MCP-accessible. For infrastructure secrets (database passwords, internal service tokens), existing infra-secrets managers are probably a better fit.
Related reading
More stop sharing
Last updated: 2026-04-15