<!-- 文档分类: OPS-MAN-060 | 阶段: 运维 | 主题: 高危操作为何被拒与如何放行 -->
# [OPS-MAN-060] 高危操作为何被拒与如何放行

> **参考手册** · 当你看到「高危操作被拒绝 / 无法执行」时，一页看懂**为什么**，以及**三条合规放行途径**。
>
> **一句话定位**：khy 的高危（红灯 L2）操作**永不自动执行**——必须由**真人当场键入确认**，或**事先在策略里放行**。这是安全下界，不是 bug。
>
> **关联规范**：[DESIGN-ARCH-026] khyos 系统级服务调用审批网关规范（§4 三级矩阵、§6.2 熔断、§10 风险词汇）

---

## 1. 先分清两种「被拒」

看到高危被拒，先判断是哪一种——处理方式完全不同：

| 现象 | 性质 | 该怎么办 |
|---|---|---|
| **非交互环境下**高危操作直接被拒（自主/Goal、管道、后台、CI），错误里写「无法当场键入确认」 | **环境性拒绝**——环境从没提供确认通道，模型无过错 | 见 §3 三条放行途径 |
| 交互式 TUI 里弹了确认框，但你**按了回车 / 输入了小写 yes / 输入不匹配** | 确认串不匹配——**必须严格键入大写 `YES`** | 重新执行，键入 `YES` |
| 你（或模型）反复用 `force:true` / `--yes` 想跳过审批 | **旁路注入**——零容忍，一次即熔断 | 别再注入旁路标志；用 §3 合规途径 |

> **重要变化**：环境性拒绝**不再计入熔断**。以前三个互不相关的合法高危操作在 headless 下撞三次
> 「环境从没给过的确认门」，就会把整个会话锁死（跳闸后连只读也全拒）。现在网关按 `cause` 区分
> 「环境没给通道」与「反复硬闯红线」，前者不跳闸——会话不会再被合法高危操作砖掉。详见
> [DESIGN-ARCH-026] §6.2。

---

## 2. 为什么高危不能「自动批准通过」

这是**有意**的安全设计，不会放松：

- **红灯 L2 = 毁灭性 / 不可逆 / 系统级**：删文件、杀进程、改宿主环境变量、全局装包、监听端口、
  执行任意代码、写系统级路径。这类操作一旦误执行无法回退。
- **L2 永不免审**（`isExemptible(L2) === false`）：没有「记住选择」「本会话免审」的快捷键——红灯无捷径。
- **fail-closed**：非交互环境拿不到你键入的确认串 → 按安全默认**拒绝**，绝不「静默放行」。
- **旁路零容忍**：任何 `force:true` / `--yes` / `skipApproval` 夹带都判旁路企图，一次即熔断。

> 换句话说：**危险操作被拒，是网关在正常工作**，不是故障。放行的正确姿势是「授权」，不是「绕过」。

---

## 3. 三条合规放行途径

### 途径 ①：在交互式 TUI / REPL 里运行，当场键入 `YES`（最常用）

直接在终端跑 `khy`（进入交互式 TUI / REPL），而不是在自主 / 管道 / 后台里跑。高危操作会弹出确认框，
**严格键入大写 `YES`**（回车、空、小写 `yes` 都不通过）即放行本次。

适用：临时的、一次性的高危操作，你人就在场。

### 途径 ②：在 `~/.khy/permissions.json` 配置放行策略

若某工具 / 命令你**确定要长期允许**，可在权限策略里预先放行，避免每次打断。策略文件位于
`~/.khy/permissions.json`。策略与网关的三级矩阵配合工作——参见 [DESIGN-ARCH-058] 权限模式与钩子地板。

适用：可预期的、重复的高危操作（且你已充分评估风险）。

> **注意**：策略放行 L1（黄灯）体验最顺；**L2（红灯）的破坏性 / 系统级红线操作仍建议人工复核**，
> 不要图省事把毁灭性操作长期放行。

### 途径 ③：破坏性 / 系统级操作 → 人工复核后执行

删库、`rm -rf`、全局装包、改系统环境这类操作，**最稳妥的做法是人来做，或人复核后在交互式会话里键入
`YES`**。让自主 agent 无人值守地跑毁灭性操作，本就不该发生。

---

## 4. 相关环境门控清单

所有安全行为都可经环境变量门控（默认全开；关闭即逐字节回退历史行为）。**不要在生产/无人值守场景关闭它们。**

| 环境变量 | 默认 | 作用 |
|---|---|---|
| `KHY_SYSCALL_GATEWAY` | 开 | 网关总开关。`=off` 回退纯既有管线（**不建议关**） |
| `KHY_GATEWAY_BREAKER_SMART` | 开 | 熔断排除「环境性拒绝」，只计真·硬闯。`=off` 回退「所有 L2 被拒都计数」的旧行为（会话易被锁死） |
| `KHY_GATEWAY_DENIAL_GUIDANCE` | 开 | 拒绝时向错误信息追加「为什么 + 怎么办」可执行指引。`=off` 只冷拒绝 |
| `KHY_L2_SESSION_ALLOW` | —— | L2 会话级放行相关（红线，勿滥用） |

---

## 5. 常见问答

**Q：为什么我的 Goal / 自主任务一执行高危就整个卡住 / 全部被拒？**
A：旧版本里，环境性拒绝会误计熔断，三次即跳闸锁死全会话。现已修复（`KHY_GATEWAY_BREAKER_SMART`
默认开，环境性拒绝不计熔断）。若仍遇到，确认没把该门控设成 `off`。

**Q：我把命令改成 `rm -rf ... --force` 想跳过确认，结果被熔断了？**
A：`--force` / `force:true` 属**旁路注入**，零容忍、一次即熔断。请改用 §3 的合规途径，不要夹带旁路标志。

**Q：确认框我明明点了同意，还是被拒？**
A：L2 要求**严格键入确认串 `YES`**（大写），仅点「同意」按钮或按回车不算。请键入 `YES`。

**Q：风险层级（safe/low/medium/high/critical 与 L0/L1/L2）到底怎么对应？**
A：见 [DESIGN-ARCH-026] §10 的「5→3 映射表」。关键点：L 级由 **action + scope + 破坏性**共同决定，
不只看风险标签——所以 `critical` 恒 L2，但单纯 `high` 若只是项目内写 / 网络出站可能只是 L1。
