Unicode TAG-Block Concealment of Tool-Metadata Payloads in the Model Context Protocol: An Approval-View Fidelity Gap Across Three Independent Server Implementations

Resumen Técnico: Ocultación de Carga Útil de Metadatos de Herramientas mediante el Bloque Unicode TAG en el Protocolo de Contexto de Modelo (MCP)

Declaración del Problema

El Protocolo de Contexto de Modelo (MCP) se ha convertido en el mecanismo estándar para que los agentes de codificación descubran e invoquen herramientas externas. En esta arquitectura, un servidor anuncia herramientas mediante un intercambio de manos tools/list, devolviendo metadatos (nombre, descripción en lenguaje natural y esquema de entrada JSON). El cliente renderiza estos metadatos en un diálogo de aprobación de una sola vez para el usuario y, posteriormente, inyecta los metadatos íntegramente en el contexto del modelo en cada turno.

El artículo identifica una brecha de fidelidad crítica: el protocolo no requiere que la vista de aprobación renderizada (lo que el humano ve) coincida con los bytes entregados al modelo (lo que el tokenizador recibe). Esta brecha permite que un servidor malicioso o comprometido utilice la codificación de ocultación —escribir instrucciones en conjuntos de caracteres que los renderizadores no pueden mostrar pero que los tokenizadores aceptan— para evadir la revisión humana mientras entrega simultáneamente instrucciones controladas por el atacante al modelo. Esto transforma los metadatos de las herramientas en un canal de entrega de prompts no supervisado, permitiendo ataques de "envenenamiento de herramientas" (tool poisoning) y de "delegado confundido" (confused deputy), donde el agente es dirigido para exfiltrar secretos o ejecutar operaciones peligrosas basadas en instrucciones ocultas al usuario.

Metodología

Los autores emplean un enfoque de tres vertientes que combina el análisis teórico, la medición empírica y la validación entre implementaciones:

1. Análisis de Mecanismo Independiente del Modelo: Antes de ejecutar los experimentos, los autores analizan el flujo de renderizado. Determinan que los terminales, clientes de chat e IDEs convencionales mapean los puntos de código Unicode a glifos. Si un punto de código no tiene un glifo asignado (no asignado), el renderizador no muestra nada (o muestra un espacio en blanco), mientras que el tokenizador del modelo decodifica los bytes UTF-8 brutos independientemente de la asignación de glifos. Este análisis predice que el bloque Unicode TAG (U+E0000–U+E007F), que es válido pero no asignado en las fuentes convencionales, será invisible para los humanos pero totalmente visible para el modelo.
2. Prueba de Concepto de Protocolo Real: Los autores construyeron un entorno utilizando un cliente y un servidor MCP genuinos que se comunican mediante JSON-RPC/stdio. Implementaron 8 técnicas concretas a través de 5 superficies de metadatos distintas (descripción de la herramienta, esquema de entrada, nombre de la herramienta, canal de error y mutación post-aprobación).
   • Técnicas: Incluyeron inyección directa, sombreado entre herramientas (cross-tool shadowing), ocultación mediante el bloque Unicode TAG, retransmisión de credenciales de delegado confundido, coerción de esquema de valores predeterminados peligrosos, colisión de espacios de nombres e inyección en el canal de error y ataques de "rug-pull" de Tiempo de Verificación a Tiempo de Uso (TOCTOU).
   • Defensas Probadas: Un sanitizador de coincidencia de cadenas representativo (utilizando lógica conjuntiva de palabras clave imperativas y sensibles) y un renderizado de revisión humana simulado.
3. Validación de la Multiplicidad de Librerías: Para distinguir las propiedades del protocolo de los artefactos de implementación, el catálogo completo de técnicas fue reimplementado y probado contra 3 librerías de servidor MCP de Python desarrolladas independientemente (el SDK oficial de bajo nivel, la API de decorador de alto nivel oficial FastMCP y un paquete de terceros fastmcp).

Contribuciones Clave

