10.3 权限模型

概念

能力下发要做精细的权限分配，「全公司统一开」是偷懒做法。WorkBuddy 企业后台用下发策略控制每个 Skill / 专家 / 知识库 / 连接器对谁可见、可用（第 5 章讲过配置操作）。

权限模型是约束三层的中间层——管「Agent 能不能做某件事」。核心原则只有一条：最小必要权限（Principle of Least Privilege）。

Agent 不是人，它没有「责任能力」——它调了一个 DELETE 把表删了，你不能让 Agent 赔钱。所以给 Agent 的权限必须比给人更保守：能只读就别给写，能限定作用域就别给全局。

FDE 必须记住的三条权限规则：

用法

权限配置的关键在「收敛」：每一类权限都尽量缩到能完成任务的最小集。权限设计遵循最小必要——先给到刚好够用，再按需放开，比先全开再收难度低得多。

审批链路

Agent 什么都敢执行，还跑得比人快。删表、发邮件、转账，它做完就走，但却不会自己停下来认错。所以，我们在动手前得想清楚一件事，哪些动作可以让它自己做完，哪些必须拦下来，等人来按下确认。这个人工门禁，第 3 章 Harness / Loop 里讲过。怎么拦？按「可逆性 × 影响面」给动作分级，分完就知道哪些要过审批。

🖼 图：approval risk matrix

提示

护栏动作：在自动化任务和 Agent 流程里，把不可逆动作显式设为「命中人工门禁，等待确认后再继续」（第 3 章 Loop 的退出与关卡机制）。这对应第 8 章第二条红线「不替客户做终审决策」——涉及钱、人、法律责任的最终判断必须由人做，且系统里要留下这个人的痕迹。

「二次审批」是个重点：对于不可逆动作（删除、发邮件、转账），不要让 Agent 直接执行，让它进入一个人工审批队列。这叫 「human-in-the-loop」（HITL）。

示例

一个 Skill 权限矩阵示例：

# Skill 权限矩阵（示意）

skills:

  - name: "query_contract"

    permissions:

      db: "contracts_db.contracts:SELECT"  # 只读

      network: "internal_only"

      irreversible_actions: false

  - name: "send_email"

    permissions:

      mail: "send_to_whitelist"  # 只能发白名单收件人

      network: "smtp.internal.corp"

      irreversible_actions: true

      requires_human_approval: true   # 不可逆，强制 HITL

• 上述配置字段为示意结构，实际字段名需参考所使用平台的官方文档确认。

注意事项

• 「不可逆动作」是最大风险点 。Agent 调用 DELETE FROM orders WHERE id < 1000 这种操作一旦执行，回滚成本极高。原则： 所有不可逆动作必须有门禁 ——要么人工审批，要么 dry-run 预览，绝对不要让 Agent 「直接执行就完了」。

提示

护栏动作：配完权限一定用后台的**「权限查询」**验证生效结果，别凭记忆。