AI 功能的权限模型：能做与不能做要显式声明

能力边界写在提示词里等于靠模型自觉。本文给出能力矩阵的写法、三层防线（参数/权限/确认）、拒绝要说清原因、审计与最小权限，以及三个常见漏洞与一条越权用例判据。

"能做/不能做"要写下来，而不是靠模型自觉

AI 功能的能力边界如果只写在提示词里 ✗，就等于**靠模型自觉** ✔ —— 它会在边界上摇摆 ✗。

正确做法是把权限与边界做成**显式声明** ✔，并在**代码层**执行 ✔（不是提示词层 ✗）。

```

角色 × 动作 × 对象 × 条件

客服 × 查询 × 订单 × 仅本租户

客服 × 修改 × 地址 × 需用户确认

主管 × 退款 × 订单 × 金额 ≤ 500 且需二次确认

外部 × 任何写操作 × 任何对象 × ❌ 禁止

```

**要点**：矩阵是**代码里的配置** ✔，不是文档里的描述 ✗；

矩阵要**可测试**（每行一条用例 ✔）。

1. **参数层**：模型给的参数先校验（范围、枚举、外键存在 ✔）；

2. **权限层**：动作与对象是否在矩阵内 ✔（**独立于模型判断** ✔）；

3. **确认层**：高风险动作**必须人确认** ✔（确认信息要人看得懂 ✔）。

模型输出**只作为意图** ✔，执行与否由这三层决定 ✔（见接线与工具设计两篇 ✔）。

拒绝时说明**为什么**（权限不足 / 需要确认 / 超出范围 ✔）；

给出**可行替代**（"可以帮你提交申请，由主管审批" ✔）；

记录拒绝原因（便于发现"权限过紧"或"角色配错" ✔）。

**忌讳**：静默失败 ✗ 或假装成功 ✗（后者最危险 ✔）。

**最小权限**：默认只给需要的动作 ✔（不要"为了方便"给全部 ✗）；

**审计日志**：谁、什么时候、以什么身份、执行了什么动作 ✔；

**定期复核**：每季度看一遍谁拥有高风险权限 ✔（离职/转岗后及时收回 ✔）。

**把权限判断交给模型** ✗（提示词写"你不能改地址"，模型仍可能改 ✔）；

**只在界面隐藏按钮** ✗（直接调接口就绕过了 ✔）—— 与检索权限同一个坑 ✔；

**权限配置写死在代码里** ✗（改一次要发版 ✔）→ 放配置 ✔，但要**有审计与默认拒绝** ✔。

> 拿一份"越权用例清单"（20 条 ✔）直接打接口（**不走界面** ✔），

> 是否**全部被拒绝**且拒绝原因清楚 ✔？有一条通过，就是权限漏洞 ✗。