MCP 2026 新规范安全迁移：Stateless 后为什么每一次 Tool Call 都必须重新鉴权？

MCP 2026-07-28 移除协议级 Session，每次 Tool Call 成为独立 HTTP POST。本文讲清逐请求鉴权的原因，并提供企业级安全迁移步骤。

摘要： MCP 2026-07-28 规范把 Streamable HTTP 的协议核心改为 Stateless：移除协议级 Session 和独立 GET SSE 流，每条 JSON-RPC 消息都通过单独的 HTTP POST 发送。这个变化并不意味着身份可以缓存到某个旧会话里继续复用；恰恰相反，官方授权规范明确要求每个客户端到服务器的 HTTP 请求都携带授权信息，服务器必须逐请求验证 Token，并确认它是专门签发给当前 MCP Server 的。本文面向 MCP Server 开发者、Agent 平台团队、API Gateway 运维与企业安全人员，解释为什么每一次 tools/call 都必须重新鉴权，给出旧 Session 架构迁移、OAuth 资源绑定、Scope 检查、重放与幂等控制、缓存隔离、灰度兼容及回滚方案。建议所有公开或企业级 HTTP MCP 服务立即开始双协议灰度迁移，但不要在 SDK 尚未稳定时一次性切断旧客户端。

核心结论

MCP 2026-07-28 的 Stateless 设计把每个 Tool Call 变成可独立路由、独立处理的 HTTP 请求，因此认证与授权也必须在该请求自身完成。服务器不能因为同一连接、同一负载均衡节点、旧的 Mcp-Session-Id 或此前成功的调用，就推断当前请求仍然代表同一主体。

Stateless 不等于 Authless： 被移除的是协议级 Session 状态，不是访问控制。官方规范明确写明授权必须包含在客户端到服务器的每个 HTTP 请求中。
认证与授权要逐请求完成： 每次 tools/call 都应验证 Token 的签名或内省结果、有效期、发行者、Audience/Resource、主体与 Scope，再做工具级策略判断。
不能继续信任 Session ID： 2026-07-28 服务器不再签发或回显 Mcp-Session-Id；收到旧 Session Header 时应忽略，而不是把它当身份凭据。
缓存必须按身份隔离： tools/list、资源读取等响应即使可以缓存，也要尊重 cacheScope，包含用户或企业数据的结果不能只按 URL 共享缓存。
迁移建议采用双协议灰度： 先启用版本协商与无状态处理，再把请求状态装入签名的 requestState 或后端状态存储，最后切换鉴权与策略链，保留可观测的旧协议回退窗口。

MCP 2026-07-28 到底改了什么

本次规范变化的核心不是“把 SSE 换成普通 HTTP”这么简单，而是重新定义了请求、状态与长任务的边界。Streamable HTTP 仍然可以对单次请求返回 SSE，但这个流只属于发起它的请求；服务器不再依靠一个长期协议 Session 把多次工具调用串成同一安全上下文。

官方 Streamable HTTP 规范列出的关键变化包括：

删除独立的 GET Stream Endpoint；
删除协议级 Sessions；
每条 JSON-RPC Request 或 Notification 都是新的 HTTP POST；
响应可以是单个 JSON 对象，也可以是仅针对本次请求的 SSE 流；
Server-to-client 的 Sampling、Elicitation、Roots 等交互改用 Multi Round-Trip Requests；
长期变更通知通过 subscriptions/listen 请求的响应流交付；
旧版的 Mcp-Session-Id、HTTP DELETE 终止 Session、Last-Event-ID 重放机制不再属于新版本。

对比项	2025 系列 Streamable HTTP	2026-07-28 Stateless Core	安全迁移影响
初始化	`initialize` 建立能力与会话语境	`server/discover`/版本协商，无状态请求	不能从初始化继承用户身份
Session	可使用 `Mcp-Session-Id`	移除协议级 Session	Session ID 不得作为鉴权依据
Tool Call	可能依赖此前会话上下文	每次调用是独立 POST	每次携带并验证 Token
Server→Client	可通过长期 SSE 发送请求	MRTR 嵌入 `InputRequiredResult`	状态必须显式、可校验
断线恢复	可用 `Last-Event-ID` 恢复	不再支持协议级重放	重新提交新请求并做幂等
缓存	依赖实现约定	结果带 `ttlMs` 与 `cacheScope`	私有响应需按身份隔离
路由	常要求 Session Affinity	可路由到任意兼容实例	每个实例都要完成同等鉴权

