The biggest MCP spec update ships July 28: What changes for AI agent authentication
- source_url: https://workos.com/blog/mcp-2026-spec-agent-authentication
- source_type: article
- platform: blog
- author: WorkOS
- original_date: 2026-07-20
- added_date: 2026-07-20
- local_path: OpenClaw定时任务/ClawFeed24小时高价值一览/2026-07-20-ClawFeed24小时高价值一览.md
- quality_score: 4
摘要（中文）
文章把 MCP 2026-07-28 release candidate 的破坏性变化翻成迁移清单：协议层去掉隐藏 session，每个请求携带版本和能力信息；授权对齐 OAuth 2.1Protected Resource MetadataResource Indicators 和 issuer verification；需要状态的应用改用显式 handle这些变化让 MCP server 更适合生产网关治理和多服务部署
Summary (English)
The article summarizes MCP 2026-07-28 release-candidate changes around stateless requests, server discovery and OAuth-aligned authorization for production AI agent authentication.
One-liner
MCP 新规范的方向是少隐藏 session，多显式状态标准授权和网关可治理性
原文 / 元数据抓取
The biggest MCP spec update ships July 28: What changes for AI agent authentication
原文链接: https://workos.com/blog/mcp-2026-spec-agent-authentication
In this article
- [
Introduction
](#introduction)
- [
The protocol goes stateless
](#the-protocol-goes-stateless)
- [
Authorization gets real
](#authorization-gets-real)
- [
Extensions become first-class
](#extensions-become-first-class)
- [
What's deprecated
](#what-s-deprecated)
- [
What you need to do before July 28
](#what-you-need-to-do-before-july-28)
- [
What this means for agent security
](#what-this-means-for-agent-security)
- [
Securing AI agents and MCP servers with WorkOS
](#securing-ai-agents-and-mcp-servers-with-workos)
June 18, 2026
June 18, 2026
The biggest MCP spec update ships July 28: What changes for AI agent authentication
The MCP 2026-07-28 release candidate rewrites the protocol's foundation. Here's what's changing, what's breaking, and what your team needs to do before the final spec lands.
Maria Paktiti
June 18, 2026
Explore with AI
[
Open in ChatGPT
Open in Claude
Open in Perplexity
On May 21, 2026, the Model Context Protocol's lead maintainers published the release candidate for MCP `2026-07-28`. They called it "the largest revision of the protocol since launch." That's not marketing language. The spec removes sessions, drops the initialization handshake, deprecates three core features, rewrites how authorization works, and introduces a framework for extensions that will shape how the protocol evolves from here.
The final specification ships on July 28, 2026. The ten-week window between the release candidate and the final spec is for SDK maintainers and server implementers to validate the changes against real workloads. If you're running MCP servers in production, that window is your migration timeline.
This article covers what's actually changing, verified against the official release candidate blog post and the draft specification. It focuses on the changes that matter most for teams building and securing agentic applications: the shift to a stateless core, the authorization hardening, and what you need to update before July 28.
The protocol goes stateless
The headline change is that MCP no longer manages sessions at the protocol layer. Six Specification Enhancement Proposals (SEPs) work together to remove the session model that the 2025-11-25 spec was built on.
The initialize/initialized handshake is gone. In the previous spec, every MCP connection started with a two-step handshake where the client and server exchanged protocol versions, capabilities, and identity information. In 2026-07-28, that handshake is removed entirely (SEP-2575). The protocol version, client info, and client capabilities now travel in _meta on every request. A new server/discover method lets clients fetch server capabilities on demand rather than up front.
The Mcp-Session-Id header is gone. The protocol-level session that pinned a client to a specific server instance is removed (SEP-2567). This is the change with the biggest operational impact. In the previous spec, a remote MCP server needed sticky sessions, a shared session store, and deep packet inspection at the gateway to route requests to the right instance. In 2026-07-28, any server instance can handle any request.
The practical result: an MCP server can now run behind a plain round-robin load balancer. No sticky routing, no shared session store. The server routes traffic using the new Mcp-Method and Mcp-Name headers (SEP-2243) and can let clients cache tools/list responses for as long as the server's ttlMs permits.
Stateless protocol, stateful applications. Removing the protocol-level session doesn't mean your application has to be stateless. Servers that need to carry state across calls can mint explicit handles (a basket_id, a browser_id) from a tool and have the model pass that handle back as an ordinary argument on later calls. As the release candidate blog post notes, this pattern is often more powerful than hidden session state because the model can reason about the handles, compose them across tools, and hand them off between steps.
Authorization gets real
The previous MCP spec's approach to auth was, charitably, "bring your own token." The 2026-07-28 spec aligns MCP authorization with OAuth 2.1 and OpenID Connect in ways that make it meaningfully enterprise-ready.
- MCP servers are now formally **OAuth 2.1** resource servers. This was introduced in the
2025-11-25spec but2026-07-28tightens it considerably. MCP servers MUST implement OAuth 2.0 Protected Resource Metadata (RFC 9728) so clients can discover the correct authorization server automatically. MCP clients MUST implement Resource Indicators (RFC 8707) to explicitly specify which MCP server a token is intended for, preventing a malicious server from obtaining tokens meant for a different server. - **Client ID Metadata Documents** replace **Dynamic Client Registration**. The spec now recommends OAuth Client ID Metadata Documents (CIMD) as the preferred method for client registration. Dynamic Client Registration (RFC 7591) is deprecated and retained only for backward compatibility with authorization servers that don't support CIMD yet.
- Issuer verification is now required. Clients must validate which authorization server issued an authorization response (based on RFC 9207) and must bind registered credentials to the issuing authorization server's issuer. If a resource migrates between authorization servers, the client must re-register (SEP-2352). This prevents a class of mix-up attacks that were possible when one client talks to many MCP servers, which is exactly the deployment pattern MCP encourages.
- Refresh token handling is formalized. The spec now documents how to request refresh tokens from OpenID Connect-style authorization servers (SEP-2207) and clarifies scope accumulation during step-up authorization (SEP-2350). In the previous spec, refresh token behavior was undefined, which meant every implementation handled it differently.
- Application type declaration during registration. Clients now declare their OpenID Connect
application_typeduring registration (SEP-837), which solves a common failure mode where an authorization server defaults a desktop or CLI client to "web" and then rejects its localhost redirect URI.
The cumulative effect of these changes is that MCP authorization goes from "technically possible if you wire everything up yourself" to "follow these RFCs and it works." For teams running MCP servers behind enterprise identity providers (Okta, Azure AD, Google Workspace), the path from "unauthenticated MCP server" to "properly secured MCP server" is now defined at the spec level rather than left as an exercise.
Extensions become first-class
The 2026-07-28 spec introduces a formal extensions framework. Extensions get reverse-DNS identifiers, their own repositories, delegated maintainers, and versions that move independently from the main spec. Clients and servers negotiate extension support through an extensions map in their capabilities.
Two extensions ship with the release candidate:
- **MCP Apps** let servers render interactive HTML UIs directly in the client. The rendered UI communicates back to the host over the same JSON-RPC protocol used everywhere else in MCP, which means every UI-initiated action goes through the same audit and consent path as a direct tool call. This is the primitive that could turn MCP from a developer integration layer into a user-facing ecosystem.
- **Tasks** provide first-class support for long-running async work. Tasks were an experimental core feature in
2025-11-25, but production use revealed enough design issues that they've been moved to an extension and substantially redesigned. A server can respond totools/callwith a task handle, and the client drives the lifecycle withtasks/get,tasks/update, andtasks/cancel. Thetasks/listendpoint is removed because it couldn't be scoped safely without sessions. Anyone who built against the experimental Tasks API in2025-11-25will need to migrate to the new lifecycle.
What's deprecated
Three features are deprecated in this release:
- Roots are replaced by Resource URIs (plain URLs).
- Sampling is removed from the core spec and may return as an extension.
- Logging is also removed from the core spec.
The spec now includes a formal deprecation policy. Deprecated features are documented, continue to work during a transition period, and are eventually removed with clear timelines. This is the first time MCP has had a structured process for evolving the spec without breaking existing implementations.
What you need to do before July 28
If you're running MCP servers in production, here's the migration checklist:
- Check for session dependencies. Find every place your server stores or read
Obsidian intake evidence excerpt
ClawFeed 24小时高价值一览 · 2026-07-20
- status: completed
- Obsidian: /Users/gracker/Library/Mobile Documents/iCloud~md~obsidian/Documents/Obsidian/OpenClaw定时任务/ClawFeed24小时高价值一览/2026-07-20-ClawFeed24小时高价值一览.md
任务信息：
- 任务名称：ClawFeed 24小时高价值一览（For You+Bookmarks）
- 处理数量：候选 65 篇，认真阅读 10 篇，入选 3 篇
- 数据源：OpenCLI Hacker News top、DuckDuckGo 开发者生态/AI 工具检索、OpenCLI web read、OpenCLI Twitter thread
- 落盘路径：/Users/gracker/Library/Mobile Documents/iCloud~md~obsidian/Documents/Obsidian/OpenClaw定时任务/ClawFeed24小时高价值一览/2026-07-20-ClawFeed24小时高价值一览.md
- 验证状态：已落盘且非空
可发布正文如下：
今日精选
1. Bun 用 11 天把 53.5 万行 Zig 主体迁到 Rust，这篇不是“AI 写代码真快”的热闹，而是一份可复用的大规模 agent 工程记录：50 个动态工作流、64 个 Claude 并行、双 adversarial reviewer、6,502 个提交、全平台 CI 绿灯后才合并。 2. MCP 2026-07-28 release candidate 把协议往生产环境推了一大步：去掉协议层 session，改成每个请求携带版本和能力信息；授权对齐 OAuth 2.1、RFC 9728、RFC 8707；长任务和 Apps 进入扩展机制。 3. OpenAI Frontier 的信息量在于企业 agent 平台形态：共享业务上下文、agent 执行环境、评估优化、身份权限边界，加上 FDE 进入企业现场，把模型能力、组织流程和权限治理放在同一个产品里。
评分：9.3/10 推荐语：这篇最值得看的是工程细节，不是结论。作者把 1,448 个 Zig 文件迁到 Rust 的过程拆成 porting guide、lifetimes.tsv、实现 agent、两个独立审查 agent、修复 agent、CI 失败回收循环，并给出真实的失败案例：git stash/git reset 互相踩、agent 为了编译加 stub、unwrap_or eager evaluation 造成 panic、libuv async close 触发 UAF/double-free。 摘要：Bun 团队用预发布 Claude Fable 5 和 Claude Code dynamic workflows，在 11 天内完成 Rust 迁移，最终 6 个平台 CI 全绿，0 个测试被跳过或删除。文章给出迁移成本和收益：5.9B uncached input tokens、690M output tokens、约 16.5 万美元 API 成本，换来 128 个已复现 bug 修复、Bun.build() 内存泄漏收敛、Linux/Windows binary 约 20% 变小、若干 workload 2%–5% 提速。 链接：https://bun.com/blog/bun-in-rust
- 标题：Rewriting Bun in Rust
评分：8.5/10 推荐语：这篇适合正在跑 MCP server 的人读，因为它把 release candidate 里的破坏性变化翻成迁移清单。最有用的点是去 session 后的部署模型变化：不用 sticky session 和共享 session store，网关可以按 Mcp-Method / Mcp-Name header 路由；需要状态的应用改用显式 handle，比如 basket_id、browser_id。 摘要：MCP 2026-07-28 候选规范移除 initialize/initialized handshake 和 Mcp-Session-Id，每次请求携带协议版本、client info 和 capability，并通过 server/discover 拉取服务端能力。授权部分补上 OAuth 2.1 resource server、Protected Resource Metadata、Resource Indicators、issuer verification、refresh token 行为和 client application type，解决多 MCP server 场景下的 token 混用风险。 链接：https://workos.com/blog/mcp-2026-spec-agent-authentication
- 标题：The biggest MCP spec update ships July 28: What changes for AI agent authentication
评分：8.1/10 推荐语：这篇虽然是产品发布，但给出了 OpenAI 对企业 agent 平台的分层判断：业务上下文、执行环境、评估优化、身份权限边界必须一起出现。案例也比普通发布稿更具体：制造业生产优化从 6 周压到 1 天，硬件测试失败的 root-cause identification 从约 4 小时降到几分钟。 摘要：Frontier 把企业 agent 当“AI coworker”管理：接入数据仓库、CRM、工单和内部应用，提供跨本地环境、企业云和 OpenAI-hosted runtime 的执行环境，并用评估反馈让 agent 在真实工作里改进。它的战略信号是 OpenAI 不只卖模型和 API，而是在争夺企业 agent 的上下文层、运行时、权限治理和现场交付入口。 链接：https://openai.com/index/introducing-openai-frontier/
- 标题：Introducing OpenAI Frontier
可直接发布文案
今天最值得读的是 Bun 迁 Rust 的复盘。它不像普通“AI 写代码”故事，细节很硬：1,448 个 Zig 文件、约 53.5 万行原代码、50 个动态工作流、最多 64 个 Claude 并行跑 11 天，最后 6 个平台 CI 全绿才合并。
有参考价值的是它的工作流设计：实现 agent 不审查自己的代码，另外两个 Claude 只负责找 bug；编译错误、测试失败、CI 失败都变成 work queue；agent 一旦开始用 stub 糊编译，直接改 prompt 让 reviewer 拒绝这种做法。
这类项目能跑通，不靠“把需求丢给模型”，靠的是测试套件、隔离、审查角色、失败回收和人盯关键节点。以后评价 coding agent，不能只看 demo，要看它能不能进入这种生产循环。
https://bun.com/blog/bun-in-rust
备选短文案
- Bun 迁 Rust 这篇很适合当 agent 工程样板看：64 个 Claude 并行不是重点，重点是实现、审查、修复、CI 回收被拆成了可重复的循环。
- MCP 7 月新规范的方向很清楚：少一点隐藏 session，多一点显式状态、标准授权和网关可治理性。生产环境跑 MCP server 的团队该提前看迁移点。
- OpenAI Frontier 的信号是：企业 agent 平台竞争不在聊天框，而在业务上下文、执行环境、评估、权限边界和现场交付。