Si en el último año alguien de tu equipo conectó un asistente de IA a algo real, es probable que haya un servidor MCP funcionando en algún rincón de tu infraestructura. Puede que lo montara una tarde quien necesitaba que el asistente llegara a una base de datos. Y probablemente sigue ahí.
Ese servidor guarda credenciales. Un análisis de riesgos publicado el 17 de agosto de 2026 describe qué ocurre cuando nadie lo trata como la frontera de seguridad en la que se ha convertido.
Qué es ese servidor exactamente
El Model Context Protocol es un estándar abierto, presentado originalmente por Anthropic, que permite a los asistentes de IA conectarse a herramientas y datos externos. En lugar de limitarse a lo que el modelo ya sabe, un agente puede consultar un registro, abrir un archivo o llamar a una API.
La pieza que hace posible todo eso es el servidor MCP: un programa pequeño situado entre el asistente y el sistema al que quiere llegar, que expone las acciones concretas que el agente tiene permitido ejecutar.
Y ahí se concentra el riesgo. Para actuar sobre un sistema, el servidor necesita las credenciales de ese sistema. En palabras del análisis, el servidor «normalmente guarda las llaves de todo lo que toca: credenciales, claves de cuentas de servicio, tokens de API y otros secretos».
El cambio de fondo: los agentes ya no solo producen respuestas, ejecutan acciones. Un secreto filtrado desde un servidor MCP no expone datos y ya está. Entrega a un atacante la capacidad de actuar sobre ellos.
Cinco maneras de que los secretos salgan
Credenciales en texto plano dentro de archivos de configuración. Poner un servidor en marcha suele consistir en pegar una cadena de configuración que contiene las propias credenciales. Ese archivo queda en disco, se copia entre máquinas y de vez en cuando acaba subido a un repositorio.
Credenciales dispersas por servidores sin gobierno. Sin un lugar central donde guardar secretos, cada agente administra los suyos. Las mismas claves se reparten entre archivos de configuración y variables de entorno, duplicadas en desarrollo, preproducción y producción. Como nadie tiene el inventario completo, rara vez se rotan y siguen siendo válidas indefinidamente.
Inyección de prompts. Los agentes leen el material que reciben y actúan sobre él, lo que convierte cualquier texto que procesan en un canal de instrucciones potencial.
Permisos excesivos. Un servidor montado con prisa tiende a recibir acceso amplio, porque acotarlo lleva tiempo y rompe cosas durante la instalación.
Servidores expuestos. El análisis señala que esa exposición suele producirse antes de que los equipos de seguridad sepan siquiera que el servidor existe.
El ejemplo con nombre conviene retenerlo: mcp-remote, descrito en el análisis como «un proxy OAuth descargado más de 400.000 veces que se ejecuta en la máquina cliente», a través del cual «un servidor malicioso podría provocar una inyección de comandos del sistema operativo». Es el CVE-2025-6514.
Qué es esa cifra y qué no es
Cuatrocientos mil es un número de descargas de una herramienta de proxy. No es un recuento de instalaciones vulnerables, y el análisis no ofrece ninguno.
La distinción importa más de lo que parece, porque la cifra de descargas es el dato más fácil de citar de toda la historia y el menos informativo. Nadie ha publicado cuántos servidores MCP están expuestos. Si te encuentras ese número por ahí, pregunta de dónde sale.
Las cinco contramedidas, tal como están escritas
El análisis enumera cinco, y se leen como una lista de comprobación más que como una estrategia:
- «Dejar de incrustar secretos en el código y centralizarlos»
- «Usar credenciales de corta duración y rotarlas automáticamente»
- «Aplicar el mínimo privilegio»
- «Mantener a una persona en el circuito para las acciones sensibles»
- «Cifrar los secretos con un modelo de confianza cero y conocimiento cero»
Nada de esto es pensamiento novedoso en seguridad, y ese es justamente el asunto. Son las prácticas que ya eran estándar para credenciales de producción, aplicadas a una clase de servidor que con frecuencia se montó fuera del proceso que las habría exigido.
La pregunta incómoda del lunes
Cualquiera que tenga herramientas de agentes puede repasar esa lista en una tarde. El valor está en el inventario.
Empieza por la pregunta que el análisis sugiere sin llegar a formular: ¿alguien tiene una lista de qué servidores MCP están funcionando, quién los montó y hasta dónde llega cada uno? En muchas organizaciones esa lista no existe, porque cada servidor se añadió para resolver un problema concreto de una persona concreta, y ninguna de esas incorporaciones pareció infraestructura en su momento.
La segunda pregunta sale de la primera. Para cada servidor de esa lista, ¿qué podría hacer un atacante con lo que guarda, más allá de leerlo? Un agente con permiso de escritura sobre un sistema de tickets, un canal de despliegue o una base de datos de clientes es una exposición distinta de uno que solo consulta documentos.
Y la tercera va sobre el material que leen tus agentes. La inyección de prompts funciona porque los agentes actúan sobre el texto que reciben, de modo que cada documento, página y mensaje que procesan forma parte de la superficie de ataque. La mayoría de las organizaciones publican y absorben grandes cantidades de texto sin preguntarse nunca qué haría con él un lector automático.
Ninguna de estas preguntas necesita un equipo de seguridad para responderse. Necesitan que alguien escriba la lista.
Fuentes
- The Hacker News, «How MCP Servers Can Expose Enterprise Secrets», 17 de agosto de 2026: https://thehackernews.com/2026/08/how-mcp-servers-can-expose-enterprise.html (consultado el 26 de agosto de 2026). Origen de las cinco categorías de exposición, las cinco contramedidas, la descripción del MCP y del papel del servidor, y el ejemplo de mcp-remote con la cifra de descargas y el CVE-2025-6514. El análisis existe únicamente en inglés: las citas de este artículo son traducción propia del original, no citas literales en español.