“Stateless”最重要的工程含义是：负载均衡器可以把连续两次 tools/call 发到不同实例，实例重启不会丢失协议 Session，边缘节点也能独立处理请求。但这只有在每个请求都携带足够的协议元数据、业务输入和安全上下文时才成立。

每个 Tool Call 都是独立 HTTP POST：先验证 Token，再进行 Audience、Scope 与工具策略检查，最后才进入执行器。

为什么每一次 Tool Call 都必须重新鉴权

首先要区分三个容易混淆的概念：

携带凭据： 客户端在每次请求中发送 Authorization: Bearer <access-token>。
认证验证： 服务器确认 Token 真实、未过期、未撤销，Issuer 与签名可信。
授权决策： 服务器根据 Subject、Audience、Scope、工具名、参数、租户和风险策略，决定是否允许执行。

官方 MCP 2026-07-28 授权规范明确要求授权必须出现在每个客户端到服务器的 HTTP 请求中；MCP Server 作为 OAuth 2.1 Resource Server，还必须验证 Access Token 是为自己这个目标资源签发的。无效或过期 Token 应返回 401，Scope 不足应返回 403。

这意味着“重新鉴权”并不等于每次都让用户重新登录，也不等于每次调用授权服务器。用户交互登录可以发生一次，客户端可以在有效期内复用 Access Token；服务器也可以短时间缓存 JWKS、Token Introspection 或策略结果。但每个请求仍必须经过逻辑验证，不能仅凭连接或历史会话放行。

原因一：HTTP 连接不是身份

HTTP/2、HTTP/3、Keep-Alive 和连接池都会复用连接。反向代理还可能终止 TLS，再用自己的连接池请求后端。同一后端连接上可能承载多个用户；同一用户的连续请求也可能落到不同实例。因此“这个连接刚才通过过验证”不能证明当前请求的身份。

原因二：Token 状态会在调用之间变化

Access Token 可能过期、被撤销、Scope 被收回、用户被禁用，或租户策略刚刚禁止某个高风险工具。如果服务器只在最初连接时验证一次，后续 Tool Call 会绕开这些变化。逐请求验证让系统在策略传播窗口内尽快生效。

原因三：每个工具所需权限不同

tools/list 可能只需 mcp:discover，读取文件需要 files:read，修改仓库需要 repo:write，生产部署可能需要 deploy:prod 和人工审批。2026 规范支持运行时 Scope Challenge：服务器可用 403 和 WWW-Authenticate 告诉客户端当前操作需要的最小 Scope，客户端再执行 Step-Up Authorization。

原因四：Audience 防止 Token 横向复用

Token 对 A MCP Server 有效，不代表它能访问 B MCP Server。客户端请求 Token 时必须使用 RFC 8707 的 resource 参数标明目标，服务器必须验证 Audience/Resource。否则，一个在低敏感服务获得的 Token 可能被拿到财务、代码仓库或云管理 MCP 上尝试复用。

原因五：工具参数会改变风险

同一 filesystem.write 工具，写临时目录和覆盖生产配置的风险不同；同一 sql.query，SELECT 与 DROP 的权限要求也不同。只在 Token 层做粗粒度 Scope 判断不足以覆盖参数级授权，策略引擎还应检查工具参数、资源路径、环境、时间与审批状态。

正确的逐请求安全链应该是什么样

一个生产级 tools/call 请求应按以下顺序处理：

