Hermes 商业算力安全边界分析 🔒

🎯 威胁模型

Hermes Agent 运行在商业 VPS / 云服务器上使用时，核心的风险不是云厂商偷代码（SSH 加密链路是安全的），而是以下三点：

生产代码被读进上下文 — Hermes 在终端执行 git clone / cat 等命令，读取的生产代码进入 LLM 上下文，通过 API 请求发送到外部（OpenRouter / OpenAI / Anthropic 等）
Git 凭据被意外操作 — 如果 LLM 决定执行 git push/commit，可能对生产仓库造成意外影响
不可控的文件扫描 — 不知道哪些文件会被终端命令或工具读取并暴露到 API 调用中

核心矛盾

使用外部 LLM API 时，Hermes 工具读取的任何文件都会经过 API 请求发出。
你无法保证 LLM 提供商不会记录/训练这些数据。

🛡️ 安全边界策略评估

方案一：创建 demo 和 product 用户隔离

维度	评估
有效？	⚠️ 只有同时配置不同 Git 凭据才有效
漏洞	如果 .env 里只有一个 token 同时有 demo 和 product 权限，分用户也没用
适用场景	多项目隔离，需要独立的 Git 凭据 + 文件系统权限
实施成本	中 — 需要配置用户、SSH 密钥、文件权限

方案二：上传脱敏代码和生产代码（推荐）

维度	评估
有效？	✅ 正确方向
思路	把生产代码脱敏后上传到 Hermes 可访问的隔离目录（如 Trilium 笔记或独立 volume），让 Hermes 只能接触脱敏版本。生产代码放在不可被 Hermes 读取的路径
适用场景	需要 Hermes 理解代码结构但不允许源码外泄
实施成本	中 — 需要脱敏流程和同步机制

方案三：本地 LLM + 敏感数据隔离

维度	评估
有效？	✅ 最彻底
思路	敏感项目使用本地 LLM（ollama / vLLM 等），不走外部 API。demo / 公开项目使用外部 LLM
代价	本地模型能力可能不如云端模型
实施	通过 Hermes profiles 或模型切换，不同项目使用不同 provider

方案四：Hermes 配置文件中的 URL / 域名白名单

维度	评估
有效？	🔶 辅助手段
思路	通过 `website_blocklist` 限制 Hermes 能访问的 URL，防止意外 git clone 到外部仓库
局限	不能防止文件被读入上下文
实施	`hermes config set security.website_blocklist '["prod", "internal"]'`

📋 推荐方案组合

最佳实践（从强到弱）

敏感项目使用本地 LLM — ollama / vLLM 部署在局域网，API 请求不出内网
项目目录白名单 — 在 system prompt 中限定 Hermes 只能在 /workspace/demo/ 下操作
.gitignore 扩展 — 在项目根目录放 .claudeignore 或 .hermesignore，明确排除敏感文件
脱敏代码上传 — 生产代码脱敏后上传到 Trilium，作为知识的来源而非直接读取生产仓库
凭据审计 — 每个项目使用独立的 deploy token，最小权限原则

🔧 实施示例

secure-demo 项目配置

# ~/.hermes/config.yaml 中为 demo 项目配置独立的 profile
# 限制工具集、限制文件系统访问范围

profiles:
  secure-demo:
    model:
      provider: openrouter
      model: anthropic/claude-sonnet-4
    terminal:
      cwd: /workspace/demo/           # 限制工作目录
    environment:
      - GIT_DIR=/workspace/demo/.git  # 限制 git 操作范围
    disabled_toolsets:
      - browser                       # 禁用浏览器工具减少攻击面

— 本文档记录 Hermes Agent 在商业 VPS 上使用的安全边界分析与缓解策略