The Model Context Protocol’s 1.1 specification was published this week. The changes target the security gaps in 1.0 that were becoming visible as the ecosystem matured: granular permissions, authentication flows, and a path toward signed packages.
For tools using MCP (Cline, Windsurf, Claude Code, Codex CLI, others), this is the foundation for safer ecosystem expansion.
What’s new in 1.1
The spec changes:
Granular permissions. MCP servers can now declare specific permissions they need (filesystem-read, filesystem-write, network access to specific domains, process execution). Tools can grant or deny each permission individually. Previous 1.0 had broad “allow tools” semantics.
OAuth-style authentication. MCP servers can require authentication for some or all operations. Tools negotiate auth tokens through standard OAuth flows. Previously, servers either had no auth or rolled their own.
Signed packages. A signing format for MCP server packages. Tools can verify a server hasn’t been tampered with between publication and execution. The infrastructure for signing keys is still being built; the format is in place.
Capability negotiation. Servers and tools negotiate capabilities at session start. A tool that supports only some MCP features can communicate this; servers can adapt or refuse to start. Previous 1.0 had no version negotiation.
Audit logging. Servers can emit audit log entries that tools surface to users. Useful for understanding what an MCP server actually did during a session.
Why this matters
I wrote earlier about the supply chain risks in MCP servers. The 1.0 spec’s permissions model was too coarse to provide meaningful security; servers had broad access by design.
1.1 is the response. The granular permissions let users (and tool vendors) limit servers to what they actually need. A Postgres MCP server that needs only read access to one database can be granted exactly that, not blanket filesystem access. A buggy or malicious server can still cause problems but the surface is much smaller.
This is the kind of progression that browser extensions, kernel modules, and other privileged software went through. MCP is following the same pattern, hopefully without needing a major incident to motivate it.
Backward compatibility
The 1.1 spec is backwards-compatible with 1.0 in the sense that 1.0 servers continue to work. Tools negotiate down to 1.0 features when interacting with 1.0 servers.
For users, this means the existing MCP servers you have continue working. New servers built against 1.1 get the additional security features. The transition is gradual.
The catch: 1.0 servers don’t get the security improvements automatically. To benefit from granular permissions, server authors have to update to 1.1. Expect uneven adoption — popular servers will update quickly; smaller ones may take time.
What tools need to do
Tool vendors (Cline, Windsurf, Claude Code, etc.) need to:
- Update their MCP client implementations to 1.1
- Build UI for granular permission management
- Implement signature verification (when the signing infrastructure is live)
- Surface audit logs to users
Cline 3.5 had partial 1.1 support before the spec was finalized; full support is expected in upcoming releases. Other tools have indicated similar plans.
What server authors need to do
For people maintaining MCP servers:
- Update to a 1.1-compatible SDK
- Declare the permissions your server actually needs (avoid asking for more than necessary)
- Implement OAuth flows for authenticated servers
- Eventually, sign your packages
This work is straightforward but takes time. Major server maintainers (the ones at Anthropic, Microsoft, GitHub, etc.) will update quickly. Community-maintained servers may take longer.
What’s still rough
A few things 1.1 didn’t fully solve:
Permission revocation. Once you grant permissions, revoking them requires resetting the server’s state. A “rotate permissions” feature would help.
Cross-tool permission sync. If you use the same MCP server with multiple tools (Cline and Claude Code), each tool tracks permissions separately. Sharing permission state would reduce setup friction.
Reputation/trust scoring. No standardized way to assess “should I trust this server?” beyond the marketplace’s own review. A community reputation system would help users make informed choices.
Sandbox enforcement. Permissions are declared in metadata; the actual enforcement depends on the tool’s sandbox implementation. Strong sandboxing is hard, especially across different OS platforms.
These are reasonable future work. 1.1 is a meaningful step forward, not a final solution.
My take
1.1 is the right response to the gaps that were emerging in MCP. The pace from spec ideation to publication has been reasonable; the changes are coherent; backward compatibility is preserved.
For the MCP ecosystem to continue growing, this kind of evolution is necessary. Static specs with growing user bases produce friction; the maintainers responding to the evolving needs is healthy.
For users, the practical implication is small in the near term. Existing setups keep working. Over the next 6 months, expect tools and servers to update; the security improvements become real as adoption catches up.
For organizations evaluating MCP for serious adoption, 1.1’s permissions and auth model removes some of the security objections that were reasonable against 1.0. The protocol is now in better shape for enterprise consideration.
What I’d watch
- Speed of tool vendor adoption of 1.1
- Major server maintainers updating to 1.1
- The signing infrastructure becoming live (TBD timing)
- Whether the granular permissions UI is intuitive for users (the design challenge)
If these go well, MCP becomes the de facto standard for AI tool integrations. If they don’t, the protocol risks fragmentation as different tools build their own integration layers.
The bet is on smooth adoption. The 1.1 release is the foundation; the next year is the test.
