MCP necesita un apretón de manos de confianza: admisión atestiguada de servidores de herramientas

¿De qué se trata?

El 22 de mayo de 2026, Alfredo Metere publicó en arXiv el paper Attested Tool-Server Admission: A Security Extension to the Model Context Protocol (2605.24248, cs.CR). El trabajo nace de una necesidad operativa concreta — permitir que el agente Enclawed se conecte a los servidores MCP externos de Google (Gmail, Calendar, Drive) sin tener que elegir entre confianza ciega y rechazo total — y se generaliza como un añadido limpio y retrocompatible al protocolo.

El argumento parte de una observación estructural sobre MCP tal como se entrega hoy: el protocolo estandariza cómo un host LLM y un servidor de herramientas intercambian mensajes, pero no tiene noción nativa de qué servidores puede usar un host, a qué nivel de sensibilidad, o cuáles de las herramientas de un servidor están dentro del alcance. Un host lee la lista de herramientas auto-declarada por un servidor y despacha las llamadas. Ese es exactamente el modelo de confianza que hereda una conexión de tercera parte no mediada, y es el hueco que vuelve esencialmente imposibles los despliegues acreditados hoy.

El paper propone tres pequeños añadidos, expresados en forma normativa RFC 2119 para que puedan adoptarse como addendum de MCP en lugar de reinventarse. Llega dos días después del documento del NSA AISC Model Context Protocol: Security Design Considerations for AI-Driven Automation — ambos documentos llegan a la misma conclusión desde extremos opuestos de la pila.

Cómo funciona

mcp-attested añade tres verificaciones en capas al handshake de MCP. Un host no extendido que no conoce el documento well-known lo ignora y se comporta exactamente como hoy: el diseño es estrictamente aditivo.

Mecanismo                    Dónde vive                          Qué filtra
---------------------------  ----------------------------------  --------------------------
Signed clearance assertion   URI well-known del servidor         Admisión del servidor
Per-server tool allowlist    Config del host, deny-by-default    Despacho herramienta a herramienta
Flavor-gated enforcement     Modo runtime del host               Warn vs. hard-deny

Aserción de clearance firmada. Cada servidor MCP publica en una URI well-known un pequeño documento firmado offline. El host verifica la aserción contra una raíz de confianza pinned antes de despachar cualquier llamada a una herramienta. El servidor ya no se admite por el solo hecho de “implementar MCP”; se admite porque una raíz de confianza que el host ha decidido reconocer ha avalado al servidor a un nivel de clearance dado.

Allowlist per-server deny-by-default. Admitir un servidor no es lo mismo que confiar en todas sus herramientas. El host configura, por servidor admitido, el subconjunto explícito de herramientas a las que dispatch. Todo lo que queda fuera de la allowlist se rechaza sin llegar siquiera al paso de selección de herramienta del modelo — eliminando del modelo (la capa de defensa más lenta y costosa) la responsabilidad de razonar si invocar la herramienta.

Modo de aplicación con dos sabores. Las mismas comprobaciones corren en sabor warning (log y pasa) o en sabor enforcing (log y rechaza). Un despliegue regulado puede enviar el sabor enforcing sin recurso operativo; un despliegue de desarrollo puede quedarse en warning mientras un equipo estabiliza sus allowlists. Cada decisión — admit, deny, warn — se escribe en un registro de auditoría a prueba de manipulaciones, lo que vuelve revisable la decisión de despacho a posteriori.

El paper acompaña el diseño con un formato de hilo, un algoritmo de verificación, un análisis de seguridad y una evaluación adversarial impulsada por LLM. Una línea de trabajo separada, MCPShield (arXiv:2602.14281) publicada en febrero de 2026, adopta un enfoque complementario de capa cognitiva — sondeo guiado por metadatos antes de la invocación, proyección aislada durante la invocación, razonamiento periódico después — y se lee con mayor utilidad junto a este paper, no contra él.

Por qué importa

