Hermes agent bitwarden support means Hermes can pull your API keys from Bitwarden Secrets Manager every time it starts, so the keys stop living in plain text inside your Hermes .env file. One machine-account token replaces a pile of provider keys, and a key you change in the Bitwarden web app reaches every Hermes process on its next start.
📺 Watch: Hermes Agent V0.22 Just Changed AI Agents Forever!
🔥 Get the Agent OS as a free bonus: AI Profit Boardroom members get the full Agent OS zip, prompt libraries, daily tutorials and weekly live coaching calls. → Get inside
There is a second, separate Bitwarden feature too. Hermes can use the Bitwarden password manager to sign in to websites in its browser, without the model ever seeing the password. This page covers both, in the order you would set them up, using only commands and settings from the official Hermes Bitwarden docs.
Julian Goldie shares his own agent setups, step-by-step trainings and weekly coaching calls inside the AI Profit Boardroom. If you want to talk through your own setup first, book a free AI strategy session.
Two Bitwarden tools, two different jobs
The most common mix-up is treating these as one feature. They use different command-line tools, different credentials and different parts of Hermes.
| Question | Secrets Manager (bws) | Password manager (bw) |
|---|---|---|
| What it holds for Hermes | API keys and other env vars | Website logins |
| When Hermes uses it | At process startup | When the browser hits a sign-in page |
| Credential | A machine-account access token | Your master password, typed once per session |
| Where the credential sits | BWS_ACCESS_TOKEN in ~/.hermes/.env | Only a session token, kept in memory |
| How you turn it on | hermes secrets bitwarden setup | Install and sign in to bw; Hermes detects it |
| Works in cron and webhooks? | Yes, it runs at every start | A locked manager reports unavailable_in_this_session |
Pick the one that matches your problem. Scattered API keys point to bws. An agent that needs to sign in to a supplier portal points to bw. Plenty of setups use both.
How the startup hook works
The Hermes secrets page lists three supported sources: Bitwarden Secrets Manager, 1Password and a command helper for other vault tools. Bitwarden runs on the bws command-line tool.
The flow is short. In Bitwarden you make a machine account, give it read access to one project, and generate an access token. Hermes keeps that single token in ~/.hermes/.env as BWS_ACCESS_TOKEN.
Each time hermes, the gateway or a cron job starts, Hermes loads .env first. Then it calls bws secret list with your project id and sets every returned secret as an environment variable.
The secret's Name in the Bitwarden project becomes the variable name. Call a secret OPENROUTER_API_KEY and Hermes sees OPENROUTER_API_KEY. Hermes also labels where each key came from, so setup flows and hermes model show "(from Bitwarden)" next to it.
📺 Watch: Hermes Agent Can Now Browse the Web as YOU
Hermes agent bitwarden setup, step by step
- Make a project. In the Bitwarden web app, switch to Secrets Manager and create a project, for example "Hermes keys".
- Add your keys as secrets. Use the exact env var names Hermes expects, such as OPENROUTER_API_KEY or ANTHROPIC_API_KEY.
- Create a machine account. Give it Read access to that project, then create an access token and copy it. Bitwarden will not show the token again.
- Run the wizard. Type hermes secrets bitwarden setup. It installs bws if it is missing, asks for the token with hidden input, asks for your region (US Cloud, EU Cloud or a self-hosted URL), lets you pick the project, test-fetches the secrets and switches the integration on.
- Confirm it. Run hermes secrets bitwarden status to see the config, the bws version and whether the token is present and valid.
Setting up a server without a prompt? The wizard also takes flags on one line: hermes secrets bitwarden setup with --access-token, --server-url (for example https://vault.bitwarden.eu) and --project-id.
Halfway through and unsure which keys belong in the vault? Book a free AI strategy session and bring your list of providers.
The config keys worth knowing
Everything except the token lives in config.yaml under secrets.bitwarden. The defaults from the docs:
- enabled starts as false. When it is false, Bitwarden is never contacted.
- access_token_env is BWS_ACCESS_TOKEN. Change it only if that name is already taken.
- project_id holds the project UUID. A value that isn't UUID-shaped is rejected.
- server_url is empty, which means the US Cloud default. It must be https, and plain http is refused except for localhost.
- cache_ttl_seconds is 300, so a fetch result is reused for five minutes.
- encrypted_cache.enabled is false. Turn it on to keep the last good fetch in an encrypted file, and set max_stale_seconds if you want it used during network failures.
- override_existing is true, so Bitwarden values beat what is already in .env.
- auto_install is true, so a missing bws binary gets installed for you.
Two more knobs sit one level up, under secrets. preserve_existing keeps chosen variables from .env for a profile, even when Bitwarden would override them. Profile aliasing lets one shared project serve several profiles: a secret named TELEGRAM_BOT_TOKEN_MILLA fills TELEGRAM_BOT_TOKEN for the milla profile.
📺 Watch: NEW Hermes Agent Updates are INSANELY GOOD!
Rotation, failures and what the agent can't see
When a machine-account token expires or gets revoked, run hermes secrets bitwarden token. Hermes checks the new token against Bitwarden before it writes anything, so a rejected token leaves your .env as it was.
Bitwarden never blocks startup. If the fetch fails, Hermes prints a one-line warning plus a second line naming the command that fixes it, then carries on with the keys already in .env.
The token is also kept away from the agent. Hermes strips BWS_ACCESS_TOKEN from every process the agent spawns, including the terminal, execute_code and cron scripts. env_passthrough can't re-allow it, and Bitwarden can never overwrite the token itself.
Treat the token like any high-value key. The docs say machine accounts can't be 2FA-gated, so anyone holding the token can read every secret that account can see. Revoke and regenerate it in the web app if it ever leaks.
Other handy subcommands: sync does a dry run, sync --apply exports into your shell, install repairs the binary and disable turns the integration off while keeping the token and project id.
Website logins with the bw password manager
The Passwords and Logins page covers the other half. If the bw command-line tool is installed and signed in, Hermes picks it up on its own and your Bitwarden website logins become fillable.
The first time the agent needs one of those logins, Hermes asks for your master password in a masked prompt. It hands it to bw unlock through the child process environment and keeps only the session token in memory. The unlock lasts once per session, with a 30-minute idle timeout.
The agent works through the browser_vault tool, with the actions list, fill, save_login, enter_code and unlock. Hermes refuses a fill unless the page origin matches the saved item, and the model never sees the password.
Bitwarden items that hold a TOTP seed let Hermes generate and enter the 2FA code too. To stop using Bitwarden for logins, run hermes vault sources --disable bitwarden.
If you use 1Password instead, the Hermes 1Password guide walks through the same two halves for that manager.
When Bitwarden is the wrong fit
The docs are direct about this. A single-machine personal setup where .env is fine gains little, because you trade one credential for another and add a network call at startup.
Air-gapped machines that can't reach Bitwarden are out. So are CI pipelines that already inject secrets another way, because the docs say to pick one path, not two.
The strong case is several machines: a laptop, a gateway VPS and a shared dev box, all reading the same project, with one place to rotate and revoke.
My verdict on Hermes Agent Bitwarden
For anyone running Hermes on more than one machine, the Secrets Manager hook is worth setting up. Keys rotate in one place, startup never fails because of it, and the token stays out of the agent's reach.
The bw login side needs even less work. If Bitwarden already holds your logins, install and sign in to bw, and Hermes handles the rest with origin checks on every fill.
To see how secrets, profiles and the gateway fit together on one machine, read the Agent OS guide. To choose which model those keys should unlock, compare real task scores on Goldie Bench. Members of the AI Profit Boardroom get Julian's working agent setups, and you can book a free AI strategy session for a plan built around your stack.
FAQ
How do I connect Bitwarden to Hermes Agent?
Run hermes secrets bitwarden setup. Paste a machine-account access token, choose your region and project, and the wizard test-fetches your secrets before it enables the integration.
Where does Hermes keep the Bitwarden token?
The token goes in ~/.hermes/.env as BWS_ACCESS_TOKEN. The project id, region and other settings go in config.yaml under secrets.bitwarden.
Do Bitwarden values replace the keys in my .env file?
Yes, by default, because override_existing is true. Set it to false if you want .env to win, or list single variables under secrets.preserve_existing.
Will Hermes still start if Bitwarden is unreachable?
Yes. You get a one-line warning with the fix command, and Hermes carries on with the keys already in .env.
Can Hermes sign in to websites with my Bitwarden logins?
Yes, when the bw tool is installed and signed in. You unlock it once per session, and Hermes only fills a login on the site saved on that item.
How do I replace an expired Bitwarden token?
Run hermes secrets bitwarden token. Hermes tests the new token with Bitwarden first and only saves it if Bitwarden accepts it.
Create one project, one machine account and one token today, and your keys move into a hermes agent bitwarden setup that rotates from a single place.
