Approving an MCP server once should not give its future releases an automatic pass. Invariant Labs demonstrated that instructions embedded in tool descriptions could redirect an agent, including its use of tools supplied by another server. The researchers also described descriptions changing after a client has approved them.
A November 12 FDE Times guide brings that risk into release management. Ask whether the software and tool definitions still match what someone reviewed.
Make changes visible
- Pin local servers to exact package versions or immutable artifacts rather than moving
latestreleases. - Record the approved
tools/listresponse. Fingerprint tool names, full descriptions andinputSchema, including parameter descriptions. Sort and serialize consistently before hashing. - Compare against that baseline before using the tools. Stop automatic use on a mismatch, inspect a readable diff, and approve changes before updating the baseline.
- Review file access, credentials and outbound connections alongside the diff. Separate sensitive reading from external sending where practical.
Invariant recommends pinning servers and tools and checking description integrity. A matching hash shows continuity with the reviewed definition; it cannot prove safe execution. Backend behavior and returned data can change independently of that definition.
Use these change checks alongside the controls in our MCP permissions, sandboxing and audit-log checklist.