入口协议校验： 验证 HTTPS、Host、Origin、Body 大小、Content-Type、MCP-Protocol-Version、Mcp-Method 和 Mcp-Name。
提取 Bearer Token： 只接受 Authorization Header，不从 URL Query、Cookie 或工具参数读取 Access Token。
验证 Token： 校验签名、exp、nbf、iss、aud/resource；Opaque Token 则调用受信任的 Introspection。
解析安全主体： 建立不可变的 subject、tenant、client_id、scopes 和认证强度上下文。
进行工具级授权： 把主体、Mcp-Name、参数摘要、环境与策略版本送入 OPA、Cedar 或自研 Policy Engine。
检查高风险审批： 删除、付款、发信、发布、修改权限、生产数据库与云变更必须验证短时审批凭据。
建立幂等边界： 写操作要求 Idempotency-Key 或业务唯一键，防止超时重试产生重复副作用。
执行并限制能力： 使用最小权限下游凭据、网络出口白名单、超时、并发与预算限制。
记录审计事件： 记录请求 ID、主体、租户、工具、资源、策略结果、审批、下游副作用 ID 与耗时。
安全响应与缓存： 脱敏输出；私有结果标记为 private，不得被共享 CDN 或跨租户缓存。

下面是一个 Node.js/Express 风格的防御性示例。它说明中间件顺序，不绑定某个 SDK 版本：

app.post(
  "/mcp",
  validateMcpHeaders({
    protocolVersion: "2026-07-28",
    allowedOrigins: ["https://YOUR_AGENT_HOST"],
  }),
  authenticateBearer({
    issuer: "https://YOUR_IDP_DOMAIN",
    audience: "https://YOUR_MCP_DOMAIN/mcp",
    jwksCacheTtlMs: 300_000,
  }),
  async (req, res, next) => {
    const decision = await policyEngine.authorize({
      subject: req.auth.subject,
      tenant: req.auth.tenant,
      scopes: req.auth.scopes,
      method: req.header("Mcp-Method"),
      tool: req.header("Mcp-Name"),
      arguments: req.body?.params?.arguments,
    });

    if (!decision.allowed) {
      return res.status(decision.reason === "insufficient_scope" ? 403 : 401).json({
        error: decision.reason,
      });
    }
    return next();
  },
  idempotencyGuard(),
  mcpRequestHandler(),
);

这里可以缓存 JWKS 公钥，但不能缓存“这个 Socket 已登录”；可以短时缓存 Token 验证结果，但缓存键必须包含 Token 哈希、Issuer、Audience 与策略版本，并且缓存 TTL 不能超过 Token 剩余有效期。

OAuth 资源绑定与 Scope 设计

2026 规范进一步强化了 OAuth/OIDC 的企业兼容性。客户端必须在授权请求和 Token 请求中携带 resource，使用 MCP Server 的 Canonical URI，例如：

resource=https://YOUR_MCP_DOMAIN/mcp

MCP Server 验证 Token 时要确认自己是目标 Audience。网关位于 MCP Server 前面时，不应把面向网关的外部 Token 原样透传给下游 SaaS 或另一个 MCP Server；应使用 Token Exchange、On-Behalf-Of、服务身份或独立的上游 Token。这样才能避免 Confused Deputy 和跨服务 Token 滥用。

Scope 不宜设计成一个万能的 mcp:all。推荐拆成“能力 + 资源 + 风险级别”：

操作	建议 Scope	附加策略
工具发现	`mcp:tools:list`	按租户过滤工具清单
只读检索	`docs:read`	限制知识库与数据标签
仓库读取	`repo:read`	限定组织与仓库
创建 PR	`repo:pr:create`	禁止直接合并
发送消息	`message:send`	预览 + 人工确认
生产部署	`deploy:prod`	短时 Step-Up + 双人审批
权限修改	`iam:write`	默认不向通用 Agent 开放

当某次 Tool Call Scope 不足时，服务器应返回 403 和 WWW-Authenticate: Bearer error="insufficient_scope"，同时一次性列出本次操作需要的 Scope，避免客户端多轮猜权限。客户端取得升级 Token 后，必须把原请求作为新的请求重试，并重新完成全部验证。

更多权限治理思路可参考 AI Stack Nav 的 MCP 权限与安全文章，企业 Agent 平台还可结合 AI Agent 治理教程建立统一审批与审计层。

从 Stateful MCP 迁移到 Stateless 的 12 个步骤

