MCP 工具调用需要逐次授权

MCP 登录成功，只能证明用户是谁，不能证明 Agent 接下来做的每件事都被允许。作者提出的补法是：为每次 Agent 运行分配身份，并在每次工具调用时，结合用户、工具和参数重新判断权限。

这套思路值得程序员读几分钟，因为风险经常藏在参数里：同一个数据库工具，查数据和删表可能只有一段 SQL 的区别。不过，原文给的是架构建议，没有实测数据，作者也来自 MCP 网关厂商，需要把技术原则和产品主张分开看。

登录管身份，每次调用还得单独授权

原文首先区分了认证（authentication）和授权（authorization）。认证回答「你是谁」，授权回答「你现在能做什么」。一次指令可能触发数百次工具调用，如果只在登录时检查权限，后续调用就会一直继承最初的放行决定。

作者引用的是 2026-07-28 版本的 MCP authorization spec，讨论范围是远程 HTTP MCP server：服务器作为 OAuth 2.1 resource server，负责验证 token，不负责签发。

客户端没有 token 时，服务器返回 401，并指向 Protected Resource Metadata（RFC 9728），让客户端找到授权服务器。客户端通过 PKCE 完成用户登录，再通过 resource 参数（RFC 8707）申请绑定目标服务器的 token。发给服务器 A 的 token，不应该被服务器 B 接受。

还有一条边界不能省：MCP server 不应把客户端 token 直接透传给上游 API。上游若接受了并非签发给自己的 token，就会出现 confused-deputy，也就是服务被借用自身能力，替调用方完成越权操作。

这些 OAuth 流程不适用于本地 stdio server；原文说，后者从环境中获取凭据。两类部署不能直接照搬同一套登录方案。

为什么同一个用户的 Agent 也要分开管理

假设 Jane 同时使用 Claude Code、Cursor 和 cron 脚本，三者都拿 Jane 的 token，日志只能记录「Jane 做了什么」。脚本出现异常时，也很难只撤销脚本的权限。

作者建议，每次调用都携带两种身份：委托任务的用户，以及实际执行任务的 Agent 实例。后者可以具体到「这台机器上、9:02 启动的这次 Claude Code 会话」。

实现上，MCP server 看到的 token 以用户为 subject，再用独立 claim 表示 Agent 实例，例如 actor 或 client/instance ID。这样才能单独撤销一次运行，同时保留用户及其他 Agent 的访问权。审计也能从「Jane 删除了 40 行」细化为「Jane 的 Cursor 会话删除了 40 行」。

这里的关键是区分一次次运行，仅记录产品名还不够。原文没有展开实例身份如何签发、验证和防止冒用，这是落地时需要补齐的部分。

参数决定风险，网关负责统一执行规则

只按工具名称控制权限，往往无法限制具体操作对象和范围。Support 角色可以使用 crm.update_record，不代表它可以修改任意客户的数据。用户拥有的工单与从未接触过的客户 account_id，应该得到不同的判断。

因此，授权决策要同时看到用户、Agent、目标服务器、工具和参数。原文用下面的伪策略表达这个思路：

allow: tool: github.create_pull_request when: repo in user.repos

deny: tool: github.delete_repository # destructive: never via an agent

allow: tool: db.query when: args.sql starts_with "SELECT"

第一行把创建 PR 限制在用户有权访问的仓库，第二行直接禁止 Agent 删除仓库。第三行尤其需要谨慎：它只是示意，不能把 SQL 以 SELECT 开头当成完整的安全校验。

作者还提出两个配套动作。其一是默认拒绝：没有匹配到 allow 规则就拦截，新增工具不会自动获得权限。其二是过滤工具列表：用户无权调用的 delete_repository，也不展示给 Agent。过滤能减少模型误选，但服务端仍须逐次校验。

凭据与审计也属于同一条执行链。作者主张使用按用户、按服务器划分的短期 token，让 Agent 不持有长期 API key；访问 GitHub、Salesforce 等上游时，继续受用户已有权限约束。所有授权决定都要记录，包括拒绝，因为失败尝试同样能暴露 Agent 的行为。

这些逻辑可以写进每台 MCP server。作者认为，一两台服务器尚可，到了不同团队维护的二十台，统一 MCP gateway 更便于管理：Agent 连接一个入口，由网关接入公司现有 IdP、附加实例身份、检查调用、记录审计，再转发获准请求。

我的判断

把授权检查推进到参数层，是这篇最有价值的建议。 工具名只能说明能力类型，参数才决定具体操作对象和影响范围。默认拒绝、短期凭据、记录拒绝原因，也都适合成为权限设计的基本要求。

但参数检查不是加几条字符串规则就结束了。repo in user.repos 依赖准确的仓库权限信息，account_id 检查依赖业务归属数据。原文没有交代这些数据如何获取、更新，以及查询失败时如何处理。

网关则是集中管理的取舍。相比逐个服务器实现，它能减少重复建设，但也增加了一个需要维护和保护的统一入口。作者没有提供延迟、故障影响或维护成本的对照数据，「二十台服务器需要网关」应视为经验判断。

作者任职于 SecureAuth，并参与 Agent Authority 的建设。文中的选型问题有参考价值，但不能据此认定该产品已经证明了方案效果。文章也没有给出可运行实现或安全测试结果。

能拿来做什么

• 给现有 MCP 工具按参数梳理权限边界。例如 GitHub 创建 PR 要检查仓库归属，CRM 更新要检查目标客户，数据库工具要明确允许的操作范围。
• 在 Node MCP 服务的调用处理链中设置统一授权入口，让未匹配 allow 规则的请求默认失败，并同步过滤对 Agent 展示的工具列表。
• 为每次 Agent 运行记录独立实例身份，验证能否只撤销一个 Cursor 会话或 cron 脚本，同时在审计中保留用户、实例和拒绝规则。
• 评估 MCP gateway 时，要求演示参数级拦截、单实例撤销和拒绝日志，再结合服务器数量与团队分工决定是否引入。