Hermes x Bitwarden — AI 智能体真正需要的安全栈

Hermes Agent 正在构建生产级 AI 智能体真正需要的安全栈

今天，Nous Research 在同一天发布了两个基础设施组件。它们解决不同的问题，但组合在一起，正在形成大多数智能体框架完全缺少的东西：一套针对在真实世界中运行的自主智能体的、连贯且分层的安全模型。

以下是发布的内容、工作原理，以及为什么生态系统的其他部分仍在追赶。

没人真正解决的问题

每个能做有用事情的 AI 智能体都需要凭证：API 密钥、访问令牌、钱包密钥、RPC 端点。智能体能力越强，它持有的凭证就越敏感。

大多数框架把这当作开发人员的问题。你自己搞定秘密管理，自己搞定隔离，自己搞定出问题时该怎么办。

生产级智能体的真实威胁模型有两个不同的层面，几乎没有人能清晰地区分开：

• 凭证管理——秘密存在哪里？如何轮换？如何在一组正在运行的智能体之间立即撤销访问权限？
• 凭证保护——当智能体本身成为攻击面时会发生什么？通过工具输出的提示注入、恶意技能、隐藏在抓取网页中的越狱。智能体带着你的 API 密钥运行在 os.environ 中，现在，任何攻破它的东西也都拥有了这些密钥。

这些是不同的问题，需要不同的解决方案。Hermes 在同一天交付了两者。

第一层：Bitwarden Secrets Manager — 凭证管理

在这次集成之前，标准的 Hermes 设置与其他智能体框架一样：明文存储在磁盘上，任何拥有文件系统访问权限的进程都能读取，没有轮换策略，没有撤销机制。如果你在多台机器上运行 Hermes —— 一台 VPS、一台开发机、一台网关服务器 —— 你需要在各处复制粘贴值，并手动保持同步。

Bitwarden Secrets Manager 实现了集中化管理： 一个启动令牌放在 .env 文件中，其余所有内容都存放在 Bitwarden 中。每次 Hermes 启动时，智能体调用 bws secret list 并将结果注入 os.environ。bws 二进制文件会自动下载 —— 不需要 apt、brew 或 sudo。

这实际带来了什么：

• 集中化轮换。 在 Bitwarden Web 应用中一次性修改密钥，所有 Hermes 实例在下次重启时自动获取更新。无需 SSH 登录多台服务器手动更新 .env 文件。
• 即时撤销。 机器账户被攻破？在 Web UI 中撤销访问令牌，所有实例立即失去访问权限。
• 优雅降级。 如果启动时 Bitwarden 不可达，Hermes 向 stderr 输出警告，并继续使用 .env 中已有的内容。不对外部可用性产生硬依赖。
• 自我保护。 即使设置了 override_existing: true，Hermes 也拒绝让 Bitwarden 覆盖启动令牌本身。系统能防止自身配置错误。

设置： 免费层级即可使用，无需付费计划即可开始。

第二层：iron-proxy — 凭证保护

PR #30179 已完全实现，35 个单元测试通过，端到端验证完成，今天开放评审。尚未合入主分支，但代码已完成并正在运行。

该架构彻底颠覆了标准模式。Hermes 不将真实凭证注入沙箱环境，而是给智能体提供不透明的代理令牌。智能体使用该令牌发出出站 API 调用。iron-proxy 在网络边界拦截，将代理令牌替换为真实凭证，然后转发请求。沙箱中从不包含真实的密钥。

来自 PR 描述：

“攻破沙箱后，攻击者只能拿到仅能在代理后面起作用的令牌。”

这具体解决了什么问题：

• 一个被提示注入的智能体试图读取并发送其 API 密钥时，会发现一个代理令牌 —— 在代理外部无用，在未列入白名单的主机上也无用。
• 一个被攻破的沙箱依赖试图回连时，会收到 HTTP 403。
• 对云元数据端点（169.254.169.254）的 SSRF 尝试默认被拒绝。

新的 CLI 界面：

