MCP’s Next Phase: Inside the November 2025 Specification
AI Security & Development
Most enterprises are learning the same lesson. The hard part of AI agents is not generating answers. It’s governing actions.
Once an agent can change systems, orchestrate cloud services, or trigger long-running workflows, the conversation shifts fast. Experimentation gives way to accountability. Trust becomes operational, not theoretical.
This is the context for the latest evolution of the Model Context Protocol (MCP).
The November 2025 specification marks a meaningful shift. MCP moves beyond simple, synchronous tool calls and toward an architecture that supports secure, long-running, governed workflows in real production environments. It introduces modern authorization, asynchronous execution, and early enterprise-grade foundations for safe autonomy.
This does not solve everything. Gaps remain around registration consistency, workload identity, supply-chain provenance, and governance standards. But this release is the point where MCP stops feeling experimental and starts looking like something organizations can intentionally build on.
I’ve been following MCP closely through prior posts on authorization, security, NLWeb, and registries. That includes a same-week OAuth 2.1 proof-of-concept that surfaced real gaps in Dynamic Client Registration.
This post breaks down what changed in the 2025 specification cycle, what it means for engineers and security teams, and what still needs to be designed for safe scale.
The Road to November: What MCP Looked Like in June
The June 2025 specification established MCP’s first stable model for connecting agents to external tools and data sources. It defined how servers expose capabilities, how clients discover resources and prompts, and how structured tool invocation works.
This enabled early interoperability across agent ecosystems without forcing every integration to become a custom API.
But the June version had clear limits that made production use risky:
Execution was mostly synchronous. Long-running work was unsupported.
Authorization was basic, with coarse trust boundaries.
Client registration and identity handling were inconsistent.
Governance and lifecycle controls were minimal.
There was no standard approach to provenance or secure discovery.
It worked for demos and experiments.
It was fragile for real systems.
The November release begins to change that direction.
Key Changes in the November 2025 MCP Specification
1. Asynchronous Tasks and Long-Running Workflows
The most important addition is the new Tasks primitive.
MCP servers can now create asynchronous, long-running operations. A server returns a task handle, publishes progress updates, and delivers results when the work completes.
This enables production-grade workloads such as:
Document processing and indexing
Analytics and ETL jobs
External system state collection
Model inference and training
Deployment and infrastructure actions
This moves MCP beyond simple call-and-response. It becomes a workflow-capable orchestration layer.
The Tasks primitive is new, and real-world maturity will depend on implementations. But the architectural direction is correct.
2. Modernized Authorization Built on OAuth 2.1
The November spec introduces a stronger authorization model based on OAuth 2.1. It supports Protected Resource Metadata discovery and OpenID Connect for authorization server resolution.
In practice:
Clients behave as OAuth clients
Servers behave as OAuth resource servers
This enables standardized access control and incremental scope negotiation. Permissions can be requested only when a workflow needs them, rather than all at install time. That aligns with zero trust principles and limits privilege sprawl.
There are still gaps. Dynamic Client Registration is optional, not mandatory. Many deployments will rely on manual or pre-configured registration. Workload identity for non-human clients remains unresolved.
The structure is there. Patterns will vary.
3. Governance and Enterprise Alignment
The specification now improves capability negotiation, lifecycle signaling, and metadata clarity. Combined with Tasks and OAuth 2.1, MCP can now support the foundations of enterprise governance.
Not everything is standardized yet. But the direction is clear.
MCP is moving toward a future where registries, attestation, version tracking, and policy enforcement can become first-class concerns.
Why These Changes Matter
These updates are not incremental. They redefine what MCP can support.
Enables Real Production Use Cases
The new primitives unlock workloads that require real operational power:
Long-running document analysis
Data transformation pipelines
Distributed model inference
CI/CD and infrastructure automation
Cross-system business workflows
This is the line between prototypes and production.
Improves Security Posture and Access Control
Incremental scopes and OAuth 2.1-aligned flows make least-privilege enforcement practical. Combined with task boundaries, risk can be evaluated per operation, not per integration.
This aligns agent safety with modern DevSecOps and zero trust architectures.
Supports Architectures Beyond Synchronous Request-Response
Asynchronous agents change the system model. Architectures must now handle:
Task lifecycle monitoring
Execution isolation
Observability and traceability
Policy enforcement and approval gates
Failure handling and compensation
Agents stop being UI helpers. They become distributed system participants.
Architectural Implications
With the November release, MCP-powered systems start to resemble agent orchestration platforms:
Agent or IDE Client
↔ MCP Server
↔ Tasks
↔ Cloud services, APIs, data stores, tooling
This introduces new responsibilities:
Lifecycle management and controlled deprecation
Monitoring and event streaming for task progress
Chain-of-custody visibility for authorization
Rollback and resilience patterns
Registry and provenance expectations
The ecosystem begins to look like a blend of service mesh, event orchestration, and identity governance.
This closely mirrors emerging AgentOps lifecycles, where agents follow deployment, monitoring, compliance, and retirement paths similar to microservices.
Registries and Supply Chain Trust
As MCP servers gain operational reach, secure discovery becomes critical.
A malicious MCP server is not just a bad data source. It’s a gateway to privileged execution.
Registries move from convenience to security boundary. Over time, they must support:
Server signing and provenance metadata
SBOM linkage and vulnerability mapping
Scope declarations
Sandbox and execution model disclosure
Policy admission control
These are not mandated today. They exist as best-practice direction. But enterprise adoption will demand them.
Teams building MCP servers now should plan for supply-chain accountability and attestation.
What Still Needs Work
The November release closes major gaps, but important issues remain open:
Standard identity for non-human and serverless workloads
Mandatory provenance and attestation
Registry governance and federation standards
Tool-level scope granularity
Deprecation and end-of-life signaling
Standardized observability and auditability for tasks
These must be addressed before MCP can support mission-critical automation at scale.
Practical Recommendations
For Engineers Building MCP Servers
Use asynchronous Tasks for time-based workflows.
Implement scoped authorization and avoid broad permissions.
Publish clear metadata, including SBOMs and lifecycle details.
For Security Teams
Evaluate MCP servers by workload behavior, not just APIs.
Monitor task creation, permission changes, and execution results.
Use private registries or policy enforcement layers when possible.
For Enterprise Architects
Treat MCP as a structural integration layer.
Plan for registry strategy and supply-chain validation.
Integrate agent workflows into CI/CD, monitoring, and incident response.
For Vendors and Platform Providers
Support OAuth 2.1 onboarding and CIMD registration paths early.
Expose provenance and security posture metadata.
Provide lifecycle guarantees and compliance visibility.
Conclusion: A Foundation for Secure Autonomous Systems
The November MCP specification marks a pivotal moment.
Asynchronous execution, modern authorization, and enterprise alignment move MCP from a lightweight tool protocol toward a foundation for secure, distributed agent systems.
Key challenges remain. Identity, provenance, governance, and registry trust are still evolving. But the direction is unmistakable.
Agents are moving into production. The standards beneath them must reflect operational reality.
Organizations that design with intent will shape how autonomy, safety, and control coexist. Those that treat agents as optimistic APIs will absorb unnecessary risk.
MCP V2 is a step toward the infrastructure required for safe, scalable autonomy.
Now is the moment to build deliberately.
Want the full deep dive? Check out my full article on Medium.
🚀 Stay tuned for more posts in AI Security & Development! Follow for more insights on securing AI, cloud, and Web3.
AI Security & Development - AI table of contents included.