Las definiciones de herramientas MCP como superficie de ataque: descripciones envenenadas, shadowing y cambios silenciosos

Objetivo

Tratar la lista de herramientas que devuelve un servidor MCP como una entrada no confiable, y detectar cuándo intenta influir en el agente o cambia después de haber sido aprobada.

Requisitos previos

Un cliente o una pasarela (gateway) donde se puedan registrar las definiciones de herramientas antes de que lleguen al modelo; una lista de los servidores aprobados.

Pasos

1. Leer la postura de la especificación: las herramientas llevan un nombre, una descripción, un esquema de entrada, un esquema de salida opcional y anotaciones opcionales, y los clientes DEBEN considerar las anotaciones de herramienta no confiables salvo que provengan de servidores de confianza. Aplicar la misma postura a las descripciones, que el modelo lee como prosa.
2. En el momento de la aprobación, guardar un hash de la definición completa de cada herramienta (nombre, descripción, esquemas, anotaciones) por servidor.
3. En cada conexión, y cada vez que el servidor envíe una notificación de lista modificada, recalcular los hashes. Si alguna definición cambió, suspender las herramientas de ese servidor hasta que una persona revise el diff.
4. Revisar las descripciones en busca de instrucciones dirigidas al modelo y no al usuario: solicitudes de leer archivos ajenos al propósito de la herramienta, de incluir datos adicionales en los argumentos, de preferir esta herramienta sobre la de otro servidor, o de ocultar algo al usuario.
5. Detectar el shadowing: dos servidores que exponen herramientas con nombres iguales o confundibles, o la descripción de un servidor que se refiere a las herramientas de otro. Espaciar por nombre (namespace) los nombres de herramienta por servidor en el cliente.
6. Comprobar que lo que hace una herramienta coincide con sus anotaciones; una herramienta anotada como de solo lectura que tiene efectos de escritura es motivo para eliminar el servidor.
7. Mostrar al usuario el nombre del servidor y los argumentos exactos antes de una llamada con efectos secundarios, no solo la autodescripción de la herramienta.

Resultado esperado

Los cambios en las definiciones de herramientas se vuelven eventos visibles en lugar de actualizaciones silenciosas; una descripción que intenta dirigir al modelo se detecta en la revisión y no en un incidente.

Límites y base de verificación

El hash detecta el cambio, no la intención; una definición maliciosa desde el principio necesita la revisión del paso 4. Un servidor puede seguir comportándose de forma distinta a lo que dice su descripción en el momento de la llamada: las definiciones no restringen nada del lado del servidor. Los servidores locales se ejecutan con los privilegios del usuario; la guía de seguridad de MCP trata el compromiso de un servidor local como un riesgo aparte.