hermes proxy <port> --bsm-project-id <project_id>

而让整个栈连贯起来的关键点是：真实凭证在代理启动时从你的 BSM（Bitwarden Secrets Manager）项目中拉取。在 Bitwarden 中轮换一个密钥 —— 下次代理重启时，它会传播到所有沙箱。整个链路中无需修改 .env。在 Web UI 中执行一个操作，即可在全量实例中传播。

诚实范围（来自 PR 本身）：

• 目前仅支持 Docker 后端。Modal、Daytona、SSH 将在后续 PR 中支持。
• 不保护被攻破的主机进程 —— 真实密钥无论如何都存在于主机环境中。
• 通过原始套接字绕过 HTTPS 的沙箱不在范围内。
• 尚无原生 Windows 二进制文件。

这是沙箱层的纵深防御 —— 不是完整的解决方案，但却是该层的正确架构。

两层如何协同工作

轮换凭证只需在 Bitwarden Web 应用中的一个操作 —— 并且该轮换会传播到沙箱隔离中，无需碰触任何配置文件或重新部署。当你在大规模运行自主智能体并拥有真实系统访问权限时，这种运维特性至关重要。

生态系统其他部分的样子

这里上下文很重要。 根据独立评估：

• CrewAI 提供了三个安全层 —— 基本的输入验证、速率限制和输出过滤。
• LangGraph 提供了大约六个安全层，增加了线程级隔离和基本的基于超时的资源限制。

两者都没有实现沙箱级凭证隔离、主机函数白名单或密码学智能体身份。在这两种情况下，生产团队必须自己实现容器级隔离、网络策略和审计日志记录。

大多数框架的模式是一样的：安全是文档，而不是基础设施。它们告诉你要谨慎使用环境变量，要在 Docker 中运行智能体，要过滤敏感输出。这些都是好建议，但没有一个是内置的。

LangChain 在 2026 年 3 月发布了 LangSmith Sandboxes —— 用于代码执行的微虚拟机隔离环境。但这解决的是代码执行隔离，而不是框架层面的凭证管理和保护。

Hermes 正在填补的空白：将凭证安全视为一等基础设施问题，拥有自己的 CLI、自己的可组合架构，以及已记录并处理好的自己的故障模式。不是 README 中的一节。不是你需要自己搭建才能部署的东西。

为什么这对 Hermes 之外也重要

生态系统尚未回答的更广泛问题是：随着智能体变得更强大、更自主，攻击面不仅仅是它们运行的基础设施，还包括智能体本身。

一个能够浏览网页、执行代码并调用金融 API 的智能体是一个目标。不仅是来自外部攻击者 —— 而且来自它处理的内容：恶意网页、被投毒的工具结果、被提示注入的技能。智能体既是执行者，也是潜在的媒介。

将凭证安全视为开发者责任的框架，隐含地假设智能体将始终按预期行为。随着自主性的提高，这一假设越来越难以维持。

Hermes 通过在同一天发布两个可组合的 PR 所证明的是：你可以将智能体安全构建为基础设施，而不是策略。凭证永远不会进入沙箱，网络边界是执行点，轮换是一个自动传播的单一操作。

这是能让你真正信任投入生产的智能体的架构。

未来方向

Hermes 秘密管理路线图的第四阶段增加了可配置 TTL 的短期秘密 —— 仅为特定操作而存在并在完成后自动清除的凭证。为已投入相关系统的团队提供 HashiCorp Vault 和 AWS Secrets Manager 支持。增强合规性要求的审计日志。iron-proxy 的 Modal、Daytona 和 SSH 后端将在后续 PR 中提供。

方向是一致的：栈的每一层都将获得合适的安全原语，并且这些原语默认相互可组合。

总结

对于任何构建接触敏感系统（金融 API、生产基础设施、个人数据）的智能体的人来说，这是值得关注的框架。 Bitwarden 现已可用；iron-proxy 只需一次合并 PR 即可。

• https://github.com/NousResearch/hermes-agent/pull/30179
  @NousResearch @Teknium