How to resolve
Implement tool versioning: Use semantic versioning for tool definitions and require version increments when schemas or behavior change. Notify clients of changes: Implement a notification mechanism that alerts clients and users when tool definitions are modified. Track definition history: Maintain an audit log of all changes to tool schemas, descriptions, and implementations with timestamps and change reasons. Use content hashing: Generate cryptographic hashes of tool definitions and expose them to clients for verification of consistency. Require approval for changes: Implement a review and approval process before tool definition changes take effect.Risk
Governance/Compliance Silent redefinition vulnerabilities violate multiple security standards:- NIST SP 800-53 (CM-3): Fails to implement configuration change control, allowing unauthorized modifications to system components.
- OWASP API Security Top 10 (API8:2023 - Security Misconfiguration): Lacks version control and change notification mechanisms.
- OWASP MCP Top 10 (MCP03:2025 - Tool Poisoning): Silent changes to tool definitions can introduce malicious behavior without detection.
Explanation
Silent redefinition occurs when an MCP server modifies its own tool definitions—including code, descriptions, or parameters—without notifying the client or end user. This vulnerability undermines the trust model by allowing servers to alter their behavior in ways that may not be transparent to users or security controls.Specifications
Trigger- MCP server scan detects changes to tool schemas, descriptions, or implementations between scan sessions without proper versioning or client notification
- CRITICAL