迁移目标不是删掉 Session Map 后让所有逻辑失去状态，而是把状态分成三类：身份状态由 Token 携带或实时解析；业务状态放到显式后端；多轮请求状态使用签名、限时、可验证的 requestState。

盘点协议版本。 记录客户端、服务器、SDK、代理和 Inspector 支持的 MCP 版本，区分 2025-era 与 2026-07-28。
绘制 Session 依赖。 搜索 Mcp-Session-Id、内存 Session Map、Sticky Session、连接级 User Context、GET SSE 与 Last-Event-ID。
建立版本协商。 客户端先用 server/discover 探测现代协议，不支持时回退到 2025 初始化流程；生产初期不要默认强制 Pin。
改造单请求上下文。 每个 POST 从 Header、Body _meta 和已验证 Token 构造 Request Context，不读取上一次请求的用户对象。
迁移认证中间件。 把认证放在 MCP Handler 之前，覆盖 tools/list、tools/call、资源、提示词、订阅与扩展端点。
实现 Audience 与 Issuer 校验。 为每个 MCP Server 配置 Canonical Resource URI，拒绝为其他服务签发的 Token。
拆分 Scope。 从全局角色迁移为操作级 Scope 和策略；高风险 Tool Call 使用 Step-Up。
外置业务状态。 长任务、审批、游标和工作流状态放入 PostgreSQL、Redis 或任务系统，键中包含租户与主体边界。
实现 MRTR/requestState。 对需要 Sampling、Elicitation 或 Roots 的多轮调用，使用签名且短期有效的状态载荷，防篡改、防跨用户复用。
补充幂等与重试。 断流后必须以新 Request ID 重发；写操作同时带幂等键，服务器保存副作用结果。
双协议灰度。 对一小部分客户端启用 2026 版本，比较 401/403、P95 延迟、工具成功率、重复副作用和跨实例一致性。
移除会话信任。 确认所有实例都能独立处理请求后，关闭 Sticky Session 和基于 Session ID 的鉴权，但保留旧协议兼容端点到公告期限。

TypeScript SDK 的官方迁移文档提醒：支持 2026-07-28 是显式 Opt-in，不能假设升级包版本就自动在 Wire 上切换新协议。客户端可使用自动版本协商，也可 Pin 新版；Pin 模式遇到只支持 2025 的服务器会直接失败。迁移计划应分别验证“SDK 已安装”“功能已启用”“线上的实际协议版本”。

从资产盘点、版本协商和逐请求鉴权，到状态外置、幂等、灰度与会话信任下线的迁移闭环。

requestState、重放与幂等：无状态不等于无业务状态

多轮交互仍然需要状态。例如工具执行到一半需要用户确认，服务器返回 InputRequiredResult；客户端收集答案后重试原请求，并携带 inputResponses 与 requestState。安全实现需要保证：

requestState 使用服务器密钥签名或仅保存不可猜测的后端引用；
包含 Subject、Tenant、Tool、参数摘要、创建时间、过期时间和一次性 Nonce；
后续请求重新鉴权后，Token 的 Subject 与 Tenant 必须和状态绑定值一致；
高风险审批状态不能转移给另一个用户或 Client ID；
状态过期、签名失败或工具参数发生变化时拒绝继续；
已完成的一次性状态进入 Used 集合，防止 Replay。

断开的 SSE 流不再用 Last-Event-ID 恢复。客户端应生成新的 JSON-RPC Request ID 重新发起；这会带来“第一次其实成功、响应却丢失”的经典不确定性。对写操作，Request ID 本身不一定适合作为长期业务幂等键，建议客户端额外提供稳定的业务 Key：

{
  "jsonrpc": "2.0",
  "id": "request-new-002",
  "method": "tools/call",
  "params": {
    "name": "create_ticket",
    "arguments": {
      "title": "YOUR_TICKET_TITLE",
      "idempotency_key": "YOUR_STABLE_OPERATION_ID"
    }
  }
}

服务器应把幂等结果与主体、租户、工具和参数摘要绑定。如果攻击者拿到别人的 Idempotency Key，也不能读取其结果或改变原操作。