El modelo de amenazas de MCP con el que la industria viene navegando los últimos dieciocho meses trata al host como la autoridad de confianza y al modelo como el portero. Ambas elecciones están mal, de maneras distintas. El host no tiene asidero a nivel de protocolo sobre quién es el servidor. Y el modelo no es una frontera de seguridad — es un predictor probabilístico de siguientes tokens, al que se le puede convencer de no negarse.

Las consecuencias específicas de MCP de dejar este hueco sin cerrar ya están bien documentadas. La CSI del NSA AISC del 20 de mayo de 2026 cataloga ocho clases de debilidades, entre ellas servidores con spoofing de capacidades y registro de herramientas no autenticado. Los reportes públicos — los hallazgos WhatsApp MCP y GitHub MCP de Invariant Labs, la oleada de CVEs MCP backend de la primavera de 2026 — han mostrado que un servidor malicioso o comprometido puede convertir despachos rutinarios de herramientas en exfiltración o corrupción del sistema de archivos. Ninguno de esos incidentes requirió un prompt ingenioso; sólo requirieron que el host creyera al servidor por su palabra.

Lo interesante de mcp-attested es que saca del todo la decisión de confianza del modelo. El modelo nunca elige despachar a un servidor no atestiguado, porque el camino de despacho del host rechaza antes de que la selección de herramienta del modelo siquiera corra. Es la misma forma que la decisión pre-handshake de TLS: el código aplicativo no puede “considerar” conectarse a un servidor con un certificado inválido.

El precio es un poco de trabajo operativo adicional — gestionar una raíz de confianza pinned, mantener allowlists per-server, distribuir documentos de clearance firmados. La tesis del paper, que suena correcta tras la reciente oleada de CVEs MCP, es que ese es el costo de poder siquiera acreditar un despliegue MCP.

Defensas

Cuatro cosas que vale la pena tomar del paper aun si su stack no adopta mcp-attested al pie de la letra.

1. Fijar (pin) una raíz de confianza para los servidores MCP y rechazar el resto. Aun sin un esquema formal de clearance, los runtimes de host pueden enviar una lista de huellas a las que aceptarán despachar, con todo lo demás produciendo un error duro en lugar de un silencio.
2. Hacer que las allowlists por servidor sean el default, no un opt-in. Tratar “este servidor expone una herramienta que no enumeré” como un bug de despliegue, no como un evento de uso. El conjunto de herramientas a las que un host realmente despachará debe ser explícito y versionado.
3. Separar el modo warning del modo enforcing y enviar registros de auditoría desde el primer día. Incluso un host MCP de desarrollo debería escribir cada decisión de admisión y despacho en un registro a prueba de manipulaciones. La mayoría de los incidentes de producción se reconstruyen desde logs que no existían en el momento de los hechos.
4. Leer este paper junto a la CSI del NSA AISC y MCPShield, no en aislamiento. Los tres cubren juntos la capa de protocolo (Metere), la capa de gobernanza (NSA) y la capa de cognición en runtime (MCPShield). Ninguno basta por sí solo.

Estado

Elemento	Referencia	Fecha	Notas
Paper Attested tool-server admission	arXiv:2605.24248	22 mayo 2026	Formato de hilo RFC 2119, clearance firmado, allowlist, modo de enforcement
Implementación de referencia	mcp-attested (citado en el paper)	mayo 2026	Enviado en las distribuciones enclawed-oss y enclaved según §1
CSI MCP del NSA AISC	nsa.gov, U/OO/6030316-26	20 mayo 2026	Ocho clases de debilidad, línea base defensiva
MCPShield	arXiv:2602.14281	febrero 2026	Defensa complementaria de capa cognitiva

MCP no va a perder su curva de crecimiento en los próximos doce meses. Lo que sí puede perder es la convención de que “lo dijo el servidor” basta para despachar una herramienta — y el paper de Metere es la primera propuesta concreta que permite a un host decir no antes incluso de que se consulte al modelo.