El MCP listo para empresas trae nuevos retos de seguridad

El Model Context Protocol (MCP) pasó en poco más de año y medio de ser una propuesta de Anthropic a convertirse en el estándar de facto para que un modelo llame a herramientas externas. Esa adopción acelerada tiene contrapartida: cada servidor MCP que una empresa conecta a su asistente es una puerta nueva hacia sus datos y sus sistemas. SecurityWeek dedica un análisis a la última revisión de la especificación, la pensada para entornos corporativos, y su lectura es clara: lo que vuelve a MCP apto para producción es también lo que amplía su superficie de ataque. Puedes leer el artículo original en SecurityWeek.

Qué ha cambiado

La versión 'enterprise-ready' del protocolo no añade una función llamativa, sino que cierra los huecos que impedían usarlo con seriedad dentro de una organización. El punto central es la autorización: el modelo de permisos se apoya ahora en OAuth 2.1, con tokens de alcance acotado y una separación más explícita entre quién es el usuario, qué servidor actúa en su nombre y a qué recursos puede tocar. Junto a eso se formaliza cómo se descubren los servidores, cómo se declaran sus capacidades y cómo se registra la actividad. Sobre el papel, es lo que pide cualquier equipo de seguridad antes de dejar que un agente ejecute acciones reales.

Por qué importa

El problema es que un protocolo de herramientas hereda los riesgos de todas las herramientas que expone, y suma los suyos propios. Tres frentes destacan.

El primero es la inyección indirecta de instrucciones. Si un servidor MCP devuelve texto que el modelo trata como contexto de confianza, ese texto puede contener órdenes. Un documento, un ticket o una página web manipulada se convierten en vía para que el agente haga algo que su usuario nunca pidió.

El segundo es el 'confused deputy'. Un agente con tokens válidos y permisos amplios es un intermediario apetecible: si un atacante consigue redirigir su intención, el agente usará sus credenciales legítimas para actuar. La especificación empresarial reduce el margen al acotar alcances, pero no elimina el patrón.

El tercero es la cadena de suministro. Instalar un servidor MCP de terceros se parece más a instalar una extensión con permisos que a llamar a una API: corre con acceso a datos y acciones, y casi nadie audita su código. Un catálogo creciente de servidores comunitarios multiplica la comodidad y, con ella, el riesgo de que uno malicioso o simplemente descuidado entre en producción.

Para quién

La lectura interesa sobre todo a tres perfiles. A los equipos de plataforma e infraestructura que están decidiendo cómo desplegar MCP de forma centralizada en vez de dejar que cada desarrollador conecte lo que quiera. A los responsables de seguridad, que necesitan tratar cada servidor como software privilegiado y no como un plugin inocuo. Y a quienes construyen servidores MCP, que ahora tienen un marco de autorización serio pero también la responsabilidad de no pedir más permisos de los que necesitan.

Para una empresa que ya usa Claude Code o asistentes internos, el mensaje práctico es sencillo: el inventario de servidores MCP es ahora parte del inventario de seguridad. Conviene saber cuáles están conectados, con qué alcances, quién los mantiene y qué pueden hacer en el peor de los casos.

La lectura de EP

Hemos integrado MCP en suficientes proyectos como para tener una opinión templada: el protocolo no es inseguro por diseño, pero llevar a producción algo que nació para el escritorio del desarrollador exige los mismos controles que cualquier integración con privilegios. La especificación empresarial es un paso necesario, no una garantía. Quien despliegue servidores MCP en una organización hará bien en empezar por lo aburrido, alcances mínimos, registro de actividad y revisión de lo que cada servidor expone, antes que por la lista de integraciones nuevas.