Model Context Protocol defines a date-stamped protocol version, such as 2024-11-05 or 2025-06-18, negotiated during the initialization handshake between an AI agent client and an MCP server. This version confirms wire-protocol compatibility: it tells both sides which message formats and capabilities the session will use. It does not identify or verify the specific server implementation, its code revision, or the exact set of tools, schemas, and permission scopes that server exposes.
This distinction matters because MCP also supports a tools/list_changed notification, which allows a connected server to alter its available tools or their schemas during an active session without renegotiating the protocol version or requiring a new handshake. A server can remain on the same protocol version while its actual tool definitions, parameters, or requested permissions change entirely. Standard software dependency pinning, which typically locks a package to a fixed release number, does not address this gap, because the protocol version and the server's functional behavior are governed independently. Treating protocol version negotiation as sufficient assurance means pinning the wrong layer.
How Unpinned MCP Servers Create Security Exposure
The practical risk of this gap has already been documented. Security researchers have described tool poisoning attacks and MCP rug pulls, in which a server's tool description or schema is modified after a client has already reviewed and approved it. Because MCP does not require re-validation when tool definitions change mid-session, an agent can continue operating under a permission set or instruction set that was never reviewed in its current form. A tool approved for read-only data retrieval, for example, could later be updated to request broader write access or embed additional instructions in its description field, and the agent may accept the change without triggering any alert.
Compounding this, the MCP specification does not include a standardized mechanism for cryptographically signing or checksum-verifying server packages or binaries. Distribution integrity is left to external ecosystems such as npm, PyPI, or container registries, none of which are MCP-specific. An enterprise running an MCP server pulled via a mutable tag such as latest has no built-in way to confirm that the code, tool schema, or permission scope running today matches what was reviewed last week. This is the specific failure mode that version pinning is designed to close.
Integrating Pinning Into CI/CD and Runtime Enforcement
Version pinning for MCP servers works best when built into processes enterprises already run, rather than treated as a separate governance track. The version manifest and digest pin can be enforced as a gate within existing CI/CD pipelines, so a new MCP server version cannot be promoted to production until its manifest has been reviewed and its schema hash logged. Tool schemas and permission scopes should be diffed and recorded at every connection, creating an audit trail showing what changed, when, and whether it was approved.
Rollback procedures also need to be defined and tested in advance. If a newly pinned MCP server version introduces unexpected tool behavior or an unreviewed permission request, platform teams need a tested path back to the last known-good pinned version rather than an ad hoc response. Aligning this work with existing software supply-chain practices, such as software bills of materials and artifact registries, avoids building a parallel process that security and platform teams have to maintain separately. At runtime, this same manifest and schema-hash data can feed policy enforcement that flags or blocks an MCP server connection when its observed version or schema no longer matches its approved baseline, which is the layer where runtime governance and tool approval workflows for AI agents typically operate.
Governance Considerations for MCP Tool Permission Changes
- Treat permission expansion as new tool onboarding: Any expansion of an MCP tool's permission scope should require the same review threshold as approving an entirely new tool.
- Define internal provenance policy: Because the specification does not mandate signing, enterprises need their own policy for verifying MCP server origin and integrity.
- Integrate with existing AI governance: MCP version and schema change control should extend existing AI governance and change management frameworks rather than sit outside them.
- Assign clear ownership: Reviewing and approving MCP server version or schema changes typically requires shared ownership between security and platform engineering.
- Maintain historical audit records: Retain records of prior MCP server versions and their associated tool definitions to support traceability during audits or incident review.