Hermes x Bitwarden: The Security Stack AI Agents Actually Need

The problem nobody is solving properly

Every AI agent that does something useful needs credentials: API keys, access tokens, wallet keys, RPC endpoints. The more capable the agent, the more sensitive the credentials it holds.

Most frameworks treat this as the developer's problem. You figure out the secrets. You figure out the isolation. You figure out what happens when something goes wrong.

The real threat model for production agents has two distinct layers that almost nobody separates clearly:

• Credential management — where do secrets live, how do you rotate them, and how do you revoke access instantly across a fleet of running agents?
• Credential protection — what happens when the agent itself is the attack surface? Prompt injection through tool output, a malicious skill, or a jailbreak buried in a fetched webpage. The agent is running with your API keys in os.environ — and now so is whatever compromised it.

These are different problems that need different solutions. Hermes shipped both on the same day.

Layer 1: Bitwarden Secrets Manager — credential management

Before this integration, the standard Hermes setup looked like every other agent framework — plaintext secrets on disk:

~/.hermes/.env
──────────────
BINANCE_API_KEY=xxx
WALLET_PRIVATE_KEY=********
OPENROUTER_API_KEY=xxx
TELEGRAM_BOT_TOKEN=xxx

Plaintext on disk, readable by anything with filesystem access. No rotation strategy, no revocation mechanism. If you run Hermes on multiple machines — a VPS, a dev box, a gateway server — you are copy-pasting values everywhere and manually keeping them in sync.

Bitwarden Secrets Manager centralizes this. One bootstrap token stays in .env; everything else lives in the vault:

~/.hermes/.env          Bitwarden Vault
──────────────          ───────────────
BWS_ACCESS_TOKEN=****    WALLET_PRIVATE_KEY
                         OPENROUTER_API_KEY
                         TELEGRAM_BOT_TOKEN

At every Hermes startup, the agent calls bws secret list <project_id> and injects the results into os.environ. The bws binary downloads itself automatically — no apt, no brew, no sudo.

What this actually gives you

• Centralized rotation. Change a key once in the Bitwarden web app. Every Hermes instance picks it up on next restart — no SSH-ing into servers to edit .env files.
• Instant revocation. Machine account compromised? Revoke the access token from the web UI and every instance loses access immediately.
• Graceful failure. If Bitwarden is unreachable at startup, Hermes logs a warning to stderr and continues with whatever was already in .env. No hard dependency on external availability.
• Self-protection. Hermes refuses to let Bitwarden overwrite the bootstrap token itself, even with override_existing: true. The system protects against its own misconfiguration.

Setup

hermes secrets bitwarden setup   # wizard: installs bws, prompts for token, picks project
hermes secrets bitwarden status  # verify
hermes secrets bitwarden sync    # dry-run: see exactly what gets applied

Available on the free tier — no paid plan required to start.

Layer 2: iron-proxy — credential protection

PR #30179 is fully implemented, with 35 unit tests passing and E2E verified. It is open for review and not yet merged to main, but the code is complete and running.

The architecture flips the standard model entirely. Instead of injecting real credentials into the sandbox environment, Hermes gives the agent opaque proxy tokens. The agent makes an outbound API call using that token, iron-proxy intercepts at the network boundary, swaps the proxy token for the real credential, and forwards the request.

The sandbox never contains the actual key. As the PR puts it: "Compromise the sandbox and the attacker walks away with tokens that only work from behind the proxy."

What this closes concretely

• A prompt-injected agent that tries to read and exfiltrate its API key finds only a proxy token — useless outside the proxy, useless on non-allowlisted hosts.
• A compromised sandbox dependency that tries to phone home hits HTTP 403.
• An SSRF attempt to cloud metadata endpoints (169.254.169.254) is denied by default.

New CLI surface

hermes egress install   # downloads pinned iron-proxy binary, SHA-256 verified
hermes egress setup     # interactive wizard
hermes egress start     # spawn the managed proxy daemon
hermes egress status    # binary + config + pid + active mappings

And the piece that makes the whole stack coherent:

hermes egress setup --from-bitwarden

Real credentials are pulled from your BSM project at proxy startup. Rotate a key in Bitwarden and it propagates to all sandboxes on the next proxy restart — no .env changes anywhere in the chain. One action in a web UI, full propagation across the fleet.

Honest scope (from the PR itself)

• Docker backend only for now. Modal, Daytona, and SSH are coming in separate PRs.
• It does not protect a compromised host process — real keys live in host env regardless.
• Sandboxes that bypass HTTPS via raw sockets are out of scope.
• No native Windows binary yet.

This is defense-in-depth for the sandbox layer — not a complete solution, but the right architecture for that layer.

How the two layers compose

Bitwarden Secrets Manager
└── One bootstrap token → N secrets in vault
└── Centralized rotation via web UI
└── Instant revocation across entire fleet
        ↓
        --from-bitwarden
        ↓
iron-proxy egress firewall
└── Sandbox holds opaque tokens, not real keys
└── Credentials injected at network boundary only
└── Non-allowlisted hosts → HTTP 403
└── Cloud metadata endpoints → denied by default
└── Rotate in Bitwarden → propagates to all sandboxes

Rotating a credential is a single action in the Bitwarden web app — and that rotation propagates through to sandbox isolation without touching any configuration files or redeploying anything. That is the kind of operational property that matters when you run agents autonomously, at scale, with access to real systems.

Where the rest of the ecosystem stands

The pattern across most frameworks is the same: security is documentation, not infrastructure. By independent assessment, CrewAI offers roughly three security layers (basic input validation, rate limiting, output filtering). LangGraph adds around six, including thread-level isolation and timeout-based resource limiting. Neither implements sandbox-level credential isolation, host function allowlisting, or cryptographic agent identity — those remain the production team's job.

LangChain shipped LangSmith Sandboxes (microVM-isolated execution environments), but that addresses code-execution isolation, not credential management and protection at the framework level.

The gap Hermes is filling: treating credential security as a first-class infrastructure problem with its own CLI, its own composable architecture, and its own documented failure modes — not a section in the README, and not something you wire up yourself before you can deploy.

Why this matters beyond Hermes

As agents become more capable and autonomous, the attack surface isn't just the infrastructure they run on — it's the agents themselves. An agent that can browse the web, execute code, and call financial APIs is a target, and not only from external attackers but from the content it processes: a malicious webpage, a poisoned tool result, a prompt-injected skill. The agent is both the executor and the potential vector.

Frameworks that treat credential security as a developer responsibility implicitly assume the agent will always behave as intended. That assumption gets harder to maintain as autonomy increases. Hermes demonstrates that you can build agent security as infrastructure rather than policy: the credentials never enter the sandbox, the network boundary is the enforcement point, and rotation is a single action that propagates automatically.

The trajectory

• Phase 4 of the secrets roadmap adds ephemeral secrets with configurable TTL — credentials that exist only for the duration of a specific operation and are automatically purged afterward.
• HashiCorp Vault and AWS Secrets Manager support for teams already invested in those systems.
• Enhanced audit logging for compliance requirements.
• Modal, Daytona, and SSH backends for iron-proxy in separate follow-up PRs.

The direction is consistent: every layer of the stack gets a proper security primitive, and those primitives compose with each other by default.

The bottom line

For anyone building agents that touch sensitive systems — financial APIs, production infrastructure, personal data — this is the framework to watch.

# Bitwarden is available now
hermes secrets bitwarden setup

iron-proxy is one merged PR away (NousResearch/hermes-agent#30179).

Source: write-up by YanXbt. Credit to @NousResearch and @Teknium for the underlying work.