缓存、网关与多租户陷阱

2026 规范让 MCP 更适合 CDN、Serverless 与普通 HTTP 基础设施，但缓存也是最容易造成跨租户泄露的地方。规范为部分结果引入 ttlMs 与 cacheScope；实现时还应配置标准 HTTP Cache Header。

私有结果不能只按 URL 缓存

所有 Tool Call 都发往类似 POST /mcp 的同一地址。如果 CDN 只把 URL 当缓存键，A 用户的结果可能返回给 B 用户。包含身份、租户、内部工具清单或私有资源的结果应标记 cacheScope: "private"，通常配合 Cache-Control: private, no-store。即使缓存，也至少按主体、租户、Scope、工具、参数摘要与策略版本隔离。

API Gateway 不能只验一次连接

Gateway 可以负责 Token 验证，但必须把经过签名或受信网络保护的身份上下文传给后端。后端不能相信客户端可直接提交的 X-User、X-Tenant。推荐由 Gateway 删除所有外部身份 Header，再写入内部 Header，并使用 mTLS 或工作负载身份保护 Gateway 到 MCP Server 的链路。

Serverless 冷启动不应降低安全

为了减少延迟，可以缓存 JWKS 和策略 Bundle，也可在边缘验证 JWT；但不能在 IdP 暂时不可用时自动“先放行再补验证”。JWKS 刷新要处理 Key Rotation：未知 kid 可触发一次受限刷新，刷新失败则 Fail Closed。

成本、性能与可观测性

逐请求鉴权会增加 CPU、网络和延迟，但不等于每个请求都访问 IdP：

方案	延迟与成本	撤销实时性	适用场景
本地 JWT + 缓存 JWKS	低	受 Token TTL 限制	高频 Tool Call
Opaque Token Introspection	中到高	较强	高风险、集中控制
Gateway 验证 + 签名身份上下文	中	取决于网关	大规模多服务
每请求远程策略决策	中到高	强	高风险细粒度授权
本地策略 Bundle	低	取决于同步间隔	低延迟边缘部署

监控至少覆盖：

401、403 与 insufficient_scope 比例；
Token 验证耗时、JWKS 刷新失败、Introspection 超时；
Audience/Issuer 不匹配和过期 Token；
每个 Subject/Client 的 Tool Call 频率与异常参数；
幂等命中、重复副作用、SSE 断流重试；
跨实例结果一致性；
新旧协议协商与回退比例；
高风险工具的审批通过、拒绝和过期。

日志不得记录完整 Access Token、Refresh Token 或敏感工具参数。可保存 Token 指纹、jti 哈希、Subject、Issuer、Audience、Scope 集合和策略版本，满足审计又降低泄露风险。

Prompt Injection 与授权的关系

逐请求鉴权不能解决 Prompt Injection，但能限制 Prompt Injection 造成的能力滥用。模型可能被恶意文档诱导调用 send_email 或 delete_record；服务器必须把模型输出视为不可信请求，执行结构化参数校验和策略判断。

尤其要避免把用户拥有的全部权限自动授予 Agent。更稳妥的设计是：

Agent 使用独立 OAuth Client 与可识别的 client_id；
Token Scope 只覆盖当前任务；
高风险调用需要一次性 Approval Token；
Approval Token 绑定 Tool、参数摘要、用户和有效期；
工具执行器使用最小权限服务身份；
数据输出经过 DLP 与租户边界检查。

删除、付款、发布、发邮件、修改账户、修改权限和生产数据库操作都应设置人工审批或独立权限隔离。即使 Token 合法，也不代表模型的每个决定都值得自动执行。

兼容、失败与回滚策略

迁移期间常见故障并非“鉴权全坏了”，而是协议、Header 和策略组合不一致：

缺少 MCP-Protocol-Version 或 Body _meta 不一致，应返回 400；
客户端仍发送 Mcp-Session-Id，新版服务器会忽略；
旧客户端尝试 GET/DELETE，新版端点应返回 405；
Token 正确但 Audience 指向 Gateway 根域而不是具体 MCP Resource，返回 401；
Token 有效但 Scope 不足，返回 403，而不是触发无限刷新；
代理丢弃 Mcp-Method 或 Mcp-Name，导致策略无法判定；
CDN 缓存 POST 私有响应，产生跨租户风险。

