La seguridad del servidor MCP empieza con una regla tajante: trata cada servidor MCP como software que puede tocar tus datos, llamar herramientas e influir en el siguiente movimiento de un agente de IA. El Model Context Protocol es útil porque conecta asistentes a recursos, prompts y herramientas ejecutables, pero ese mismo diseño crea riesgos en torno a la autorización, la inyección de prompts, la ejecución de comandos y la exfiltración de datos.
Por qué la seguridad del servidor MCP es diferente de la seguridad API ordinaria
Anthropic lanzó el Model Context Protocol el 25 de noviembre de 2024 como un protocolo abierto para conectar aplicaciones de IA a fuentes de datos y herramientas externas. Según la especificación del 25 de noviembre de 2025, los servidores MCP proporcionan tres elementos principales: recursos, prompts y herramientas. Las herramientas son la parte más delicada. Son funciones que el modelo puede ejecutar.
Una API normal espera a que un cliente determinista haga una solicitud. Un servidor MCP puede estar detrás de un host de IA que interpreta la intención del usuario, lee descripciones de herramientas, selecciona acciones y, a veces, encadena varios servidores. Eso hace que la seguridad del servidor mcp sea en parte un problema de seguridad de aplicaciones y en parte un problema de control del agente.
La política oficial de seguridad de MCP, publicada en GitHub y citada en 2026, es refrescantemente directa: los clientes MCP confían en los servidores a los que se conectan, y los servidores MCP locales deberían considerarse de confianza igual que el software instalado. Ese es el modelo mental correcto. Si no instalarías una aplicación de escritorio sin firmar desde un repositorio aleatorio en un portátil de finanzas, no conectes el cliente de IA de esa misma máquina a un servidor de herramientas aleatorio con acceso al sistema de archivos o a la red.
Si estás creando flujos de trabajo agénticos, el riesgo operativo se parece más a la entrega autónoma de software que a un widget de chat. La misma cautela se aplica a los bucles de programación con IA y a los cambios desatendidos; nuestra guía sobre ingeniería de bucles para sistemas de IA es relevante porque las herramientas MCP a menudo se convierten en las manos de esos bucles.
El modelo de amenazas central: herramientas, confianza y movimiento de datos
Empieza por lo que el servidor puede hacer realmente. Un servidor de solo lectura que expone documentación pública es algo muy distinto de un servidor que puede consultar bases de datos de producción, enviar mensajes de Slack, crear pull requests en GitHub o iniciar pagos. Sinceramente, llamar a ambos “un servidor MCP” puede ocultar la diferencia de riesgo.
La especificación MCP dice que los hosts deben obtener el consentimiento explícito del usuario antes de invocar cualquier herramienta y antes de exponer datos del usuario a los servidores. No lo trates como una simple cortesía de UX. Es un límite de seguridad, y uno débil si tu host presenta mensajes vagos como “¿Permitir acceso?” sin indicar el servidor de destino, el nombre de la herramienta, la categoría de datos y la consecuencia.
La guía práctica de OWASP de 2026 para el desarrollo seguro de servidores MCP hace hincapié en una arquitectura segura, autenticación y autorización sólidas, validación estricta, aislamiento de sesiones y despliegue reforzado. Son términos conocidos, pero MCP les da un giro: una respuesta maliciosa puede ser leída por el modelo como una instrucción, no solo mostrada como datos.
Aquí está el escollo que muchos equipos pasan por alto: la parte peligrosa puede ser una herramienta que no llamaste directamente. En una configuración con varios servidores, un servidor de bajo privilegio puede devolver texto que empuje al agente a llamar a una herramienta privilegiada en otro servidor. Eso es propagación implícita de confianza, y un artículo de arXiv de enero de 2026 titulado “Breaking the Protocol” lo señaló como una de las tres preocupaciones a nivel de protocolo, junto con la falta de atestación de capacidades y el muestreo bidireccional sin autenticación de origen.
Dónde encaja la autenticación en la seguridad del servidor mcp
La especificación de autorización MCP del 18 de junio de 2025 define la autorización basada en HTTP usando OAuth 2.1, OAuth Authorization Server Metadata, Dynamic Client Registration y Protected Resource Metadata. Si tu servidor es accesible a través de HTTP, deberías estar leyendo esa especificación, no improvisando el manejo de bearer tokens en una rama de fin de semana.
Sin embargo, la autorización es opcional en el protocolo. Esa frase debería hacerte detenerte. La especificación dice que los transportes HTTP deberían seguir la especificación de autorización MCP, los transportes STDIO deberían obtener credenciales del entorno y los transportes alternativos deberían seguir las prácticas de seguridad de su propio protocolo.
La autenticación opcional del protocolo no significa seguridad opcional. Significa que la carga recae sobre ti. Para la seguridad del servidor mcp, necesitas decidir qué identidades existen: el usuario humano, la aplicación host, el cliente MCP, el servidor y la cuenta de servicio aguas abajo. Si todo eso se reduce a un único token todopoderoso, la auditabilidad se resiente y una brecha hace más daño.
Un patrón práctico es separar la autorización del usuario de la autorización de la herramienta. Puede que a un usuario se le permita conectarse a un servidor MCP de CRM, pero no ejecutar “export_all_contacts” o “delete_account_notes.” Si ya piensas en términos de refuerzo de la identidad, los modos de fallo se parecen a los problemas de MFA y abuso de sesión tratados en nuestro análisis de la advertencia de MFA de Microsoft 365: la autenticación por sí sola no te salva cuando las sesiones y los permisos son demasiado amplios.
Vulnerabilidades conocidas y lo que enseñan
La vulnerabilidad pública más concreta del registro proporcionado es CVE-2025-6514, publicada por NVD el 9 de julio de 2025. Afectó al paquete npm mcp-remote versiones 0.0.5 hasta 0.1.15, y NVD la clasificó como CWE-78 Inyección de comandos del SO.
La vulnerabilidad implicaba conectarse a servidores MCP no fiables mediante URLs de respuesta de authorization_endpoint manipuladas. Su vector CVSS v3.1 era AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H. Traducido: vector de ataque de red, baja complejidad de ataque, no se requieren privilegios, se requiere interacción del usuario, alcance modificado y alto impacto en la confidencialidad, la integridad y la disponibilidad.
| Problema o elemento de investigación | Año | Qué se informó | Lección de seguridad |
|---|---|---|---|
CVE-2025-6514 en mcp-remote |
2025 | Inyección de comandos del SO en las versiones 0.0.5 hasta 0.1.15 |
No confíes en los metadatos de autorización proporcionados por el servidor sin validarlos |
| OWASP MCP Tool Poisoning | 2026 | Las respuestas maliciosas de herramientas pueden desencadenar llamadas restringidas, filtraciones o evasiones de prompts | Trata la salida de las herramientas como entrada no fiable, no como instrucciones |
| «MCP Pitfall Lab», prepublicación de arXiv | 2026 | Según se informa, el hardening redujo los hallazgos de Tier-1 de 29 a 0 con un coste medio de 27 líneas de código | Pequeños cambios en el código pueden eliminar importantes clases de exposición |
| Análisis de LangSight | 2026 | Se informó de 8.247 servidores MCP expuestos sin autenticación | La exposición a Internet ya se está produciendo a escala |
| Investigación de TrueFoundry | 2026 | Se informó de 492 servidores MCP expuestos públicamente sin autenticación básica ni cifrado | La higiene básica de transporte y autenticación sigue fallando en despliegues reales |
Esas cifras de exposición a Internet proceden de investigaciones de proveedores, no de un organismo de estandarización, así que tómalas como señales de advertencia y no como datos censales. Aun así, la dirección es obvia. Los equipos están publicando endpoints de MCP más rápido de lo que los están sometiendo a modelado de amenazas.
Haz un cálculo sencillo. Si un servidor expuesto tiene cuatro herramientas, y solo una herramienta puede leer tickets internos, resumir documentos o enviar mensajes, una sola respuesta envenenada puede crear cuatro puntos de decisión en los que se puede desviar al agente. Escálalo a 50 servidores internos y ya no estás revisando «una integración de chatbot». Estás revisando un tejido de automatización distribuida.
Envenenamiento de herramientas: el riesgo que los escáneres corrientes no detectan
OWASP describe el Envenenamiento de Herramientas de MCP como una inyección indirecta de prompts a través de respuestas maliciosas de herramientas MCP. El resultado puede ser grave: un agente puede invocar herramientas restringidas, filtrar datos o eludir los prompts del sistema porque una herramienta devolvió contenido que parecía una instrucción.
Los escáneres de seguridad clásicos buscan inyección SQL, inyección de comandos, path traversal y secretos expuestos. Útil. Pero no entenderán de forma fiable que un campo JSON llamado summary contiene lenguaje que indica al modelo que ignore las reglas anteriores y envíe credenciales a otra herramienta.
Por tanto, una buena seguridad del servidor mcp requiere disciplina en las salidas. La guía de prevención de OWASP incluye salidas estructuradas con esquema fijo, aislamiento de herramientas privilegiadas, controles de acceso del lado del servidor, allowlists de servidores aprobados, principio de mínimo privilegio y confirmación del usuario fuera de banda para acciones sensibles o de exfiltración. Yo situaría los esquemas fijos cerca del principio. La prosa en formato libre es donde empieza gran parte de la confusión de los agentes.
En los sistemas que recuperan conocimiento externo, la misma familia de riesgos aparece en la generación aumentada por recuperación. Si tu servidor MCP introduce documentos en un agente, las cuestiones de diseño se solapan con las de Decisiones entre RAG y fine-tuning: ¿dónde entra el texto no confiable, quién puede influir en él y qué puede hacer el modelo después de leerlo?
Elabora una lista de comprobación práctica de hardening
Los consejos de seguridad se vuelven imprecisos rápidamente, así que conviértelos en algo operativo. Antes de que un servidor MCP llegue a un usuario real o a un conjunto de datos real, deberías poder responder qué expone el servidor, qué identidades pueden llamarlo, a qué puede acceder cada herramienta y cómo detectarás un uso indebido.
- Haz un inventario de todas las herramientas. Registra el nombre de la herramienta, la descripción, los parámetros, los sistemas posteriores, las clases de datos y las acciones destructivas en una documentación adaptada a 2026 que tus revisores realmente puedan leer.
- Usa credenciales de mínimo privilegio. Otorga a cada servidor y herramienta de alto riesgo solo los permisos que necesita, preferiblemente con tokens de alcance limitado y cuentas de servicio independientes.
- Valida las entradas y las salidas. Aplica esquemas estrictos, rechaza los campos inesperados, limita la longitud de las cadenas y evita pasar la salida sin procesar de la herramienta al contexto del agente cuando baste con un valor tipado.
- Exige consentimiento explícito para las llamadas arriesgadas. Muestra al usuario el servidor, la herramienta, los argumentos, el destino y los datos que se van a compartir antes de la ejecución, especialmente en el caso del correo electrónico, los pagos, la eliminación, los cambios de código y las exportaciones.
- Separa las herramientas con privilegios. Mantén las herramientas de búsqueda de solo lectura alejadas de las herramientas de escritura, las herramientas de administración y el acceso a secretos; usa servidores independientes si eso hace que el límite quede más claro.
- Permite solo servidores de confianza. No permitas que los empleados conecten servidores MCP públicos arbitrarios a hosts internos sin revisión, fijación de versión y aprobación de la configuración.
- Registra las decisiones, no solo las solicitudes HTTP. Registra la selección de herramientas, la aprobación del usuario, la identidad del servidor, los argumentos, las salidas y los efectos posteriores con una retención que se ajuste a tus necesidades de respuesta ante incidentes.
Un contraargumento merece atención: demasiadas confirmaciones pueden enseñar a los usuarios a hacer clic sin leer. Es cierto. La respuesta no es tener menos controles en todas partes; es aplicar fricción en función del riesgo. Una consulta meteorológica no debería sentirse como una transferencia bancaria, pero exportar datos de clientes a un servidor de terceros debería requerir una confirmación visible e independiente.
La observabilidad importa porque los fallos de MCP pueden parecer que «el modelo hizo algo raro». Instrumenta la cadena. Si estás creando telemetría para sistemas de agentes, nuestro desglose de arquitectura de observabilidad de IA a escala de datos encaja bien con el registro de MCP, las trazas y la correlación de eventos.
Opciones de despliegue que reducen el radio de impacto
Los servidores STDIO locales resultan tentadores porque son fáciles de integrar en las herramientas para desarrolladores. La comparación de la política de seguridad oficial es útil: trata los servidores MCP locales como software instalado. Fija versiones, revisa el código o su procedencia, y evita ejecutarlos con el conjunto completo de secretos de tu shell habitual, salvo que realmente los necesiten.
Los servidores de red necesitan protección del transporte, autenticación, autorización y límites de tasa. Si un servidor está expuesto públicamente, colócalo detrás de los mismos controles que esperarías para una API interna: TLS, acceso basado en identidad, monitorización, aplicación de parches, análisis de dependencias e interruptores de desactivación de emergencia. Aquí ganan los controles aburridos.
La prepublicación de 2026 en arXiv “MCP Pitfall Lab” informó de que el endurecimiento recomendado redujo los hallazgos de nivel 1 de 29 a 0 y redujo la puntuación de riesgo de su marco de trabajo de 10.0 a 0.0 con un coste medio de 27 líneas de código. Como es una prepublicación, no trates las cifras como universales. Tómalas como un recordatorio útil de que muchos errores de MCP son pequeños y corregibles: falta de validación, comprobaciones de origen débiles, permisos demasiado amplios y descripciones ambiguas de herramientas.
El comercio agéntico eleva aún más el nivel de riesgo. Una herramienta que lee inventario es una cosa; una herramienta que gasta dinero es otra. Las cuestiones de seguridad en torno al consentimiento, los límites de transacción y la aprobación humana se solapan con los riesgos comentados en pagos y compras con IA agéntica, donde una mala acción puede tener consecuencias financieras inmediatas.
Gobernanza: decidir quién puede conectar qué
Alguien de tu organización debe asumir la responsabilidad de las conexiones MCP. Sin ello, cada equipo se convierte en su propia autoridad de integración, y el experimento más débil define vuestra exposición. Así es como los servidores “temporales” se convierten en vías de ataque permanentes.
Un modelo de gobernanza claro tiene tres filtros. Primero, aprueba la fuente del servidor: proveedor, repositorio, responsable de mantenimiento, licencia y proceso de actualización. Después, aprueba las capacidades: herramientas, ámbitos, categorías de datos y destinos salientes. Por último, aprueba el tiempo de ejecución: aplicación host, transporte, credenciales, registros y flujo de consentimiento del usuario.
Los informes públicos de 2026 de LangSight y TrueFoundry afirmaban que había desde cientos hasta miles de servidores MCP expuestos sin autenticación. Aunque los totales exactos cambien a medida que mejoren los análisis, la lección para la seguridad del servidor mcp sigue siendo la misma: denegar por defecto la exposición externa y hacer que las excepciones sean formalmente rutinarias.
También te convendrá disponer de un interruptor de apagado. Si una herramienta empieza a filtrar datos o una dependencia recibe un CVE como mcp-remote lo hizo en 2025, necesitas desactivar el servidor, rotar credenciales, revocar sesiones y conservar los registros sin esperar a la reunión del equipo de plataforma del próximo jueves.
Preguntas frecuentes
¿Qué es un servidor MCP en términos sencillos?
Un servidor MCP es un servicio que expone recursos, indicaciones o herramientas a una aplicación de IA a través del Model Context Protocol. La parte arriesgada son las herramientas, porque son funciones que el modelo puede ejecutar.
¿Requiere el protocolo autorización de MCP?
No. La especificación de autorización MCP de 2025 define una autorización HTTP basada en OAuth 2.1, pero la autorización es opcional en el protocolo. Los transportes HTTP deben seguir la especificación de autorización MCP, mientras que STDIO y otros transportes necesitan una gestión de credenciales adecuada para su entorno.
¿Qué es MCP Tool Poisoning?
El envenenamiento de herramientas MCP es un ataque indirecto de inyección de instrucciones en el que la salida maliciosa de una herramienta influye en un agente para que llame a herramientas restringidas, filtre datos o ignore las instrucciones del sistema. Los esquemas de salida fijos, el principio de mínimo privilegio, las listas de permitidos del servidor y la confirmación fuera de banda reducen el riesgo.
¿Debería confiar en los servidores MCP públicos?
Solo tras revisarlo. La política oficial de seguridad de MCP indica que los clientes confían en los servidores a los que se conectan, por lo que los servidores públicos deben tratarse como software de terceros con acceso a tu agente, tus datos y, en ocasiones, a capacidades locales.
¿Cuál es la mejora más rápida para la seguridad del servidor mcp?
Haz un inventario de todas las herramientas y elimina los permisos innecesarios. Luego añade una validación estricta del esquema y una confirmación explícita para las acciones sensibles; esos controles reducen tanto los errores habituales del software como el uso indebido específico de los agentes.
ES 
EN 
FR