Cloudflare detecta los «MCP en la sombra»: el nuevo riesgo de seguridad de los agentes de IA
Los agentes de inteligencia artificial están empezando a conectarse directamente con bases de datos, repositorios, herramientas de desarrollo y aplicaciones empresariales mediante Model Context Protocol (MCP). El problema aparece cuando esas conexiones se crean sin pasar por los controles de seguridad de la organización.
Cloudflare ha añadido a su plataforma Zero Trust mecanismos específicos para detectar tráfico MCP, identificar servidores no autorizados y bloquear conexiones directas. La compañía denomina a este fenómeno shadow MCP, una evolución del conocido shadow IT que puede convertirse en uno de los nuevos problemas de seguridad asociados a la IA agéntica.
MCP convierte un chatbot en algo capaz de actuar
MCP es un protocolo abierto que estandariza la comunicación entre una aplicación de IA y herramientas externas. En lugar de desarrollar una integración distinta para cada modelo, un servidor MCP puede publicar herramientas y recursos que diferentes clientes compatibles utilizan mediante una interfaz común.
Un agente podría, por ejemplo, consultar GitHub, leer documentación interna, buscar incidencias, recuperar información de una base de datos o iniciar determinadas acciones sobre sistemas corporativos.
En el glosario de inteligencia artificial de Tecnoic ya explicamos esta diferencia: un chatbot principalmente responde, mientras que un agente puede utilizar herramientas y ejecutar acciones.
Ahí está precisamente el problema de seguridad. Cuando entregamos a un agente una conexión MCP, no solo le proporcionamos información adicional: potencialmente le estamos concediendo capacidades operativas.
La documentación oficial de seguridad de MCP recoge mecanismos de autorización, validación de tokens y diferentes riesgos que deben tener en cuenta clientes y servidores. Es decir, MCP no elimina la necesidad de controlar identidades y permisos: la hace todavía más relevante.
Qué es el «shadow MCP»
El concepto recuerda al shadow IT: aplicaciones SaaS, servicios cloud o herramientas instaladas por empleados sin conocimiento del departamento de TI.
Con MCP ocurre algo similar, pero las consecuencias pueden ser diferentes.
Un empleado puede encontrar un servidor MCP útil, añadirlo a un cliente compatible y empezar a utilizar sus herramientas. Para el departamento de seguridad, esa conexión puede pasar inicialmente desapercibida.
En su explicación sobre los nuevos controles de seguridad para MCP, Cloudflare distingue además entre shadow MCP y otro escenario denominado portal bypass.
En el primer caso, el servidor ni siquiera está autorizado por la empresa. En el segundo, el servidor sí está aprobado, pero el usuario se conecta directamente a su dirección original en lugar de utilizar el punto de acceso corporativo establecido.
Es decir, la conexión directa puede saltarse controles intermedios como políticas de acceso, prevención de pérdida de datos o registros específicos sobre las herramientas utilizadas.
Es el mismo cambio de seguridad que estamos viendo en otros ámbitos de la IA. Como explicamos al analizar la seguridad de los agentes de IA, ya no basta con controlar quién accede a un sistema: también hay que determinar qué puede ejecutar cada agente, con qué identidad y sobre qué recursos.
Cómo detecta Cloudflare el tráfico MCP
Hasta ahora, localizar estas conexiones podía requerir buscar dominios que contuvieran referencias a MCP, determinadas rutas URL o patrones propios de JSON-RPC.
El nuevo mecanismo intenta detectar directamente características del protocolo.
En conexiones MCP mediante Streamable HTTP, después de la inicialización el cliente utiliza la cabecera MCP-Protocol-Version. Cloudflare Gateway puede inspeccionar este tipo de características y clasificar la petición como tráfico MCP.
Según el registro de cambios de Cloudflare One, los administradores pueden utilizar el selector:
experimental.is_mcp == true
Con él es posible construir políticas para permitir, bloquear o controlar tráfico MCP sin mantener manualmente una lista de todos los servidores conocidos. Cloudflare indica que esta capacidad se encuentra actualmente en beta.
La compañía también ha incorporado un panel específico desde el que consultar volumen de peticiones MCP, usuarios, servidores detectados y conexiones que no están atravesando los puntos de acceso corporativos definidos por la organización.
La detección tiene límites importantes
Esto no significa que Cloudflare pueda descubrir automáticamente cualquier agente ejecutándose dentro de una empresa.
Para analizar una conexión HTTPS, el tráfico debe atravesar la infraestructura de Gateway y estar sometido a los mecanismos de inspección correspondientes. La propia explicación técnica de Cloudflare sobre la detección MCPadvierte de estas limitaciones.
Quedan fuera, entre otros casos, servidores MCP locales que utilizan stdio, conexiones realizadas desde redes no gestionadas o tráfico que no atraviesa el gateway corporativo.
Es una distinción importante porque MCP admite arquitecturas muy diferentes. Un servidor ejecutándose localmente dentro del ordenador puede no generar siquiera una conexión HTTP susceptible de ser observada por un gateway de red.
La nueva función debe entenderse, por tanto, como un mecanismo para supervisar principalmente MCP remoto, no como un inventario universal de todos los agentes y herramientas existentes en una organización.
De bloquear MCP a aplicar Zero Trust a los agentes
La alternativa a bloquear todas las conexiones consiste en canalizarlas a través de puntos controlados.
Cloudflare propone para ello sus MCP Server Portals, que funcionan como una entrada centralizada hacia servidores MCP aprobados. Desde esos portales pueden aplicarse políticas de identidad y acceso, limitar herramientas, generar registros y combinar el tráfico con otros controles corporativos.
La arquitectura encaja directamente con los principios de Zero Trust que explicamos en Tecnoic: no considerar confiable una conexión simplemente porque procede de un empleado o dispositivo corporativo, sino verificar qué identidad solicita acceso, a qué recurso y bajo qué política.
Aplicado a los agentes surge una nueva pregunta: ¿debemos tratar a un agente de IA como otra identidad dentro de la arquitectura de seguridad?
Cada vez tiene más sentido hacerlo.
Por qué importa también a las empresas españolas
No hay una función específica para España en este anuncio, pero el problema afecta directamente a cualquier organización española que empiece a desplegar agentes conectados a servicios corporativos.
El riesgo aumenta cuando MCP da acceso a código fuente, documentación interna, sistemas de soporte, infraestructura cloud, CRM o información personal. Bloquear toda conexión MCP sería una solución simple, pero probablemente poco práctica; permitir cualquier servidor externo tampoco parece razonable.
El modelo que empieza a perfilarse se parece más a una combinación de servidores autorizados, identidad verificable, mínimo privilegio, DLP y auditoría de cada acción.
MCP está resolviendo uno de los principales problemas técnicos de los agentes: cómo conectarlos de forma estándar con el resto del software. Precisamente por eso está creando otro desafío. Cuando conectar una IA a una herramienta se vuelve muy sencillo, controlar esas conexiones pasa a ser parte de la infraestructura de ciberseguridad.
¿Deberían las empresas permitir que los empleados añadan libremente servidores MCP? ¿O acabaremos tratando cada herramienta de un agente como hoy tratamos una aplicación corporativa?