回滚不能恢复“仅首次连接鉴权”的旧做法。若新版协议出现兼容问题，可让客户端通过版本协商回退到 2025 传输，但授权中间件仍应逐请求验证 HTTP 凭据。把传输协议回滚和安全控制回滚分离，才能避免为了可用性重新打开身份漏洞。

事实依据与来源

官方已确认事实： MCP 2026-07-28 已正式发布；Streamable HTTP 移除了协议级 Session 和 GET Stream，每条 JSON-RPC 消息成为独立 POST。
官方授权要求： MCP 客户端必须在每个 HTTP 请求中包含授权；服务器必须验证 Token，并确认它为当前 MCP Server/Audience 签发。无效或过期 Token返回 401，Scope 不足返回 403。
官方安全要求： Streamable HTTP Server 必须验证 Origin；本地运行建议只监听 localhost；授权安全指南要求禁止 Token Passthrough，并使用 Resource Indicators 绑定目标资源。
官方 SDK 现状： TypeScript SDK v2 的 2026-07-28 支持需要显式启用，默认仍可按旧时代行为运行；因此本文建议验证线上 Wire Version，而非只检查依赖版本。
编辑判断： “每一次 Tool Call 都必须重新鉴权”在本文指每次独立请求都经过凭据和策略验证，不指每次要求用户交互登录，也不要求每次都远程访问 IdP。
实施建议： 双协议灰度、Gateway 签名上下文、幂等键、状态绑定、缓存隔离和人工审批属于工程落地建议，需要结合企业 IdP、SDK 与风险模型验证。
尚需项目实测： 各官方 SDK 对 2026-07-28 的稳定版本、默认开关与迁移 API 可能继续变化，应以所用语言 SDK 的最新发布说明为准。

本文内容核验日期：2026 年 9 月 23 日。

FAQ

Q1：Stateless 是否意味着 MCP Server 不再需要登录？

不是。Stateless 只表示协议不依赖服务器保存的会话来理解下一次请求。受保护的 HTTP MCP Server 仍需授权，每个请求都要携带并验证 Access Token。

Q2：每次 Tool Call 重新鉴权，会不会每次弹出登录页面？

不会。客户端可以在 Token 有效期内安全复用 Access Token，并在需要时用 Refresh Token 更新。服务器逐请求验证 Token，不等于用户逐请求交互登录；只有权限不足需要 Step-Up 时才可能提示用户。

Q3：可以继续使用 Mcp-Session-Id 作为用户身份吗？

不可以。2026-07-28 已移除协议级 Session，新版服务器应忽略 Mcp-Session-Id。即使为了旧协议兼容保留 Session，它也只能辅助传输状态，不能代替 Access Token 和工具级授权。

Q4：JWT 每次验证会不会拖慢 Tool Call？

本地验证 JWT 通常可通过缓存 JWKS 控制成本，不必每次连接 IdP。应测量 P95/P99，并让缓存 TTL 不超过安全边界；未知 Key、过期 Token 或 Audience 不匹配必须 Fail Closed。

Q5：Token 已经有效，为什么还要检查 Scope？

Token 有效只证明它来自可信发行方且仍在有效期内，不证明它有权调用当前工具。不同工具和参数需要不同权限，高风险调用还可能要求 Step-Up 或人工审批。

Q6：MCP Gateway 已经验证 Token，后端还需要验证吗？

可以由可信 Gateway 集中完成密码学验证，但后端必须验证 Gateway 身份与其签名的安全上下文，并继续做工具级授权。客户端能够直接访问后端或伪造身份 Header 时，集中验证就失去意义。

Q7：Stateless 后多轮 Elicitation 的状态放在哪里？

可以放在签名、短期有效且绑定主体的 requestState 中，或放在数据库/Redis 并只返回不可猜测引用。后续每次请求仍先重新鉴权，再确认当前主体与状态所有者一致。

