La nueva especificación MCP desplaza la seguridad hacia los desarrolladores. Checklist concreto para securizar tu servidor MCP sin bloquear tus agentes IA.
La nueva especificación del Model Context Protocol, publicada a finales de junio de 2026, desplaza una parte crítica de la responsabilidad de seguridad del protocolo hacia los desarrolladores que lo implementan. Concretamente: si tu servidor MCP expone una herramienta sensible sin validación estricta de tokens OAuth, la brecha viene de tu código, no del protocolo diseñado por Anthropic.
Es un cambio de filosofía, no un simple parche. Hasta ahora, MCP seguía siendo relativamente permisivo en la forma en que los servidores gestionaban la autenticación. La nueva versión lista para empresas, documentada por SecurityWeek a finales de junio, cierra este margen de maniobra y empuja a los equipos a endurecer ellos mismos sus implementaciones. Ya lo habíamos mencionado en Comercio agentivo en Shopify: MCP se convierte en la interfaz estándar entre agentes IA y sistemas empresariales. El problema es que conectar un agente a tu CRM o tu base de pedidos sin protección es abrir una puerta que nadie vigila.
Qué cambió en la especificación MCP de junio de 2026
El protocolo MCP funciona como una interfaz unificada: un agente IA, Claude, Cursor, o cualquier cliente compatible, se conecta a ella para llamar herramientas externas sin código específico por integración. X (el antiguo Twitter) lanzó su propio servidor MCP a finales de junio para permitir que agentes como Claude o Grok Build accedan directamente a su plataforma, según TechCrunch. HiBob hizo algo similar días antes con una integración MCP que conecta Slack a su SIRH.
Esta adopción rápida tiene un reverso. Cuantos más servidores MCP se expongan públicamente, mayor es la superficie de ataque. La nueva especificación responde a esto formalizando requisitos más estrictos sobre la gestión de tokens y scopes OAuth. Pero no los impone técnicamente, documenta lo que un servidor "listo para empresas" debe hacer. Libre cada desarrollador de seguir o ignorar.
Aquí está el punto contraintuivo: una especificación más segura sobre el papel puede hacer que el ecosistema sea menos seguro a corto plazo, porque da la ilusión de que el protocolo ya gestiona el problema. No lo hace. Documenta el problema y te deja la patata caliente.
Las brechas que ya vemos en los despliegues MCP
Tool poisoning: cuando un servidor miente sobre lo que hace
Un servidor MCP declara sus herramientas mediante un manifiesto en lenguaje natural, una descripción que el agente lee para decidir cuándo llamarla. Nada impide que un servidor malicioso, o comprometido, declare una herramienta "solo lectura" que en realidad escribe en tu base de datos. El agente confía en la descripción, no en el código real. Este es el vector más documentado en la comunidad de seguridad MCP desde principios de 2026.
OAuth mal configurado, el vector número uno
La mayoría de los incidentes provienen de una confusión clásica: scopes demasiado amplios, tokens que nunca expiran, o peor aún, tokens compartidos entre múltiples agentes en el mismo servidor. Un token MCP comprometido da acceso a todo lo que el scope autoriza, no solo a la solicitud actual.
Ausencia de sandboxing entre el agente y el sistema de archivos
Muchos servidores MCP todavía se ejecutan localmente, con acceso a disco casi total para simplificar el desarrollo. Funciona muy bien hasta el día en que el agente recibe un prompt malicioso inyectado a través de un documento externo y ejecuta un comando shell que nunca debería haber tenido permiso para lanzar.
Cómo securizar un servidor MCP en producción
Aquí está lo que recomendamos concretamente, por orden de prioridad:
- Scopes OAuth granulares, un scope por herramienta, nunca un scope global "admin".
- Expiración corta de tokens, 15 a 60 minutos, con actualización explícita en lugar de tokens que viven semanas.
- Validación del manifiesto de herramientas en cada llamada, no solo en el momento del handshake inicial.
- Sandboxing sistemático, contenedor aislado, sistema de archivos de solo lectura excepto directorio dedicado.
- Logs de auditoría por llamada de herramienta, con alertas sobre patrones anormales (frecuencia, horarios, scopes inusuales).
- Rate limiting en el lado del servidor MCP, independiente del rate limiting de la API subyacente.
Esta lista no tiene nada de revolucionario. Es esencialmente higiene API clásica, aplicada a un protocolo más joven que la mayoría de estándares REST. La diferencia es que nadie todavía tiene los reflejos automáticos, porque MCP tiene poco más de un año de existencia pública.
Un límite honesto a mencionar: estas medidas ralentizan el desarrollo. Un scope por herramienta significa más configuración cada vez que añades una nueva herramienta. Si tu equipo despliega rápido e itera en un MVP interno no expuesto públicamente, este nivel de rigor puede ser desproporcionado. Resérvalo para servidores expuestos a terceros o que manipulan datos sensibles.
MCP vs API REST clásica: la seguridad en comparación
| Criterio | API REST clásica | Servidor MCP |
|---|---|---|
| Autenticación | OAuth 2.0 / API keys, estándar maduro | OAuth integrado en la especificación, pero implementación variable |
| Descubrimiento de capacidades | Documentación estática (OpenAPI) | Manifiesto dinámico leído por el agente en tiempo de ejecución |
| Superficie de ataque | Endpoints conocidos, fijos | Herramientas declaradas dinámicamente, por tanto más difícil de auditar |
| Control de acceso | Roles y permisos bien establecidos | Scopes todavía poco granulares en la práctica |
| Madurez del ecosistema | 15+ años de patrones probados | Menos de dos años, mejores prácticas aún en movimiento |
La tabla habla por sí sola: MCP no es menos securizable que una API REST, pero el ecosistema de herramientas, escáneres y mejores prácticas aún tiene que ponerse al día. Llegará. De momento, depende de ti compensar.
Lo que ya hacen los grandes actores
Anthropic hizo evolucionar su modelo Claude hacia Sonnet 5 a finales de junio de 2026, en sustitución de Sonnet 4.6 lanzado en febrero, según 9to5Mac. Un modelo más capaz plantea mecánicamente más riesgos en la agencia: cuanto más autónomo es el agente en sus decisiones, más consecuencias tiene una brecha MCP aguas arriba. X eligió exponer un servidor MCP público para permitir que agentes como Claude o Cursor interactúen directamente con su plataforma, una opción que supone una gobernanza de tokens particularmente estricta dado el volumen. HiBob, por su lado, optó por una integración más cerrada, conectando su SIRH a Slack vía MCP en lugar de exponer un servidor abierto a cualquier cliente.
Dos filosofías, dos niveles de riesgo. Si tu tienda Shopify o tu SaaS interno planea exponer un servidor MCP, la pregunta que hacerse primero es: ¿realmente necesitas un acceso abierto, o un acceso cerrado a tus propios agentes es suficiente?
Conclusión
Tres puntos a recordar. Primero, la nueva especificación MCP no securiza automáticamente tus despliegues, documenta requisitos que debes implementar tú mismo. Segundo, las brechas más frecuentes siguen siendo clásicos: scopes demasiado amplios, tokens que no expiran, sandboxing ausente. Tercero, el rigor tiene un costo en velocidad, a reservar para servidores realmente expuestos.
Si ya expones un agente IA conectado a tu stack vía MCP, o si todavía dudas entre una solución sin código y una implementación personalizada, los arbitrajes están detallados en Sin código vs código para construir un agente IA. ¿Necesitas una auditoría de seguridad en tu servidor MCP antes de lanzarlo a producción? Contactanos en fstck.co.
Preguntas frecuentes
¿Cómo sé si mi servidor MCP es vulnerable al tool poisoning?
Verifica que el manifiesto declarado por cada herramienta coincida exactamente con su comportamiento real en producción, no solo con la documentación. Una auditoría simple: registra cada llamada de herramienta y compara la acción real (escritura, lectura, llamada externa) con la descripción anunciada en el manifiesto.
¿Debo esperar a que MCP madure antes de desplegarlo en producción?
No, pero debes adaptar el nivel de rigor a la exposición real del servidor. Un servidor MCP interno, accesible solo por tus propios agentes en una red privada, tolera menos restricciones que un servidor expuesto públicamente a clientes terceros.
¿Cuál es la diferencia entre los scopes OAuth de una API REST y los de un servidor MCP?
El principio es idéntico, limitar el acceso a lo estrictamente necesario, pero la especificación MCP promueve un scope por herramienta en lugar de un scope por recurso. En la práctica, muchas implementaciones actuales siguen siendo demasiado permisivas por falta de herramientas maduras para gestionar esta granularidad fácilmente.
¿Un token MCP comprometido da acceso a todas las herramientas del servidor?
Depende completamente de la configuración de los scopes. Si el token tiene un scope global, sí, el atacante recupera todo lo que ese scope autoriza. Por eso la granularidad de los scopes no es un detalle opcional, sino la primera línea de defensa.
¿Es MCP más riesgoso que una integración API clásica?
No es intrínsecamente más riesgoso, pero es menos maduro en términos de herramientas de auditoría y mejores prácticas estandarizadas. El descubrimiento dinámico de capacidades, que es la fortaleza de MCP, también complica el análisis estático de seguridad que se hace fácilmente en una API REST documentada en OpenAPI.
