Protocol migration is a threat-model event because observability and control may move to extensions or product-specific layers.
Why this question matters
The MCP 2026-07-28 release deprecates Roots, Sampling, and Logging in the core specification and moves Tasks into an extension. This simplifies and evolves the protocol, but deployments may have used those features as informal trust or monitoring boundaries.
Teams should map which controls depended on core behavior and verify equivalent semantics after migration. A feature name that survives in a vendor product may no longer have the same interoperability or governance guarantees.
Signals worth observing
- A client assumes deprecated notifications remain universally available.
- Monitoring disappears when a server upgrades protocol versions.
- Task semantics differ between the former core feature and extension.
Practical control direction
- Inventory controls tied to deprecated protocol features.
- Pin and test extension versions before migration.
- Keep security logs outside optional protocol convenience features.
AgentCollusion lensRelationship evidence should remain stable even while transport and protocol features evolve.Sources and further reading
Next field note: Stateless MCP Moves State Into the Evidence Layer
