把工具授权拆成两道门
MCP 让智能体调用外部工具变得顺手，但也把一个新的难题摆到台面：当一个能力被暴露给智能体，到底算「看见了」还是算「被批准用」？10 月 20 日，云安全联盟发布一份分析，提出一个双门授权模型来回答这个问题。前置门叫「能力准入」，决定该不该把一个能力暴露给某个智能体，做法是最小能力优先，先筛掉不该出现的工具；后置门叫「执行授权」，决定这一次具体的调用对不对，由模型之外的一个可信执行点，对着具体资源来把关。
这个模型的关键，是点破了行业里一个常见的误判：很多人把 MCP 的工具发现（tools/list）当成了安全闸，以为「智能体能发现这个工具」就等于「它可以用」。但工具发现只是一份清单，不是授权边界；更糟的是，如果服务器访问和工具访问塌缩成同一件事，一个被暴露的服务器就可能顺手把不该碰的资源也交出去。双门模型主张把两者分开：先收口能力面，再把把关点移到模型之外，授权要看智能体、负载、来源、操作、资源、上下文这六类信号，而不只是一张有效的访问令牌。
暴露不等于授权
落到设计上，这意味着「暴露一个能力」和「批准一次调用」必须是两件事，不能混为一谈。能力准入负责收窄每个智能体能看到的世界，执行授权负责在每次动作发生时做实时裁决，而且这个裁决点要独立于模型——模型自己不该既当运动员又当裁判。云安全联盟把这份分析定位成配套参考，和 OWASP 的过度授权指南对齐，本身不是已发布的规范，更像是给后续标准化铺路的一块界碑。
对正在把 MCP 服务器接进智能体的团队，这份模型的实用价值在于它把一句空话变成了可操作的动作：先列清楚每个智能体该暴露哪些工具、不该暴露哪些，再把后果严重的调用交给模型之外的执行点按资源逐一核准。过去几个月的 MCP 安全事件已经反复证明，规范本身缺了 normative 的安全要求，漏洞就会在一家家服务器里被一遍遍重新发现；双门模型不一定终结这个问题，但它至少把「授权」这件常被忽略的事，摆到了和「连接」同等重要的位置。