Q8：旧客户端不支持 2026-07-28，是否必须立即停用？

不必一次性停用。建议使用版本协商和双协议灰度，统计回退比例并推动升级。兼容旧传输期间仍应保留逐请求身份验证、最小权限和审计，不能为了兼容恢复连接级信任。

参考来源

内容核验日期：2026 年 9 月 23 日

工具评测文章

工具选型与提示词资料

适合阅读工具评测、工具推荐、对比测评类文章后继续转化。

工具选型表 按场景、价格、上手难度和核心能力筛选合适的 AI 工具。 查看资料包 提示词模板包 提供写作、运营、编程、图片和视频生成常用提示词模板。 查看资料包

AI Stack Nav

MCP 2026 新规范安全迁移：Stateless 后为什么每一次 Tool Call 都必须重新鉴权？

核心结论

MCP 2026-07-28 到底改了什么

为什么每一次 Tool Call 都必须重新鉴权

原因一：HTTP 连接不是身份

原因二：Token 状态会在调用之间变化

原因三：每个工具所需权限不同

原因四：Audience 防止 Token 横向复用

原因五：工具参数会改变风险

正确的逐请求安全链应该是什么样

OAuth 资源绑定与 Scope 设计

从 Stateful MCP 迁移到 Stateless 的 12 个步骤

requestState、重放与幂等：无状态不等于无业务状态

缓存、网关与多租户陷阱

私有结果不能只按 URL 缓存

API Gateway 不能只验一次连接

Serverless 冷启动不应降低安全

成本、性能与可观测性

Prompt Injection 与授权的关系

兼容、失败与回滚策略

事实依据与来源

FAQ

Q1：Stateless 是否意味着 MCP Server 不再需要登录？

Q2：每次 Tool Call 重新鉴权，会不会每次弹出登录页面？

Q3：可以继续使用 Mcp-Session-Id 作为用户身份吗？

Q4：JWT 每次验证会不会拖慢 Tool Call？

Q5：Token 已经有效，为什么还要检查 Scope？

Q6：MCP Gateway 已经验证 Token，后端还需要验证吗？

Q7：Stateless 后多轮 Elicitation 的状态放在哪里？

Q8：旧客户端不支持 2026-07-28，是否必须立即停用？

参考来源

工具选型与提示词资料

最新文章

热门文章

标签云

AI Stack Nav

发表回复取消回复

MCP 2026 新规范安全迁移：Stateless 后为什么每一次 Tool Call 都必须重新鉴权？

核心结论

MCP 2026-07-28 到底改了什么

为什么每一次 Tool Call 都必须重新鉴权

原因一：HTTP 连接不是身份

原因二：Token 状态会在调用之间变化

原因三：每个工具所需权限不同

原因四：Audience 防止 Token 横向复用

原因五：工具参数会改变风险

正确的逐请求安全链应该是什么样

OAuth 资源绑定与 Scope 设计

从 Stateful MCP 迁移到 Stateless 的 12 个步骤

requestState、重放与幂等：无状态不等于无业务状态

缓存、网关与多租户陷阱

私有结果不能只按 URL 缓存

API Gateway 不能只验一次连接

Serverless 冷启动不应降低安全

成本、性能与可观测性

Prompt Injection 与授权的关系

兼容、失败与回滚策略

事实依据与来源

FAQ

Q1：Stateless 是否意味着 MCP Server 不再需要登录？

Q2：每次 Tool Call 重新鉴权，会不会每次弹出登录页面？

Q3：可以继续使用 Mcp-Session-Id 作为用户身份吗？

Q4：JWT 每次验证会不会拖慢 Tool Call？

Q5：Token 已经有效，为什么还要检查 Scope？

Q6：MCP Gateway 已经验证 Token，后端还需要验证吗？

Q7：Stateless 后多轮 Elicitation 的状态放在哪里？

Q8：旧客户端不支持 2026-07-28，是否必须立即停用？

参考来源

工具选型与提示词资料

最新文章

热门文章

标签云

AI Stack Nav

发表回复 取消回复

发表回复取消回复