El Model Context Protocol (MCP) se está convirtiendo rápidamente en un estándar común para conectar agentes de IA a datos y herramientas empresariales. Sustituye las integraciones ad-hoc por herramienta con una interfaz compartida que permite a los agentes llamar a servidores externos, recuperar contexto y ejecutar acciones. Pero cada servidor MCP con el que se comunica un agente es un nuevo límite de confianza. Incidentes de seguridad recientes —incluido un paquete npm malicioso que suplantó un servicio de email legítimo y vulnerabilidades divulgadas en los SDK oficiales de MCP— muestran lo que ocurre cuando los equipos tratan los servidores MCP como componentes plug-and-play.
La seguridad MCP significa tratar cada servidor como no confiable por defecto, verificar su origen, limitar el acceso de las herramientas, aislar la ejecución, registrar las acciones y gobernar el despliegue con políticas explícitas. Si su equipo está recorriendo el camino más amplio de piloto a producción descrito en IA agentica en producción, la seguridad MCP es la capa que determina si su agente puede tocar datos empresariales de forma segura una vez que llega allí.
Puntos clave
- MCP convierte cada servidor externo en un nuevo límite de confianza. Las integraciones MCP con permisos abiertos por defecto pueden exponer datos empresariales más allá del ámbito previsto del agente.
- Los principales riesgos de 2026 incluyen el envenenamiento de herramientas, la inyección de prompts a través de respuestas de servidores MCP, ataques de rug-pull y de cadena de suministro, ámbitos de herramientas excesivamente amplios y fallos de validación de OAuth o de tokens.
- Las mejores prácticas de seguridad MCP abarcan la verificación y fijación de versión de servidores, ámbitos de herramientas con mínimo privilegio, aislamiento de ejecución en sandbox, registro de auditoría exhaustivo y aprobación con humano en el bucle para acciones sensibles.
- La gobernanza empresarial cierra la brecha: políticas escritas, clasificación de datos y controles que pueden apoyar la alineación con ISO/IEC 27001:2022 y SOC 2 —pero que por sí solos no establecen el cumplimiento.
- Los servidores MCP remotos autenticados suelen ser más fáciles de gobernar cuando se combinan con segmentación de red, autorización con ámbito limitado, control de egreso y registro centralizado. Remoto no es automáticamente más seguro; es más seguro solo cuando esos controles están en vigor.
¿Qué es el Model Context Protocol (MCP)?
El Model Context Protocol es un protocolo abierto que estandariza cómo las aplicaciones LLM se conectan a fuentes de datos y herramientas externas. Según la especificación oficial del Model Context Protocol, MCP define tres roles: hosts (aplicaciones que gestionan agentes), clientes (entidades dentro del host que se conectan a servidores) y servidores (programas que exponen herramientas, recursos y prompts). MCP es un protocolo abierto introducido originalmente por Anthropic, como se describe en la introducción de Anthropic al Model Context Protocol. No es propiedad exclusiva de ningún proveedor.
Por qué los equipos van más allá de las integraciones ad-hoc
Antes de MCP, conectar un agente a una base de datos, CRM o almacenamiento de archivos significaba escribir una integración personalizada por herramienta. MCP sustituye eso por un protocolo compartido donde cualquier cliente compatible con MCP puede llamar a cualquier servidor. Los beneficios —integración más rápida, servidores reutilizables, portabilidad entre modelos— son reales, pero esa misma facilidad amplía la superficie de ataque. Cuando un desarrollador puede instalar un servidor MCP en segundos, la pregunta pasa de “¿podemos construir esto?” a “¿deberíamos confiar en este servidor con nuestros datos?”
Qué asegura MCP por defecto —y qué no
MCP estandariza la comunicación entre clientes y servidores. No asegura la integración completa. Lo siguiente sigue siendo responsabilidad del host y del cliente: confianza del servidor, autorización, consentimiento, validación de salidas y controles de ejecución (sandboxing, limitación de tasa, aislamiento). La especificación señala que las descripciones y anotaciones de herramientas deben considerarse no confiables a menos que provengan de un servidor de confianza. MCP le ofrece una forma estándar de conectarse —no una garantía de que aquello a lo que se conecta sea seguro.
Por qué la seguridad MCP importa ahora
Un servidor MCP a menudo almacena credenciales para una base de datos, sistema de archivos, proveedor de email o API de negocio. Si el servidor se ve comprometido, tiene permisos excesivos o es malicioso, la superficie de fuga de datos se expande a todo lo que esas credenciales pueden alcanzar.
| Dimensión | Integración ad-hoc | Integración basada en MCP |
|---|---|---|
| Límite de confianza | Una integración personalizada por herramienta | Un límite estándar por servidor, reutilizado entre agentes |
| Ámbito de permisos | Definido por integración, a menudo revisado | A menudo heredado de los valores predeterminados del servidor, fácilmente sobre-otorgado |
| Auditabilidad | Registro personalizado por integración | Llamadas estandarizadas, pero el registro aún debe configurarse |
| Riesgo de cadena de suministro | Limitado a las dependencias elegidas | Cualquier servidor instalable se convierte en una dependencia potencial |
MCP hace que añadir nuevos servidores sea trivialmente fácil, y cada uno extiende el límite. Muchos pilotos ejecutan servidores locales con la configuración predeterminada —sin autenticación, sin registro de auditoría, sin credenciales con ámbito limitado— lo cual es aceptable para una demostración, pero no cuando el agente accede a datos reales de clientes.
Incidentes, vulnerabilidades y patrones de ataque de seguridad MCP documentados
No todas las preocupaciones de seguridad MCP son iguales. Algunas son incidentes reales confirmados. Otras son vulnerabilidades divulgadas y parcheadas antes de una explotación conocida. Otras más son demostraciones de investigación. Esta sección separa las tres.
Incidente confirmado: paquete npm malicioso postmark-mcp
En septiembre de 2025, un paquete npm malicioso de terceros llamado postmark-mcp suplantó a Postmark, un servicio de entrega de email. No era un paquete oficial de Postmark —Postmark no había publicado su servidor MCP oficial en npm antes de este incidente. Según el aviso de seguridad oficial de Postmark, el paquete construyó confianza a lo largo de 15 versiones y luego añadió una puerta trasera en la versión 1.0.16 que enviaba copias ocultas (BCC) de los emails salientes a un servidor externo. El análisis de Koi Security sobre el paquete malicioso reportó aproximadamente 1.500 descargas semanales; el destino oculto del BCC atribuido a Koi Security era una dirección en el dominio giftshop.club.
Este fue un paquete malicioso real y un incidente de cadena de suministro de software, no una vulneración de la plataforma oficial de Postmark. La API y los servicios legítimos de Postmark no fueron comprometidos y permanecieron sin afectación. El incidente demuestra riesgo de cadena de suministro, riesgo de permisos excesivos, fallo en la verificación de servidores y riesgo de cambio de versión. El patrón es similar a un rug-pull; “rug pull” se usa aquí como descripción del patrón, no como clasificación propia de Postmark.
Vulnerabilidades divulgadas: CVE-2025-66414 y CVE-2025-66416
Dos vulnerabilidades divulgadas en los SDK oficiales de MCP destacan los riesgos a nivel de implementación. Estas son vulnerabilidades de implementación divulgadas, no vulneraciones reales confirmadas, sin evidencia pública de explotación en el mundo real.
CVE-2025-66414 — SDK de TypeScript. Antes de la versión 1.24.0, el SDK de TypeScript de MCP no habilitaba la protección contra DNS rebinding por defecto para servidores basados en HTTP. Cuando un servidor se ejecutaba en localhost sin autenticación usando StreamableHTTPServerTransport o SSEServerTransport, y enableDnsRebindingProtection no estaba habilitado, un sitio web malicioso podía eludir la política de mismo origen e invocar herramientas o recursos expuestos. No afecta al transporte stdio. Corregido en 1.24.0. Consulte el aviso de GitHub para CVE-2025-66414 y el registro NVD para CVE-2025-66414.
CVE-2025-66416 — SDK de Python. Antes de la versión 1.23.0, el SDK de Python de MCP (mcp en PyPI) no habilitaba la protección contra DNS rebinding por defecto para servidores basados en HTTP. Cuando un servidor se ejecutaba en localhost sin autenticación usando FastMCP con HTTP streamable o SSE, y TransportSecuritySettings no estaba configurado, un sitio web malicioso podía eludir la política de mismo origen e invocar herramientas o recursos expuestos. No afecta al transporte stdio. Corregido en 1.23.0. Consulte el aviso de GitHub para CVE-2025-66416 y el registro NVD para CVE-2025-66416.
Ambos avisos señalan que ejecutar servidores MCP basados en HTTP localmente sin autenticación no es recomendable. Las configuraciones afectadas son específicas: el transporte stdio y los servidores autenticados no estaban afectados.
Demostraciones de investigación y patrones de ataque teóricos
Investigadores de seguridad han demostrado patrones de ataque que ilustran cómo MCP puede ser abusado. Estas son pruebas de concepto, no incidentes reales confirmados. Los patrones de ataque MCP documentados muestran que instrucciones maliciosas pueden incrustarse en descripciones de herramientas visibles para el modelo pero no obvias para el usuario, causando que el agente tome acciones que el usuario nunca aprobó. También muestran cómo un servidor inicialmente benigno podía introducir posteriormente inyección de prompts indirecta a través de los datos devueltos, manipulando el comportamiento de un agente sin explotar directamente el modelo.
Principales riesgos de seguridad MCP en 2026
Envenenamiento de herramientas y servidores MCP maliciosos
El envenenamiento de herramientas ocurre cuando un servidor incrusta instrucciones maliciosas en descripciones o metadatos de herramientas que el modelo lee pero el usuario no ve. El agente puede seguir esas instrucciones y tomar acciones fuera de la intención del usuario. El incidente de postmark-mcp es un caso confirmado de un servidor malicioso que suplantó un proyecto legítimo.
Inyección de prompts a través de respuestas de servidores MCP
Un servidor MCP devuelve datos —contenido de archivos, filas de bases de datos, respuestas de API. Si esos datos contienen instrucciones, el agente puede tratarlas como comandos. Como el agente confía en el servidor como fuente de datos, el contenido devuelto se convierte en una superficie de inyección a menos que el host lo valide y aísle. Para un tratamiento más profundo, consulte seguridad LLM para IA agentica.
Riesgos de rug-pull y de cadena de suministro de terceros
Un rug-pull ocurre cuando un servidor que inicialmente era seguro cambia su comportamiento tras una actualización. El riesgo de cadena de suministro se extiende a las dependencias, paquetes transitivos y servidores sin mantenimiento. Los agentes llaman a herramientas de forma automática y frecuente, por lo que el radio de impacto de un servidor comprometido es mayor que el de una dependencia de biblioteca típica.
Ámbitos de herramientas excesivamente amplios y exposición de credenciales
A los servidores se les otorgan a menudo permisos más amplios de los que necesitan. Cuando las credenciales pasan por un servidor comprometido o con permisos excesivos, la exposición se extiende a todo lo que esas credenciales pueden alcanzar. El mínimo privilegio es el control que limita el daño cuando un servidor falla.
Fallos de OAuth, validación de tokens y autorización
La autorización MCP para servidores remotos basados en HTTP sigue las convenciones de OAuth 2.1, como se describe en la guía de autorización MCP. La autorización protege los recursos y operaciones sensibles expuestos por los servidores MCP. OAuth no es una garantía automática de seguridad: las implementaciones deben validar la audiencia del token, el emisor, la expiración y los ámbitos; los tokens deben ser de corta duración y almacenarse de forma segura; los flujos de producción deben usar HTTPS; las credenciales, los encabezados de autorización, los tokens y los códigos de autorización no deben escribirse en los registros; y deben evitarse los ámbitos genéricos en favor de ámbitos con mínimo privilegio por herramienta. MCP no implementa OAuth de forma segura por los desarrolladores. Para una guía más amplia sobre paso de tokens, riesgos de suplente confundido, SSRF y minimización de ámbitos, consulte las mejores prácticas de seguridad MCP.
Mejores prácticas de seguridad MCP
Verificar y fijar cada servidor MCP
Trate cualquier servidor MCP como software no confiable: confirme que el publicador es oficial, revise los permisos solicitados, lea el código fuente o una auditoría de confianza, fíjelo a una versión específica y prefiera servidores de organizaciones en las que confíe. El incidente de postmark-mcp es el ejemplo de advertencia.
Aplicar mínimo privilegio en los ámbitos de herramientas
Otorgue a cada servidor el acceso mínimo necesario. Separe los ámbitos de lectura y escritura. Use credenciales con ámbito limitado en lugar de tokens de administrador compartidos. Si un servidor se ve comprometido, el daño se limita al ámbito reducido que se le otorgó.
Aislar la ejecución del servidor MCP en un sandbox
Ejecute los servidores MCP en entornos aislados —contenedores, VMs o segmentos de red separados— no directamente en el host. No comparta sistemas de archivos ni credenciales entre servidores. El sandboxing reduce el radio de impacto de “el servidor puede alcanzar todo” a “el servidor solo puede alcanzar lo que se le permitió explícitamente alcanzar”.
Registro de auditoría y observabilidad del agente
Registre identidades autenticadas, ámbitos otorgados, llamadas a herramientas, entradas y salidas sanitizadas, decisiones de política, eventos de aprobación, errores y resultados finales de las acciones. Las credenciales, los tokens y los datos personales sensibles no deben aparecer en los registros. El registro es lo que permite a un equipo reconstruir eventos, demostrar cumplimiento y detectar anomalías antes de que se conviertan en incidentes.
Humano en el bucle para acciones sensibles
Exija aprobación humana para acciones con impacto en el mundo real: escritura en bases de datos de producción, envío de emails externos, llamadas a APIs de pago, modificación de registros de clientes. Los umbrales deben basarse en la clasificación de datos —los datos públicos pueden no requerir aprobación, mientras que los datos confidenciales y restringidos requieren autorización explícita.
Marco de gobernanza empresarial para agentes de IA
Políticas, titularidad y flujos de aprobación
La gobernanza comienza con políticas escritas: quién puede aprobar un nuevo servidor MCP, qué revisión se requiere, quién es responsable de cada despliegue de agente. Sin titularidad explícita, los desarrolladores instalan servidores de forma ad-hoc y los equipos de seguridad los descubren solo después de un incidente. Un flujo de trabajo simple —proponer, revisar, aprobar, desplegar— detiene la mayoría de los riesgos de cadena de suministro antes de producción.
Controles de clasificación y residencia de datos
Clasifique los datos como públicos, internos, confidenciales o restringidos, y decida qué clases puede tocar un agente y sus servidores. Aplique controles de residencia cuando sea necesario: los datos sujetos a regulaciones de la UE o de EE. UU. no deben fluir por servidores fuera de la región apropiada.
Alineación del uso de MCP con ISO/IEC 27001:2022 y SOC 2
Los controles de seguridad MCP pueden apoyar la alineación con ISO/IEC 27001:2022 y SOC 2, pero implementar estos controles por sí solo no establece el cumplimiento. La verificación de servidores se mapea con la gestión de riesgos de proveedores; el mínimo privilegio se mapea con el control de acceso; el registro de auditoría se mapea con la monitorización; el humano en el bucle se mapea con la gestión de cambios. El cumplimiento completo requiere el sistema de gestión más amplio, la evaluación de riesgos, la auditoría interna y la certificación externa.
Patrones de arquitectura para una integración segura de IA
Servidores MCP locales frente a remotos
Los servidores locales se ejecutan en el mismo host —simples para desarrollo, pero comparten sistema de archivos y red, lo que aumenta el radio de impacto. Los servidores remotos se ejecutan por separado, pueden autenticarse y son más fáciles de auditar. Remoto no es automáticamente más seguro: un servidor remoto sin autenticación en internet abierto es peor que un servidor local correctamente configurado. Los servidores remotos autenticados suelen ser más fáciles de gobernar cuando se combinan con segmentación de red, autorización con ámbito limitado, control de egreso y registro centralizado.
OAuth y conexiones MCP autenticadas
La autorización MCP para servidores remotos basados en HTTP sigue las convenciones de OAuth 2.1. Use tokens con ámbito limitado, de corta duración y rotados, almacenados de forma segura. Valide la audiencia del token, el emisor, la expiración y los ámbitos en cada solicitud. No escriba credenciales, encabezados de autorización, tokens ni códigos de autorización en los registros. Evite los ámbitos genéricos; otorgue ámbitos con mínimo privilegio por herramienta. Los flujos de producción deben usar HTTPS. MCP no implementa OAuth de forma segura por usted —consulte la guía de autorización MCP y las mejores prácticas de seguridad MCP para los requisitos a nivel de protocolo y la guía más amplia sobre paso de tokens, riesgos de suplente confundido y minimización de ámbitos.
Segmentación de red y controles de egreso
Coloque los servidores MCP en subredes privadas con egreso controlado. Restrinja el tráfico saliente a una lista de permitidos de direcciones IP y dominios. Esto limita las rutas de exfiltración si un servidor se ve comprometido —el mismo principio que HDWEBSOFT usa para el email saliente a través de un NAT Gateway con listas de IP permitidas. Para un contexto más amplio sobre integración segura de IA, consulte nuestros servicios de desarrollo de IA y servicios de ciberseguridad.
Un flujo de trabajo de despliegue MCP con seguridad primero
Un despliegue MCP defendible sigue un flujo de trabajo repetible: auditar el servidor (confirmar el origen, revisar permisos, leer el código), limitar los permisos (mínimo privilegio por herramienta, credenciales con ámbito), aislar la ejecución (contenedor o segmento de red separado), observar el comportamiento (registrar identidades, ámbitos, llamadas a herramientas, E/S sanitizada, decisiones de política, aprobaciones, errores, resultados) y aplicar supervisión humana (aprobación para acciones sensibles según la clasificación de datos).
HDWEBSOFT aplica este flujo de trabajo en proyectos de clientes que involucran agentes de IA y datos empresariales. Como socio de desarrollo de software certificado ISO 9001 e ISO/IEC 27001, HDWEBSOFT trata la seguridad como una puerta de liberación, no como una lista de verificación final. El objetivo no es ralentizar a los equipos; es asegurar que cuando un agente llegue a producción, la capa MCP no sea lo que falle.
Conclusión
MCP es la dirección correcta para conectar agentes de IA a datos empresariales. Un protocolo compartido es mejor que una maraña de integraciones personalizadas. Pero la seguridad MCP no es automática. Cada servidor es un límite de confianza, cada ámbito de herramienta es un posible radio de impacto y cada actualización es una oportunidad para que el comportamiento cambie. Los equipos que despliegan de forma segura verifican los servidores, aplican el mínimo privilegio, aíslan la ejecución, registran lo que importa y mantienen a los humanos en el bucle.
Si su equipo está conectando agentes de IA a datos empresariales a través de MCP, el paso de mayor valor es una revisión independiente antes de producción. Solicite una Auditoría de Seguridad y Arquitectura de IA para identificar brechas en la verificación de servidores, ámbitos de herramientas, autorización, registro y gobernanza —y obtenga un plan de remediación concreto antes de que un incidente lo imponga.
Preguntas frecuentes
¿Qué es la seguridad MCP?
La seguridad MCP es la práctica de proteger los agentes de IA que se conectan a datos y herramientas externas a través del Model Context Protocol. Abarca la verificación de servidores, ámbitos de herramientas con mínimo privilegio, aislamiento de ejecución, registro de auditoría, controles con humano en el bucle y la gobernanza empresarial de integraciones basadas en MCP.
¿Cuáles son los riesgos de seguridad más comunes en servidores MCP?
Los riesgos de seguridad MCP más comunes incluyen el envenenamiento de herramientas por servidores maliciosos, la inyección de prompts transmitida a través de respuestas de servidores MCP, ataques de rug-pull y de cadena de suministro de terceros, ámbitos de herramientas excesivamente amplios y exposición de credenciales, y fallos de validación de OAuth o de tokens en despliegues autenticados.
¿Cómo aseguro un servidor MCP en producción?
Asegure un servidor MCP en producción verificando y fijando cada servidor, aplicando ámbitos de herramientas con mínimo privilegio, aislando la ejecución del servidor en un sandbox, registrando identidades autenticadas y llamadas a herramientas, aplicando aprobación con humano en el bucle para acciones sensibles y alineando el despliegue con la gobernanza empresarial y los controles de cumplimiento.
¿Es seguro el Model Context Protocol para agentes de IA empresariales?
MCP es seguro para agentes de IA empresariales cuando los equipos tratan cada servidor MCP como un nuevo límite de confianza y aplican controles de seguridad explícitos. MCP estandariza la comunicación entre clientes y servidores, pero la confianza del servidor, la autorización, la validación de salidas y los controles de ejecución siguen siendo responsabilidad del host y del cliente.
¿Cómo apoya la seguridad MCP el cumplimiento de ISO/IEC 27001:2022 o SOC 2?
Los controles de seguridad MCP pueden apoyar la alineación con ISO/IEC 27001:2022 y SOC 2 al mapear la verificación de servidores, el acceso con mínimo privilegio, el registro de auditoría y la gestión de riesgos de proveedores con categorías de control existentes. Implementar estos controles por sí solo no establece el cumplimiento; las organizaciones también deben completar el sistema de gestión más amplio y los requisitos de auditoría.
¿Cuándo deberíamos realizar una Auditoría de Seguridad y Arquitectura de IA?
Realice una Auditoría de Seguridad y Arquitectura de IA antes de promover un agente de IA a producción, después de un incidente de seguridad o casi-incidente, al conectar agentes a nuevas fuentes de datos sensibles y siempre que se introduzca un nuevo servidor MCP en un flujo de trabajo de producción.
