MCP撤销不是瞬时事件：JWT、工具发现与在途请求
MCP撤销不是瞬时事件：JWT、工具发现与在途请求
核心结论与用户价值
知识轴：MCP Gateway / harness-runtime / sandbox-security。 控制台移除角色，不等于旧token失效；工具从tools/list消失，不等于按已知名字调用会被阻止；新调用被拒绝，也不等于在途请求被取消。MCP-Gateway-Runtime的撤销验收应以真实请求时间和凭据版本为锚，而不是只看最新配置。
这直接适用于Hermes的工具registry和联邦网关：agent可能缓存旧工具schema、持有旧JWT，网关还可能向下游传递另一份短期授权证明。用户看到“已撤销”时，需要明确撤掉的是哪一层、何时开始对哪个请求生效。
来源与读取边界
依据Red Hat Connectivity Link 1.3官方“Revoking MCP server tool access”章节，09-24读取；没有独立确认文章发布日期，不称今日release。本轮web_extract成功取得正文；独立requests GET仍为403，已将失败响应和成功提取的精选原文分开归档，不把403 HTML冒充原文。未连接集群、未执行oc、未配置真实Keycloak或AuthPolicy。
机制一：撤销先改发证规则，已有JWT仍携带旧权限
文档方案将tool权限映射到身份提供方JWT的角色。移除用户/组角色后，新认证得到不含该角色的token，后续请求被拒绝；既有token仍可用到过期。缩短access-token lifespan可缩短这个窗口，但增加刷新开销；不能把“修改角色成功”报为“当前所有会话已禁用”。
文档明确：已经被处理的tools/call正常完成，因为授权检查在进入backend之前发生。若业务要求撤销后不能再提交最终副作用，需要另加提交时验权或可中断执行机制；这是对当前方案的工程要求，不是声称文档已实现。相关机制见continuity-security-context-contracts-and-finality。
机制二：调用门与发现过滤是两条独立路径
| 路径 | 本方案的判断点 | 易误读处 |
tools/call | AuthPolicy CEL将x-mcp-toolname与token内resource_access角色比对 | 工具调用被挡不说明工具列表同步刷新；可信工具名header与实际请求应由gateway绑定 |
tools/list | broker消费签名x-authorized-tools以过滤可见列表 | 没配置这个环节时，已禁止调用的工具仍会显示 |
| 已在backend执行的请求 | 进入前已完成授权 | 此撤销方案不回滚或终止它 |
章节前部描述启用signed-header后的过滤结果；后面的操作步骤解释仅改IdP角色时工具仍显示，需另配置broker过滤。两段应按配置前提读，不把它们简化成同配置下的逻辑矛盾。
机制三：签名权限header又引入一层配置/时间边界
示例由Authorino用ES256生成wristband JWT，包含allowed-tools，tokenDuration: 300；broker装载公钥验证。300是该示例signed-header token的有效期，不是用户access-token寿命，也不是端到端撤销SLA。 broker加载密钥还涉及Secret与自动redeploy；配置写入、实际reload、出站授权和客户端缓存必须分别观察。
示例的“删除旧AuthPolicy再创建，不能只apply合并”是该配置转换的维护说明，不能无条件推广为生产操作。本文只归纳机制，未自动修改任何policy。
可执行验收矩阵
以下是推荐的隔离测试设计，并非本轮执行结果：
- 撤销前保留旧token、工具列表版本和一个无危险副作用的慢请求；记录请求开始/授权决定时间。
- 撤销角色后，用旧token与新token分别执行
tools/list和按已知名字直接tools/call，分别记录拒绝、列表过滤与backend回执。 - 旧token到期、broker密钥reload、客户端重新发现后逐步复测。保留
issuer / subject / audience / exp / policy_version / tool_name / request_id / decision_time，不记录明文token。 - 若要求硬停止，增加在途撤销/提交时验权用例，明确已经提交的副作用如何处理。跨网关联邦还需逐hop核授权责任，不因入口撤销而假定下游已同步。
文档示例有500/session错误包装；自动化验收应结合授权decision和backend是否执行，不用“HTTP必须403”替代业务事实。与litellm-auth-fallback-and-gateway-blast-radius一致，认证入口、目标集合和实际backend都应绑定；与Agent-Benchmarks一致，每个结论都必须对应其配置和证据层。
边界与未解问题
本章不是所有MCP网关的通用保证，也没有证明本用户环境存在旧token风险。短寿命JWT不能自动解决所有撤销需求：token交换、header缓存、broker reload、长连接与在途动作仍须测量。后续最有价值的增量是同一任务跨两个gateway时的撤销时间线与最终副作用，而非再增加一个“支持RBAC”的工具介绍。
写入记录
- 2026-09-24 09:14 CST：补入官方1.3撤销机制，拆分旧/新token、发现/调用、signed-header与在途请求；明确正文提取成功和直接HTTP403的证据差异，未做集群E2E。