05 · 哪些权限可以批准,凭据应该怎样处理
安全不是“一律不让它做”,而是让权限、范围和后果匹配。
这是课程第一阶段的最后一篇。你会用一套固定问题判断文件、命令、网络和外部操作的风险,并学会添加、检查、撤销凭据。结束后,你应该能解释为什么同一个动作在练习目录里可以批准,在生产环境里却必须停下来。
看完会得到什么
- 一套五问权限检查法
- 一张常见动作风险表
- 凭据添加、查看和撤销的安全路径
- 凭据泄露后的处理顺序
- 一个可以反复使用的审批原则
开始前
- 预计时间:15—20 分钟
- 前置课程:04 · Hermes 是怎样完成任务的
- 已验证日期:2026-07-17
- 已实测命令:
hermes auth、hermes auth add/list/remove/logout、hermes status、hermes doctor - 本篇不会要求你创建新的真实 API key
- 本篇不会执行删除、发布、支付或生产环境操作
安全的第一原则:先看后果,不看动作名字
“写文件”听起来普通,但写入练习目录的新文件和覆盖生产配置不是同一风险。“运行命令”也一样:查看版本与安装未知脚本不能放在同一类。
批准前问五个问题:
- 它会接触什么? 是一个练习文件,还是整个主目录、通讯录或服务器?
- 它会改变什么? 只读、新建、覆盖、删除,后果不同。
- 能不能恢复? 有备份、版本控制或撤销路径吗?
- 结果会不会离开本机? 联网、发消息、发布和提交交易会产生外部影响。
- 是否涉及凭据、资金或生产系统? 只要涉及其中一项,就提高一个风险等级。
常见动作风险表
| 动作 | 默认风险 | 通常怎样处理 |
|---|---|---|
| 读取指定练习文件 | 低 | 范围明确时可批准 |
| 在练习目录新建结果文件 | 低到中 | 确认文件名和目录后批准 |
| 覆盖已有文件 | 中 | 先看 diff 或保留备份 |
| 安装依赖 | 中 | 核对来源、项目和影响范围 |
| 访问公开网页 | 中 | 确认是否会上传本地内容 |
| 读取整个主目录 | 高 | 通常拒绝,缩小范围 |
| 删除文件或数据库记录 | 高 | 先备份、列出对象并人工确认 |
| 向外部账户发送消息 | 高 | 先生成草稿,再确认收件人和正文 |
| 发布公开内容 | 高 | 人工终审后执行 |
| 修改生产环境或安全策略 | 高 | 分离诊断和执行,明确回滚方案 |
| 支付、转账或提交交易 | 高 | 人工确认金额、对象、网络和不可逆性 |
| 展示或转发凭据 | 极高 | 拒绝;如已发生立即撤销 |
这张表不是自动审批规则。同一个动作的对象、范围和环境改变后,风险也会改变。
把任务拆成“准备”和“执行”
高风险任务不要一句话交给 Agent 全部完成。更稳妥的方式是把它拆开:
例如,不要直接说:
帮我修好生产服务器。先说:
只读取当前服务状态、磁盘、内存和最近日志,不修改配置。输出问题清单、建议动作、影响和回滚方式,等我确认后再执行。这样不是让 Agent 变慢,而是把不可逆决定留在信息更充分的时刻。
凭据是什么
凭据是用来证明身份或授权访问的秘密,例如:
- API key;
- OAuth 登录状态;
- GitHub Token;
- 云服务访问密钥;
- 钱包私钥或助记词。
最后一类不应该交给普通 Agent 工作流保管或输入。涉及钱包签名时,应使用专门的安全工具和人工确认边界。
凭据应该放在哪里
优先顺序:
- 使用 provider 提供的 OAuth 登录;
- 使用 Hermes 的凭据管理命令;
- 只有官方流程明确要求时,才把 API key 放入 Hermes 的环境配置文件;
- 永远不要把 key 写在提示词、教程正文、截图、Git 提交或公开 Issue 中。
添加某个 provider 的凭据时,可以使用:
hermes auth add <provider>例如 <provider> 应替换为 Hermes 当前支持的 provider ID。命令会进入对应的 OAuth 或安全输入流程。不要使用把真实 key 直接写在命令参数里的方式,因为终端历史可能保存它。
查看已保存的凭据条目:
hermes auth list按 provider 查看:
hermes auth list <provider>这些命令用于查看条目和状态,不应显示完整秘密值。
如果官方流程要求检查环境配置文件位置,使用:
hermes config env-path这个命令只显示文件路径。不要把该文件内容整体复制到聊天或公开页面。
怎样撤销 Hermes 中保存的凭据
先列出条目:
hermes auth list <provider>再按索引、条目 ID 或准确标签移除:
hermes auth remove <provider> <target>如果要退出某个 provider 并清理其登录状态:
hermes auth logout <provider>注意:**从 Hermes 本地移除,不一定等于服务端 Token 已失效。**如果凭据已经泄露,还必须到对应 provider 的账户安全页面撤销或轮换。
凭据泄露后怎样处理
假设一个 Token 已经被发到群聊。不要继续测试它“还能不能用”,按下面顺序处理:
- 在对应服务端撤销泄露的 Token;
- 删除公开消息或页面中的明文,但不要把“已删除”当作“未泄露”;
- 检查账户安全日志和异常访问;
- 从 Hermes、本地配置和自动化环境中移除旧凭据;
- 如仍需使用,创建权限更小、有效期更短的新凭据;
- 更新依赖该凭据的工作流,并验证旧凭据已经失效。
凭据一旦公开,就应视为已经被复制。仅仅编辑消息、重启 Agent 或清空会话都不能让它重新安全。
最小权限怎样落地
“最小权限”不是一句口号,而是三个具体限制:
限制对象
只让 Agent 访问完成任务需要的文件、仓库、账号和服务。
限制动作
只读任务不要开放写入;准备草稿不要同时开放发布;诊断问题不要自动修改生产配置。
限制时间
临时任务使用短期凭据。任务结束后撤销,不让一次授权无限期留在环境里。
Hermes 的审批模式
Hermes 可以对终端命令等动作进行风险判断和审批。新人建议保留默认的智能审批模式:
hermes config set approvals.mode smart不要为了少点一次确认就使用 --yolo 或关闭审批。绕过提示不能提高任务质量,只会取消一道阻止高风险动作的检查。
审批仍不是完整沙箱。真正重要的任务还需要:
- 独立工作目录;
- 版本控制或备份;
- 最小系统账户权限;
- 发布、支付和生产修改前的人工确认;
- 执行后的真实验收。
四个审批练习
练习一:读取练习目录
任务要求整理三个公开样例,Hermes 请求读取这三个文件。
**可以批准。**对象和动作都在任务范围内,且只读。
练习二:为了整理资料,读取整个主目录
**不批准。**要求它只读取明确的资料目录或文件清单。
练习三:准备一封合作邮件后直接发送
**先批准写草稿,不批准直接发送。**检查收件人、正文、附件和身份后,再单独确认发送。
练习四:修复线上服务
Hermes 已定位到配置问题,请求立即重启并覆盖配置。
**先停下来。**要求它给出 diff、影响、备份、回滚和验证步骤;由有权限的人确认窗口后执行。
出错时按这个顺序查
不知道凭据保存在哪里
- 运行
hermes auth list; - 运行
hermes config env-path查看环境文件位置; - 不要搜索并公开打印整个主目录中的秘密;
- 对照 provider 官方文档确认服务端撤销入口。
批准了不该批准的操作
- 使用
/stop或终止当前 Hermes 进程; - 检查工具实际执行到了哪一步;
- 对文件使用备份或版本控制恢复;
- 对外部操作检查发送、发布或交易状态;
- 涉及凭据时立即撤销并轮换。
不确定一个动作是否高风险
默认先拒绝执行,让 Hermes说明:对象、范围、外部影响、恢复方式和验收步骤。信息不足时,不执行比猜测更安全。
本篇作品
写下你自己的审批原则,至少包含下面这句话:
低风险、范围明确、可恢复的动作可以在验收条件下执行;涉及外部发布、删除、支付、生产系统和凭据的动作,必须由人确认具体对象和后果。
本篇验收
- [ ] 能用五个问题判断一次工具操作
- [ ] 能区分读取、新建、覆盖、删除和外部发布的风险
- [ ] 知道凭据不能进入普通对话、截图或 Git
- [ ] 知道怎样列出、移除和退出 Hermes 的 provider 凭据
- [ ] 知道本地删除凭据不等于服务端撤销
- [ ] 知道审批不是沙箱,也不替代结果验收
第一阶段完成
你已经完成第一次对话、真实文件任务、工作机制和安全边界。下一阶段不会急着增加更多功能,而是先学习怎样把模糊需求写成可执行任务,并管理会话、工具、Memory 和 Skills。