--- title: "Nous Research's Hermes v0.15 Stops AI Agents From Leaking API Keys" subtitle: "Hermes Agent v0.15 adds Bitwarden Secrets Manager integration, replacing scattered plaintext API keys with a single bootstrap token and centralized rotation." url: "https://alphasignal.ai/news/nous-research-s-hermes-v0-15-stops-ai-agents-from-leaking-api-keys" author: "AlphaSignal Newsroom" author_url: "https://alphasignal.ai/editorial-team" company: "Nous Research" company_url: "https://alphasignal.ai/company/nousresearch" published: "2026-05-22T17:40:10.000Z" updated: "2026-06-16T21:05:04.429Z" type: "News" topics: - "Agents" - "Development" subtopics: - "Tool Use" - "Agent Frameworks" - "Code Agents" - "Code Agents" upvotes: 1573 read_time: "5 min" source_url: "https://hermes-agent.nousresearch.com/docs/user-guide/secrets/bitwarden" comments: 0 --- # Nous Research's Hermes v0.15 Stops AI Agents From Leaking API Keys > Hermes Agent v0.15 adds Bitwarden Secrets Manager integration, replacing scattered plaintext API keys with a single bootstrap token and centralized rotation. [Hermes Agent](https://hermes-agent.nousresearch.com/docs/user-guide/secrets/bitwarden) has a secrets problem that every developer running AI agents eventually hits: you need a dozen API keys to talk to OpenAI, Anthropic, OpenRouter, and a handful of other providers, and they all end up sitting in a plaintext `~/.hermes/.env` file. Rotate one key and you have to hunt down every machine running Hermes. Hermes v0.15 fixes this with native [Bitwarden Secrets Manager](https://bitwarden.com/products/secrets-manager/) support. ## The plaintext problem with agent workflows Until now, the biggest friction with agent workflows was authentication. The moment an agent hit a login wall or needed an API key, the loop broke, and you had to step in and hold its hand. Storing keys in a flat `.env` file works fine for a single laptop, but it breaks down fast when you are running Hermes across multiple machines, shared dev boxes, or gateway VPSes. A recent Bitwarden study found that 65% of developers hardcode secrets across development environments , and agent runtimes are no exception. The new integration is a direct answer to that pattern. ## One token to rule them all The integration pulls API keys from Bitwarden Secrets Manager at process startup instead of storing them in plaintext inside `~/.hermes/.env`. One bootstrap secret , a machine-account access token , replaces every per-provider key, and rotating a credential becomes a single change in the Bitwarden web app. The mechanics are straightforward: 1. You create a machine account in Bitwarden Secrets Manager, give it read access to a project, and generate an access token. Hermes stores that single token in `~/.hermes/.env` as `BWS_ACCESS_TOKEN`. 2. Every time Hermes (or the gateway, or a cron job) starts, after `~/.hermes/.env` has loaded, Hermes calls `bws secret list ` and sets the returned keys into `os.environ`. 3. By default Hermes overrides values already in your environment, so Bitwarden is the source of truth , rotate a key once in the web app and every Hermes process picks it up on next start. The secret names in Bitwarden map directly to environment variable names , so a secret named `ANTHROPIC_API_KEY` becomes exactly that in the environment. No mapping files, no extra config. ## Zero-friction setup The `bws` binary auto-installs lazily on first use into `~/.hermes/bin/bws` , no `apt`, no `brew`, no `sudo`. A single wizard command handles the rest: ``` hermes secrets bitwarden setup ``` The wizard downloads and verifies the `bws` binary, prompts for the access token (hidden input), asks which Bitwarden region you are using (US Cloud, EU Cloud, or self-hosted), lists the projects your machine account can see, runs a test fetch, and flips `secrets.bitwarden.enabled: true` in your config. For automated or CI-adjacent setups, the wizard also accepts flags: ``` hermes secrets bitwarden setup \ --access-token "$BWS_ACCESS_TOKEN" \ --server-url https://vault.bitwarden.eu \ --project-id ``` Bitwarden Secrets Manager is available via the `bws` CLI, lazily installed, and the free tier works. No paid plan is required to try this out. ## Key config options The integration is controlled through `~/.hermes/config.yaml`. A few knobs worth knowing: - `override_existing: true` (default) , Bitwarden wins over whatever is already in your shell environment. Set to `false` if you want local `.env` values to take precedence during development. - `cache_ttl_seconds: 300` , secrets are cached per-process for 5 minutes. Set to `0` to always fetch fresh. - `server_url` , leave empty for US Cloud, set to `https://vault.bitwarden.eu` for EU Cloud, or point at your self-hosted instance. - `auto_install: true` , the `bws` binary is downloaded automatically on first use. Flip to `false` if you want to manage the binary yourself. ## Security details that matter The `bws` binary download is verified against the published SHA-256 checksum from the same GitHub release. A mismatch aborts the install. There is also a self-referential protection built in: Hermes will refuse to let Bitwarden overwrite the bootstrap token itself, even with `override_existing: true`. If you store `BWS_ACCESS_TOKEN` as a secret inside the project, it is silently skipped during apply. The bootstrap token is itself a high-value credential , anyone with it can read every secret the machine account has access to. Treat it like any other API key, store it only in `.env` (not `config.yaml`), and revoke it from the Bitwarden web app if it ever leaks. ## When to use it (and when not to) The docs are refreshingly honest about the tradeoffs. The integration is the right call for: - Multi-machine setups where you want one rotation to propagate everywhere - Shared dev boxes or team environments - Gateway VPSes running Hermes as a persistent service - Any setup where you want centralized revocation across multiple Hermes installations It is probably overkill for a single-machine personal setup where `~/.hermes/.env` is fine. For single-machine personal setups, you are trading one credential for another and adding a network dependency at startup. And if you are in a CI/CD pipeline that already uses GitHub Actions secrets or HashiCorp Vault, the docs recommend picking one path and not two. ## Part of a bigger security push The Bitwarden integration shipped as part of [Hermes v0.15](https://github.com/NousResearch/hermes-agent/releases/tag/v2026.5.28), which the team called "The Velocity Release." The release also adds mTLS for HTTP and SSE MCP servers, which means your agent and its tool servers authenticate each other instead of trusting any caller on the network. Hermes now also defends the context window against prompt-injection attacks , called "Brainworm-class" attacks , that try to hijack the agent via tool output, recalled memory, or stored skills. More secret manager backends , Vault, AWS Secrets Manager, 1Password CLI , are easy to add behind the same interface. The lift is one module in `agent/secret_sources/` and one CLI handler. Bitwarden is first, but the architecture is clearly designed to be extended. The community reaction has been positive: users noted that Bitwarden makes it easy to manage keys, rotate them quickly, and coordinate access with a team. For anyone running Hermes across more than one machine, that is the core value proposition in a single sentence. ## Sources - [X post by @nousresearch](https://x.com/nousresearch/status/2057879204490883278) - [Bitwarden Secrets Manager | Hermes Agent Docs](https://hermes-agent.nousresearch.com/docs/user-guide/secrets/bitwarden) - [Hermes Agent v0.15.0 (v2026.5.28) — The Velocity Release](https://newreleases.io/project/github/NousResearch/hermes-agent/release/v2026.5.28) - [Secrets | Hermes Agent Docs](https://hermes-agent.nousresearch.com/docs/user-guide/secrets/) - [Nous Research on X — Hermes Agent Bitwarden announcement](https://x.com/NousResearch/status/2057879204490883278) - [Hermes Agent v0.15: What Actually Matters | TECHSY](https://techsy.io/en/blog/hermes-agent-v0-15)