Hermes x Bitward - The Security Stack AI Agents Actually Need

Hermes Agent Is Building the Security Stack That Production AI Agents Actually Need

Today Nous Research shipped two pieces of infrastructure on the same day. They solve different problems. Together they’re forming something most agent frameworks don’t have at all: a coherent, layered security model for autonomous agents running in the real world.

Here’s what landed, how it works, and why the rest of the ecosystem is still catching up.

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 a 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, 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. 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. They 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 on disk. Readable by anything with filesystem access. No rotation strategy. No revocation mechanism. If you’re running Hermes on multiple machines — a VPS, a dev box, a gateway server — you’re copy-pasting values everywhere and manually keeping them in sync.

Bitwarden Secrets Manager centralizes this:

One bootstrap token in .env. Everything else lives in Bitwarden. At every Hermes startup, the agent calls bws secret list <project_id> and injects 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 multiple servers to update .env files manually.

Instant revocation. Machine account compromised? Revoke the access token from the web UI. 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:

Free tier. No paid plan required to start.

Layer 2: iron-proxy — credential protection

PR #30179 is fully implemented, 35 unit tests passing, E2E verified, open for review today. 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.

From the PR description:

“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 send its API key finds 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:

And the piece that makes the whole stack coherent:

Real credentials pulled from your BSM project at proxy startup. Rotate a key in Bitwarden — it propagates to all sandboxes on 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, SSH coming in separate PRs.

• Doesn’t 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

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’s the kind of operational property that matters when you’re running agents autonomously, at scale, with access to real systems.

What the rest of the ecosystem looks like

This is where context matters.

By independent assessment, CrewAI provides three security layers — basic input validation, rate limiting, and output filtering. LangGraph provides approximately six, adding thread-level isolation and basic timeout-based resource limiting. Neither implements sandbox-level credential isolation, host function allowlisting, or cryptographic agent identity. In both cases, the production team must implement container-level isolation, network policies, and audit logging themselves.

The pattern across most frameworks is the same: security is documentation, not infrastructure. They tell you to use environment variables carefully, to run agents in Docker, to filter sensitive output. All good advice. None of it is built in.

LangChain shipped LangSmith Sandboxes in March 2026 — microVM-isolated environments for code execution. But this 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 failure modes documented and handled. Not a section in the README. Not something you wire up yourself before you can deploy.

Why this matters beyond Hermes

The broader question the ecosystem hasn’t answered: as agents become more capable and more 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. Not just from external attackers — 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 are implicitly assuming the agent will always behave as intended. That assumption gets harder to maintain as autonomy increases.

What Hermes is demonstrating — with two composable PRs shipped on the same day — is that you can build agent security as infrastructure rather than policy. The credentials never enter the sandbox. The network boundary is the enforcement point. Rotation is a single action that propagates automatically.

That’s the architecture that scales to agents you’d actually trust in production.

The trajectory

Phase 4 of the Hermes secrets roadmap adds ephemeral secrets with configurable TTL — credentials that exist only for the duration of a specific operation and are automatically purged after. 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:

iron-proxy is one merged PR away. - https://github.com/NousResearch/hermes-agent/pull/30179

@NousResearch @Teknium