• Aislamiento de la Codificación de Ocultación: El artículo aísla un mecanismo estructural único —la codificación de ocultación— donde la divergencia entre la búsqueda de glifos del renderizador y el vocabulario del tokenizador permite que las cargas útiles sobrevivan a la revisión humana mientras alcanzan al modelo.
• Brecha de Fidelidad a Nivel de Protocolo: Demuestra que el diseño de MCP trata los metadatos de las herramientas como instrucciones indistinguibles de los prompts del sistema, pero depende de un modelo de consentimiento grueso de un solo paso donde la vista renderizada y el contexto del modelo son rutas de código independientes.
• Medición Empírica de la Evasión de Defensas: El estudio proporciona la primera medición determinista, a nivel de protocolo, de qué técnicas de envenenamiento de herramientas derrotan a defensas específicas (sanitizadores vs. revisión humana) y cuáles sobreviven a las mutaciones de definición sin activar una re-aprobación.
• Verificación de la Multiplicidad de Implementaciones: Al reproducir los resultados en tres bases de código de servidor distintas, los autores establecen que estas vulnerabilidades son inherentes a la especificación de MCP y al comportamiento de renderizado de Unicode, no errores en una librería específica.

Resultados

El estudio arrojó los siguientes hallazgos empíricos a través de 8 técnicas y 5 superficies de metadatos:

• Entrega al Modelo: 8/8 técnicas entregaron con éxito cargas útiles controladas por el atacante en el contexto del modelo.
• Evasión de Sanitizadores: 4/8 técnicas evadieron el sanitizador de coincidencia de cadenas base. Esto incluyó técnicas que enmarcaron las instrucciones como configuración (coerción de esquema), usaron nombres de herramientas como vector de ataque o utilizaron la codificación de ocultación.
• Evasión de Revisión Humana: Solo 1/8 técnica (T7: ocultación mediante el bloque Unicode TAG) evadió el renderizado de revisión humana. Como predijo el análisis del mecanismo, la carga útil del bloque TAG era invisible para el renderizador (sin glifo asignado) mientras permanecía intacta en el flujo de bytes entregado al modelo.
• Ejecución de Re-Consentimiento: 0/8 técnicas activaron una re-aprobación forzada por el protocolo, incluso en el caso del "rug-pull" T3, donde una definición de herramienta benigna fue mutada a una envenenada después de que el usuario ya hubiera aprobado el servidor.
• Acuerdo de Multiplicidad de Librerías: Las 32 celdas de resultado (8 técnicas × 3 librerías) produjeron resultados idénticos, confirmando que los hallazgos son propiedades a nivel de protocolo.

Significancia y Reivindicaciones

El artículo afirma que la vulnerabilidad no es un error específico de un producto de software, sino una brecha estructural en el modelo de confianza del protocolo MCP. La significancia radica en identificar que:

1. La Fidelidad de Renderizado es Crítica: Las defensas actuales que dependen de la coincidencia de cadenas o la revisión humana son insuficientes porque inspeccionan una superficie renderizada que puede ser vaciada mediante la codificación de ocultación. El artículo argumenta que las vistas de aprobación deben ser fieles a los bytes (renderizando los bytes exactos o normalizando los puntos de código no asignados a marcadores de posición visibles) en lugar de ser meramente plausibles visualmente.
2. Faltan Mecanismos de Protocolo: El protocolo carece de mecanismos para forzar el re-consentimiento cuando las definiciones de las herramientas mutan (TOCTOU) o para delimitar los espacios de nombres de las herramientas por origen (evitando colisiones de espacios de nombres).
3. Estrategia de Defensa: Los autores concluyen que solucionar estos problemas requiere cambios estructurales en la capa del protocolo (consentimiento fiel a los bytes, re-consentimiento ante mutaciones, espacios de nombres delimitados por procedencia) en lugar de depender únicamente de mitigaciones en el tiempo de autoría o sanitizadores de coincidencia de cadenas.

El artículo establece explícitamente que no propone una nueva familia de ataques, sino que aísla la propiedad específica (fidelidad de renderizado vs. entrega) que determina si los ataques existentes de envenenamiento de herramientas son visibles para el revisor humano. Posiciona su trabajo como el primero en combinar la medición de un protocolo real, la contabilidad de capas de defensa, el análisis de mecanismos independiente del modelo y la validación de múltiples librerías.