AI 接入数据库、源码和远程执行之后，最容易产生一个错觉：只要请求带着合法 Token，工具调用就安全了。

其实 Token 通常只回答第一个问题——“你是谁”；系统还必须回答第二个问题——“你这次能做什么”。一个只负责读结构的助手，不该顺手获得改源码、跑任务甚至调角色权限的能力。

这篇文章不谈抽象的“零信任”，只拆一个可复现的源码事实：如何给 AI 工具分成读取、写入、执行、管理四类能力，并让新入口在漏标时默认拒绝。

一、一枚 Token 解决不了第二个问题

Microi 官方文档把 MCP 描述为 AI 与数据库结构、应用源码、远程执行之间的连接层。连接层越能干，授权就越不能只停在“登录成功”。官方 MCP 文档也把连接配置、工具发现和真实可调用性分成了不同诊断层。

这里要先分清两种东西：

• 身份凭证证明调用者是谁、属于哪个租户；
• 能力范围限制这枚凭证可以触碰哪一类工具动作。

在当前提交态源码里，普通后台管理员会话继续保持既有行为；新增的能力判断重点约束 AccessKey 会话。这样做没有另起第二套用户体系，也没有替换 DiyToken，只是在工具入口前再加一道“动作级”门禁。

二、四把钥匙怎么分

源码把能力范围收敛成四个枚举：

public enum V8McpScope
{
    Read,
    Write,
    Execute,
    Admin
}

这四类不是按接口名字拍脑袋分，而是按副作用分：

1. Read：读取 Schema、应用上下文、配置和状态，不改变业务资源。
2. Write：同步源码、更新配置、写入低代码资源。
3. Execute：运行接口引擎、任务或浏览器执行上下文。
4. Admin：改变角色权限、安全门、外部数据库连接等平台边界。

分类的好处不是“看起来整齐”，而是能给不同 Agent 发不同钥匙。文档整理助手只拿 mcp:read；发布机器人可以按流程拿 read + write；真正需要远程运行的执行器再增加 execute。高风险的 admin 不应该成为默认套餐。

三、关键不在四个枚举，而在漏标也拒绝

很多权限设计只检查“声明了什么”，却没定义“忘记声明怎么办”。这才是新增端点最容易穿透的地方。

当前过滤器先查动作上的能力属性；找不到时直接返回 403。逻辑可以简化成：

var capability = action.GetCustomAttribute
  
   ();
if (capability == null)
{
    return Forbidden("未声明能力范围，默认拒绝");
}

  

这叫 fail closed：配置遗漏时，系统坏在安全的一侧。开发者会立刻看到端点不可用，然后补上明确分类；而不是等某个拥有 AccessKey 的 Agent 偶然发现它可以越权调用。

它还改变了权限评审的重心。评审者不必猜一个新接口会不会被某个宽泛角色顺带放行，只需检查动作属于哪一级、调用方是否持有对应能力，以及拒绝路径有没有被测试覆盖。这样，新增工具时产生的是一条显式的授权决策，而不是悄悄扩大旧 Token 的含义。即便以后把工具交给不同模型、插件或自动化任务，审计记录也能回答“谁用哪把钥匙做了什么”，而不只剩下一串登录成功日志。

四、104/104 是怎么来的

为了避免把“我看到几个属性”写成结论，我从 Git HEAD 读取控制器，而没有采用当前工作区文件。原因很现实：工作区同时存在别人的未提交改动，文章数字必须绑定一个稳定、可复现的树。

静态扫描结果是：104 个 HTTP 动作，104 个能力属性；其中 Read=49、Write=31、Execute=9、Admin=15。仓库中的 xUnit 测试也把“动作数固定为 104、每个动作恰好一个能力声明”写成了断言：

Assert.Equal(104, actions.Count);
Assert.All(actions, action =>
    Assert.Single(action.GetCustomAttributes
  
   ()));

  

这个精确数字有一个有趣的取舍：它既是覆盖证明，也是漂移探测器。新增动作却忘了更新分类或测试，CI 会立刻红；但只要正常新增端点，也必须同步调整基线。因此，数字断言适合安全边界明确、变更需要评审的控制器，不适合到处机械复制。

需要强调：本轮受共享发布锁约束，没有重启 61500/61501，也没有把静态扫描说成生产环境的 104 次授权请求。源码事实、单元测试源码、本地构建、远端发布和生产行为是五层不同证据。

五、把规则做成一个可点的选择题

为了让这套规则不只停在代码块里，我在既有 mci_demo 微服务新增了 /mcp-capability-gate 页面。页面先选访问密钥画像，再选工具动作：

• “只读助手 + 同步应用源码”得到默认拒绝；
• “平台管理员 + 修改角色权限”通过能力检查；
• mcp:admin 是四类能力的超级范围，但不替代菜单、表、行级权限和业务状态机。

这个页面已发布为 mci_demo v0.5.4，公有入口可以直接打开：在线体验四级能力门禁。桌面 1920×1080 与 390px 窄屏都跑过真实浏览器检查，允许/拒绝交互、横向溢出、控制台错误和文字对比度均有单独记录。

它仍然只是一张“规则演示页”：页面没有假装调用生产授权接口，截图证明的是发布物真的可访问、交互真的工作，而不是线上所有账号都已完成渗透测试。

六、超级权限也不是万能钥匙

mcp:admin 可以覆盖四类 MCP 能力，这是为了让可信平台管理员不必携带一长串重复 Scope。但“能进入动作”不等于“业务必然成功”。

进入动作之后，系统仍要继续检查租户、DiyToken、菜单、角色、表权限、数据范围、资源状态和幂等条件。能力范围只解决工具入口的粗粒度授权，不能替代业务内部的细粒度校验。

这也是 Microi吾码AI 场景里值得坚持的边界：AI 可以获得更强的工具，但每一层只负责自己那一段判断。把所有安全责任都塞给一个 Token，最后通常没人说得清它究竟代表身份、角色、租户，还是一张无限通行证。

七、落地时检查这六件事

如果你也在给 Agent、MCP 或自动化工具加授权，可以直接按下面检查：

1. 身份 Token 与动作能力是否分开表达？
2. 能力是否按副作用分类，而不是按页面名字分类？
3. 新端点缺少声明时，是拒绝还是默认放行？
4. 超级范围是否仍受租户和业务权限约束？
5. 是否有静态扫描或测试保证每个动作恰好一个分类？
6. 验收记录是否区分源码、测试、构建、发布物和真实生产行为？

四把钥匙并不会让系统凭空安全，但它把问题从“这个 Agent 好像权限很大”变成了可枚举、可测试、可审计的工程事实。对能读库、改源码、跑任务的 AI 工具来说，这一步很朴素，也很值钱。