Los agentes de IA están pasando de la fase experimental a los flujos de trabajo de producción, y el Protocolo de Contexto de Modelo (MCP) se está convirtiendo en la capa conectiva que permite a dichos agentes acceder a datos, aplicaciones, API, repositorios y herramientas de automatización empresariales. Esto hace que MCP sea potente, pero también crítico para la seguridad. A medida que las organizaciones adoptan la IA agente, deben comprender no solo cómo MCP mejora la conectividad, sino también cómo genera nuevos desafíos de visibilidad, gobernanza y superficie de ataque.
¿Qué es MCP y por qué es importante para la IA empresarial?
El Protocolo de Contexto de Modelo es un estándar abierto que ofrece a los sistemas de IA una forma coherente de descubrir e interactuar con herramientas, fuentes de datos y sistemas empresariales externos. Una forma concisa de definirlo es esta: MCP es un plano de control estandarizado para conectar agentes de IA con el contexto y las acciones empresariales.
Esto es importante porque la IA empresarial solo resulta útil cuando puede acceder a los sistemas donde se realiza el trabajo. Un agente de soporte puede necesitar consultar una plataforma de tickets. Un asistente de programación puede necesitar inspeccionar un repositorio de código fuente. Un asistente financiero puede necesitar recuperar registros de bases de datos. Un agente de operaciones puede necesitar invocar una API interna o iniciar un flujo de trabajo.
MCP funciona como una capa de abstracción de uno a muchos. En lugar de crear integraciones independientes para cada aplicación y sistema de IA, las organizaciones pueden exponer herramientas, recursos y prompts a través de servidores MCP. Los clientes de IA pueden entonces llamar a API, consultar bases de datos, leer archivos, recuperar contexto y activar flujos de trabajo mediante un protocolo compartido.
La adopción ha sido rápida. Anthropic presentó MCP en noviembre de 2024 como un estándar abierto para conectar asistentes de IA con los sistemas donde residen los datos. Para 2025, OpenAI, Microsoft y Google ya habían anunciado o documentado la compatibilidad con MCP en sus productos y servicios.
En diciembre de 2025, Anthropic donó MCP a la Agentic AI Foundation, un fondo dirigido por la Linux Foundation y cofundado por Anthropic, Block y OpenAI, con el apoyo de Google, Microsoft, AWS, Cloudflare, Bloomberg y otros. Actualmente, MCP se considera ampliamente el estándar predeterminado emergente para la conectividad de la IA agente.
Cómo la arquitectura de MCP crea exposición de seguridad
MCP utiliza una arquitectura de cliente-servidor. Una aplicación de IA actúa como host y ejecuta uno o más clientes MCP. Estos clientes se conectan a servidores MCP, que exponen herramientas, recursos y prompts. Un servidor puede proporcionar acceso a un repositorio Git, una base de datos, una aplicación SaaS, una cuenta en la nube o una API interna.
Esto se asemeja a un modelo de API tradicional, pero MCP cambia el patrón de interacción. Los servidores MCP no se limitan a devolver datos estáticos. Describen las herramientas disponibles a los sistemas de IA, influyen en el contexto del agente y ejecutan acciones en nombre de los clientes conectados. En los flujos de trabajo de agentes, el modelo puede decidir cuándo y cómo invocar esas herramientas basándose en las instrucciones y el contexto.
Eso crea vectores de ataque que difieren de los riesgos tradicionales de las API. Un usuario da una instrucción, un agente de IA la interpreta, un cliente MCP selecciona una herramienta, un servidor MCP ejecuta una acción y los sistemas posteriores responden. Cada transferencia puede introducir una brecha de política, validación o visibilidad.
Los servidores MCP también suelen ser intermediarios privilegiados. Un único servidor puede situarse entre un agente de IA y gestores de código fuente, bases de datos, servicios en la nube, API internas, sistemas de archivos o herramientas de observabilidad. Si ese servidor tiene permisos excesivos o está mal protegido, se convierte en un objetivo de alto valor.
El protocolo fue diseñado para ser flexible, y esa flexibilidad ha ayudado a su adopción. Pero también significa que muchos controles quedan en manos de quienes lo implementan. La autenticación, la autorización, la validación de entradas, la aprobación de herramientas, la gestión de sesiones, el registro y la aplicación de políticas no se aplican de forma uniforme a nivel de protocolo. Por lo tanto, dos servidores MCP que realicen funciones similares pueden tener posturas de seguridad completamente diferentes.
Principales riesgos de seguridad de MCP a los que se enfrentan las organizaciones hoy en día
El riesgo de seguridad de MCP abarca la identidad, la autorización, la integridad de los prompts, la gestión de sesiones, la gestión del contexto y la exposición de la cadena de suministro de software. Cuatro áreas requieren atención inmediata.
La primera es el control de acceso. MCP no requiere autenticación ni control de acceso basado en roles a nivel de protocolo. Las implementaciones sólidas pueden añadir estos controles, pero las implementaciones iniciales pueden depender de supuestos de confianza locales, credenciales compartidas o un acceso excesivamente permisivo a las herramientas. Si un servidor MCP puede leer repositorios, consultar bases de datos o llamar a API internas, un control de acceso débil en la capa MCP puede convertirse en un control de acceso débil en todos los sistemas conectados.
La segunda es el envenenamiento de herramientas y inyección de prompts. En un ataque de envenenamiento de herramientas, un servidor MCP malicioso o comprometido inserta instrucciones ocultas en las descripciones, metadatos, prompts o resultados de las herramientas. Un agente de IA puede interpretar esas instrucciones como contexto legítimo y realizar acciones no deseadas, como filtrar datos, ignorar instrucciones de seguridad o enviar secretos a otra herramienta. La inyección de prompts genera un riesgo relacionado cuando los agentes procesan contenido no confiable proveniente de tickets, documentos, repositorios, páginas web o resultados de herramientas.
El tercero es la debilidad de tokens y sesiones. Muchas implementaciones de MCP dependen de tokens de portador (bearer tokens), permisos delegados, flujos de OAuth o patrones de transferencia de tokens. Los tokens de larga duración, los alcances amplios, la revocación deficiente y la gestión débil del ciclo de vida de las sesiones pueden permitir que los atacantes se desplacen desde la capa de MCP hacia sistemas secundarios. MCP también crea oportunidades para ataques de "diputado confundido", donde se engaña a un componente confiable para que utilice su autoridad de una manera que el usuario no pretendía.
El cuarto es la serialización de contexto insegura. MCP intercambia habitualmente objetos estructurados a través de JSON-RPC. Sin una aplicación estricta de esquemas y aislamiento, los riesgos de cargas útiles malformadas, deserialización insegura, recorrido de rutas (path traversal), inyección y ejecución de comandos pueden llegar a herramientas o entornos de ejecución privilegiados.
El problema de descubrimiento e inventario de servidores MCP
Los servidores MCP se están convirtiendo en una nueva forma de TI en la sombra. Son fáciles de implementar para los desarrolladores, a menudo se crean con marcos de trabajo de código abierto y pueden ejecutarse en estaciones de trabajo, contenedores, sistemas de CI/CD o entornos en la nube. Un desarrollador puede conectar rápidamente un asistente de IA a archivos, repositorios, credenciales, registros, bases de datos o API internas sin establecer un proceso formal de revisión de seguridad.
Eso genera un problema de visibilidad. Sin un descubrimiento continuo de servidores MCP, los equipos de seguridad no pueden responder preguntas básicas como: ¿Qué servidores existen? ¿Dónde se ejecutan? ¿Quién es su propietario? ¿Qué herramientas exponen? ¿Qué agentes los utilizan? ¿A qué datos pueden acceder? ¿Están autenticados? ¿Están autorizados? ¿Han cambiado los permisos?
Una auditoría única no será suficiente. Los entornos MCP cambian a medida que los desarrolladores prueban marcos de trabajo, añaden herramientas, actualizan credenciales o amplían permisos. Los equipos de seguridad necesitan un inventario en tiempo real que capture la ubicación, el propietario, la exposición de herramientas, el estado de autenticación, el alcance de acceso, el comportamiento en tiempo de ejecución y el estado de autorización en todos los puntos finales y entornos en la nube.
Esto debería resultar familiar para los equipos que han lidiado con API en la sombra: puntos finales desconocidos, propiedad poco clara, exposición de datos sin documentar y controles inconsistentes. Los servidores MCP crean un desafío similar, pero con una complicación añadida. No solo exponen datos a las aplicaciones, sino que exponen capacidades a agentes de IA que pueden razonar, elegir herramientas e iniciar acciones.
Incidentes de seguridad de MCP en el mundo real que ilustran el riesgo
MCP es todavía relativamente nuevo, pero la investigación documentada ya muestra por qué los equipos de seguridad necesitan controles antes de una implementación a gran escala.
Los investigadores han demostrado ataques de inyección de parámetros de herramientas contra agentes MCP de código abierto, mostrando cómo las entradas no saneadas pueden exponer datos confidenciales del servidor o influir en la ejecución de la herramienta. Estos casos destacan dos modos de fallo comunes: las entradas se consideran confiables demasiado pronto y el registro (logging) es insuficiente para reconstruir lo sucedido a posteriori.
Los escenarios de MCP relacionados con GitHub también han mostrado el peligro de los permisos excesivos en los repositorios. En una clase de ataques, una herramienta conectada a MCP con acceso amplio a repositorios podía leer contenido de un repositorio privado y escribirlo en uno público sin que el usuario comprendiera completamente la ruta de la acción. El problema es la frontera difusa entre la intención del usuario, los permisos de la herramienta y las acciones de la API secundaria.
La vulnerabilidad del Inspector MCP de Anthropic ofreció otra advertencia. El Inspector MCP es una herramienta de desarrollo para probar y depurar servidores MCP. En 2025, los investigadores informaron sobre la CVE-2025-49596, una vulnerabilidad crítica de ejecución remota de código que involucraba ataques basados en navegador contra entornos de desarrollo locales. Los informes describieron cómo un sitio web malicioso podía activar comandos en la máquina de un desarrollador bajo ciertas condiciones, lo que provocó un parche en la versión 0.14.1. La lección para las empresas es directa: incluso las herramientas MCP proporcionadas por proveedores requieren revisión de seguridad, gestión de versiones y uso controlado.
Mejores prácticas de seguridad de MCP para la implementación empresarial
Las organizaciones deben tratar a MCP como una infraestructura de conectividad de producción, no como una comodidad para el desarrollador. El primer requisito es la autenticación y autorización para cada interacción con MCP. Los servidores MCP no autenticados no deberían tener acceso a herramientas, datos o flujos de trabajo confidenciales. Cuando se utilice OAuth, siga las directrices de OAuth 2.1, aplique el consentimiento explícito por cliente, restrinja los alcances, vincule los tokens a las audiencias previstas y evite la transferencia innecesaria de tokens.
El principio de menor privilegio debe aplicarse en cada capa: usuario, agente, cliente, servidor, herramienta y sistema interconectado. Un servidor diseñado para leer documentación no debería tener acceso de escritura a repositorios de código fuente. Un servidor utilizado para análisis no debería poder modificar la infraestructura en la nube. Los permisos de las herramientas deben revisarse siempre que se actualicen los servidores o se añadan nuevas capacidades.
Aísle los servidores MCP en entornos controlados (sandboxes) para reducir el impacto de ataques como el recorrido de rutas, la inyección de comandos, la ejecución arbitraria de código, la escalada de privilegios y el agotamiento de recursos. Los límites del sistema de archivos, el aislamiento de contenedores, las restricciones de tiempo de ejecución y los controles de salida de red pueden reducir significativamente el radio de impacto.
Se debe aplicar una validación estricta del esquema JSON-RPC antes de que las solicitudes lleguen a los entornos de ejecución. Los parámetros de las herramientas deben ser saneados, las salidas deben tratarse como no confiables y la deserialización solo debe ocurrir en contextos controlados.
El registro de auditoría integral también es esencial. Los equipos de seguridad necesitan una secuencia rastreable de la actividad a lo largo de las sesiones, incluyendo quién inició la solicitud, qué agente y cliente estuvieron involucrados, qué servidor recibió la llamada, qué herramienta se invocó, qué decisión de autorización se tomó, qué sistema interconectado se vio afectado y si ocurrió alguna violación de RBAC. Los registros útiles deben incluir datos relevantes de encabezados HTTP, eventos de autorización, registros de ejecución de herramientas, identificadores de sesión y resultados anómalos.
Por último, evalúe los servidores MCP de terceros antes de su uso en producción. Los servidores de la comunidad deben analizarse como si fueran paquetes de terceros, imágenes de contenedores o dependencias de código abierto. Revise el código fuente siempre que sea posible, analice si existe comportamiento malicioso, comprenda los permisos requeridos, valide el comportamiento de autenticación y realice pruebas en un entorno que no sea de producción antes de conectarlos a sistemas sensibles.
Cómo construir un programa de gobernanza de MCP desde cero
La seguridad de MCP no puede depender de la disciplina individual de los desarrolladores. Las empresas necesitan una gobernanza que convierta la adopción segura en el estándar predeterminado.
Comience con el descubrimiento. Los equipos de seguridad necesitan un inventario completo de los servidores MCP en endpoints, estaciones de trabajo de desarrolladores, instancias en la nube, contenedores, sistemas CI/CD e infraestructura de producción. Una vez descubiertos, clasifique cada servidor según el riesgo basándose en la sensibilidad de los datos, las herramientas expuestas, la postura de autenticación, el alcance del acceso, la exposición externa, la importancia para el negocio y el estado de aprobación.
Los controles deben aplicarse en función del riesgo. Los servidores experimentales de bajo riesgo pueden requerir solo medidas básicas y políticas de caducidad. Los servidores de alto riesgo pueden exigir una autenticación robusta, una autorización estricta, aislamiento, flujos de trabajo de aprobación, monitoreo continuo y una gestión formal de cambios.
El monitoreo continuo mantiene el programa actualizado. Este debe detectar nuevos servidores MCP casi en tiempo real, distinguir las implementaciones autorizadas de las no autorizadas, identificar cambios en la exposición de herramientas y señalar comportamientos que sugieran un uso indebido o una vulneración.
La gobernanza de MCP también debe conectarse con los programas de seguridad empresarial existentes. Los equipos de IAM necesitan entender cómo se autorizan los usuarios, agentes, clientes y servidores. Los equipos de EDR deben visualizar las herramientas MCP en los endpoints. Los equipos de seguridad en la nube deben rastrear los servidores MCP en sus entornos. Los equipos de seguridad de API deben monitorear las API interconectadas que los agentes llaman a través de MCP. Los equipos de SIEM y respuesta a incidentes necesitan suficiente telemetría para reconstruir la actividad impulsada por los agentes.
Aquí es donde la seguridad de MCP se conecta directamente con la seguridad de las API. Los agentes de IA generan impacto empresarial al llamar a herramientas, API, bases de datos y flujos de trabajo. MCP se sitúa en medio de esa ruta de acción. Asegurarlo requiere visibilidad tanto en la capa de MCP como en las API y sistemas a los que accede.
La seguridad de MCP comienza con la visibilidad
Cada cambio tecnológico importante crea una nueva infraestructura que los equipos de seguridad terminan teniendo que gobernar. En la adopción de la nube, fueron las cuentas no gestionadas. En las API, fueron las API en la sombra (shadow APIs). Para los agentes de IA, los servidores MCP se están convirtiendo rápidamente en el próximo desafío de visibilidad.
El riesgo no es MCP en sí mismo. El protocolo resuelve un problema real al proporcionar a los sistemas de IA una forma estandarizada de interactuar con aplicaciones empresariales, fuentes de datos y flujos de trabajo. El desafío es que las organizaciones están implementando servidores MCP mucho más rápido de lo que establecen controles a su alrededor.
Los equipos de seguridad no pueden proteger lo que no pueden ver. Antes de poder evaluar modelos de autenticación, revisar permisos o detectar intentos de manipulación de herramientas, necesitan saber qué servidores MCP existen, a qué sistemas pueden acceder y qué agentes de IA los están utilizando.
A medida que los agentes de IA se integran en los procesos empresariales, los servidores MCP se parecerán cada vez más a las API: una infraestructura de conectividad crítica que requiere descubrimiento, supervisión y gobernanza continuos. Las organizaciones que establezcan visibilidad ahora estarán en una posición mucho más sólida que aquellas que intenten proteger un ecosistema MCP cuya existencia desconocían. Obtenga una evaluación de superficie para encontrar todos los servidores MCP en su infraestructura de IA.
Preguntas frecuentes sobre la seguridad de MCP
¿Qué diferencia a la seguridad de MCP de la seguridad de API estándar?
La seguridad de API tradicional se centra en interacciones predecibles entre cliente y servidor. MCP añade una capa de decisión de IA, descubrimiento dinámico de herramientas, autoridad delegada y contexto que puede influir en el comportamiento del agente. Esto introduce riesgos como el envenenamiento de herramientas, la inyección de prompts, ataques de diputado confundido y acciones no deseadas por parte del agente.
¿Cómo encuentro todos los servidores MCP que se ejecutan en mi organización?
Utilice el descubrimiento continuo en endpoints, entornos en la nube, estaciones de trabajo de desarrolladores, contenedores, sistemas CI/CD e infraestructura de producción. El inventario debe registrar la ubicación, el propietario, las herramientas expuestas, el estado de autenticación, los sistemas conectados, el alcance del acceso y el estado de aprobación.
¿Qué es el envenenamiento de herramientas en MCP y cómo funciona?
El envenenamiento de herramientas ocurre cuando un servidor MCP malicioso o comprometido oculta instrucciones en descripciones de herramientas, metadatos, prompts o resultados. Un agente de IA puede tratar esas instrucciones como contexto legítimo y realizar acciones no deseadas.
¿Requiere MCP autenticación de forma predeterminada?
No. MCP no exige autenticación ni RBAC a nivel de protocolo. Las organizaciones deben implementar controles de identidad, autorización, consentimiento, tokens y políticas para cualquier servidor MCP conectado a datos o acciones confidenciales.
¿Qué es el ataque de diputado confundido en MCP y cómo puedo prevenirlo?
Un ataque de diputado confundido ocurre cuando un componente MCP de confianza utiliza su autoridad de una manera que el usuario no pretendía. Prevéngalo con consentimiento explícito, alcances de OAuth restringidos, tokens vinculados a la audiencia, comprobaciones de autorización por herramienta y decisiones de política que consideren al usuario, al agente, al cliente, al servidor, a la herramienta y a la acción solicitada.
¿Cómo debo evaluar un servidor MCP de terceros antes de usarlo en producción?
Evalúelo como lo haría con un paquete de terceros, una imagen de contenedor o una dependencia de código abierto. Revise el código fuente cuando sea posible, analice en busca de código malicioso, comprenda los permisos requeridos, valide el comportamiento de autenticación, pruebe en un entorno que no sea de producción y supervise el comportamiento antes de conectarlo a sistemas confidenciales.