AI 编程安全指南：3800 个仓库被黑之后，你用 AI 写代码还安全吗？

2026 年 5 月 20 日，GitHub 确认 3800 个仓库 因恶意 VSCode 扩展被攻破。同一天，Copilot 的按量计费改革让更多开发者开始尝试新的 AI 编程工具。

工具迁移潮 + 供应链攻击潮，两件事撞在一起。你用 AI 写的每一行代码，会不会成为下一个攻击入口？

一、AI 编程时代的新安全威胁

1.1 攻击面扩展

传统编程的安全问题集中在代码本身（SQL 注入、XSS、CSRF）。AI 编程引入了一个全新的攻击面：

1.2 3800 仓库被黑事件复盘

这个事件说明了一个残酷的现实：开发者对"工具"的信任正在被系统性攻击。

二、Hermes 的五层安全体系

Hermes 在设计之初就考虑了这些问题。它的安全体系是分层递进的：

第一层：命令审批（Approvals）

# ~/.hermes/config.yaml
approvals:
  mode: smart           # manual / smart / off
  timeout: 60           # 审批超时

三种模式：

实际效果： 当 AI 试图执行 rm -rf、git push --force、curl | bash 等命令时，终端会暂停并显示：

⚠️ 该命令可能危险：rm -rf /project/cache/*
是否执行？[y/N]

你确认后才执行。在消息平台上会显示为可点击的确认按钮。

第二层：Secrets 防泄漏（Redact Secrets）

这是最实用的功能之一。AI 执行的命令结果中如果包含 API Key、Token、密码，在进入对话上下文之前会被自动脱敏。

security:
  redact_secrets: true    # 默认开启

覆盖的模式：

sk-proj-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
→ [API_KEY_REDACTED]

ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
→ [TOKEN_REDACTED]

password=mysecret123
→ [PASSWORD_REDACTED]

# 开启
hermes config set security.redact_secrets true

# 关闭（不推荐）
hermes config set security.redact_secrets false

# 需要重启生效

为什么重要： Hermes 的会话历史存在 ~/.hermes/sessions/ 目录下的 SQLite 数据库中。如果对话中不慎出现了 API Key，它会被写入数据库。redact_secrets 在 Key 进入上下文之前就拦截了。

第三层：Tirith 规则引擎

Tirith 是 Hermes 内置的策略评估引擎，在命令执行之前判断其风险等级。

security:
  tirith_enabled: true
  tirith_path: tirith
  tirith_timeout: 5
  tirith_fail_open: true     # 超时时放行还是拦截

Tirith 评估的原理：

AI 要执行命令 → Tirith 规则引擎 → 匹配规则
  ↓                     ↓
安全命令              危险命令
  ↓                     ↓
自动放行            弹确认框或拦截

内置规则覆盖：

• 文件删除操作（rm -rf、shred）
• Git 破坏性操作（git push --force、git reset --hard）
• 系统配置修改（chmod 777、sudo）
• 网络操作（curl | bash、wget -O）
• 凭据操作（export 密钥、cat .env）

第四层：网站黑白名单

可以限制 AI 能访问哪些网站：

security:
  website_blocklist:
    enabled: true
    domains:
      - "pastebin.com"
      - "rentry.co"         # 防止代码被粘贴到公开网站
    shared_files: []

作用：

• 防止 AI 把源代码上传到公开的 pastebin
• 防止 AI 访问已知的恶意网站
• 限制 AI 只能访问公司内部的文档站点

第五层：YOLO 模式

当你 100% 信任当前会话时，可以一键绕过所有安全控制：

hermes --yolo                        # 启动时开启
> /yolo                              # 会话中切换
export HERMES_YOLO_MODE=1            # 环境变量

注意： YOLO 是临时开关，不适合持久化配置。建议只在 CI/CD 或你全程盯着 AI 干活时使用。

三、安全实践清单

3.1 新手必做配置

# 推荐的入门安全配置
approvals:
  mode: smart               # AI 判断风险
  timeout: 60

security:
  redact_secrets: true      # 防泄漏
  tirith_enabled: true
  tirith_fail_open: true

privacy:
  redact_pii: false         # 不是必选项

3.2 团队推荐配置

approvals:
  mode: manual               # 每次都问
  timeout: 30                # 30 秒不确认自动拒绝
  cron_mode: deny            # 无人值守任务禁止危险操作

security:
  redact_secrets: true
  website_blocklist:
    enabled: true
    domains:
      - "pastebin.com"
      - "rentry.co"
      - "codeshare.io"
  tirith_fail_open: false    # 宁可误杀不可放过

3.3 危机情况应急响应

如果怀疑 AI 执行了危险操作：

# 1. 停止所有任务
hermes cron pause <job-id>

# 2. 检查 Gateway 日志
grep -i "rm\|delete\|destroy\|secret" ~/.hermes/logs/gateway.log

# 3. 检查最近的 git 改动
cd /path/to/project
git log --oneline --since="1 hour ago"

# 4. 检查 .env 文件是否被读取
cat ~/.hermes/.env | grep -i "leak\|expose\|sent"

# 5. 重置所有凭据
hermes auth reset openai
hermes auth reset deepseek

3.4 长期安全习惯

1. 用 hermes auth add 管理凭据 — API Key 加密存储在 auth.json，不在明文的 .env 中
2. 定期检查 hermes auth list — 确保没有未授权的 Key
3. 分开 Profile 的凭据 — 工作用 Key 跟个人 Key 分开放
4. secrets 永远不进 Skills — 不要在 SKILL.md 里写任何密钥
5. 审查安装的 Skills — hermes skills inspect 检查 Skill 内容后再安装

四、Kubernetes vs 单机：不同的安全模型

五、总结

回到开头的问题：你用 AI 写的每一行代码，会不会成为下一个攻击入口？

答案是：取决于你怎么用。

• 让 AI 在沙箱里跑、所有危险命令都经过你确认、凭据自动脱敏 → 比你自己手动操作更安全
• 开着 YOLO 模式、不审查 Skill 内容、把所有 Key 放 .env → 风险确实存在

Hermes 的五层安全体系提供了足够多的控制手段。关键是你得用起来——默认配置已经够安全了，但完全可以调到更严。

最后一条铁律： 永远不要把生产环境的凭据放到 .env 里。用 hermes auth add 加密存储，或者用环境变量注入。安全不是功能，是习惯。