MCP: Gobierno, MCPOps y Seguridad del Model Context Protocol

¿Qué es MCP?

Model Context Protocol (MCP) es un estándar abierto basado en JSON-RPC, desarrollado por Anthropic, que permite a los Large Language Models (LLMs) interactuar de forma estandarizada con herramientas externas y fuentes de datos. Antes de MCP, cada integración entre un LLM y un sistema externo requería implementaciones específicas y no interoperables. MCP resuelve este problema proporcionando un protocolo común que permite a cualquier aplicación compatible comunicarse con servidores MCP sin necesidad de integraciones ad-hoc.

Un MCP se compone de un Host (la herramienta final: VS Code, Claude, Cursor…), un MCP Client que se crea en el host (uno por cada servidor), un MCP Server local o remoto que ejecuta las tools, y el LLM que orquesta la conversación. A través de este protocolo se exponen tools (acciones ejecutables), resources (datos o ficheros de contexto) y prompts (plantillas preestablecidas).

Por qué los MCPs necesitan gobierno

La adopción masiva de la IA ha alcanzado también a los MCPs. Diferentes roles e instituciones están creando y utilizando MCPs sin considerar los riesgos asociados. Esta situación replica problemas históricos: al igual que ocurrió con las APIs REST o los microservicios en sus inicios, la falta de estándares y buenas prácticas conduce a implementaciones inseguras y difíciles de mantener. En MCP este problema se amplifica por dos factores: la integración con LLMs introduce nuevos vectores de ataque (prompt injection, exposición de datos sensibles) y la accesibilidad de la tecnología permite que perfiles menos técnicos desplieguen integraciones sin los conocimientos de seguridad necesarios.

Los MCPs no deben tratarse como meros wrappers de APIs. Cada MCP server es un producto de software independiente, con su propia lógica, seguridad y procesos de gobierno, y como tal debe gestionarse.

Ciclo de vida, ownership e inventario

Un MCP recorre los mismos estados que cualquier otro producto: Diseño → Desarrollo → Revisión → Producción → Deprecado → Retirado. Cada uno debe tener un owner claramente definido: cuando existe una relación 1:1 con una API, el owner de la API puede asumir esa responsabilidad; cuando integra múltiples fuentes, debe designarse un propietario específico que coordine los sistemas involucrados. A esto se suman un inventario centralizado (internos y terceros aprobados), versionado semántico (MAJOR.MINOR.PATCH) que refleje los cambios en las dependencias y un proceso de aprobación multidisciplinar que evalúe utilidad, calidad técnica, seguridad y cumplimiento.

MCPOps: CI/CD para MCPs

MCPOps es el conjunto de prácticas y herramientas que permiten construir, probar, desplegar y mantener MCPs de forma sistemática y automatizada, siguiendo principios análogos a DevOps o GitOps sobre pipelines de CI/CD. Un pipeline típico cubre la construcción (manual, generación automática desde OpenAPI o híbrida), la validación de calidad (linting, análisis estático, validación de esquemas JSON, documentación), los análisis de seguridad sobre código y librerías, el testing unitario, de integración/contrato y de carga (considerando el consumo de tokens del LLM), el despliegue en contenedores, API Managers con soporte MCP o serverless, y la observabilidad completa: logging, métricas, tracing, alertas, dashboards y auditabilidad.

Seguridad y exposición

Los principales riesgos a cubrir son la exposición de datos sensibles, autenticación, autorización granular, validación de entrada y salida, gestión de secrets, rate limiting y aislamiento del acceso a sistemas externos. Una pieza clave es el AI/MCP Gateway, un proxy inteligente entre los clientes y los MCP servers que centraliza autenticación y autorización unificadas, DLP y detección de PII, rate limiting, content filtering, logging consolidado y enrutamiento inteligente entre múltiples MCPs.

En cuanto a exposición, un MCP puede publicarse localmente o de forma remota vía HTTP/SSE. La mejor práctica es que consuma APIs bien diseñadas en lugar de acceder directamente a bases de datos: las APIs ofrecen contratos estables y versionados, validaciones propias y facilitan el testing. Cuando se requiere acceso a ficheros conviene definir una whitelist de directorios permitidos, priorizar solo lectura, validar rutas para evitar directory traversal y aislar con chroot.

MCPs de terceros: evaluación y mitigación

Usar MCPs de terceros introduce riesgos adicionales: acceso directo al contexto del LLM, ejecución en entornos potencialmente privilegiados, acciones en nombre del usuario y nuevos vectores de ataque como prompt injection o data exfiltration. Antes de adoptarlos hay que evaluar qué tools exponen, qué datos necesitan como input, a qué recursos externos se conectan, qué permisos requieren en el host y qué condiciones de licenciamiento aplican.

Para mitigar estos riesgos: sandboxing con contenedores de recursos limitados, sin acceso por defecto al host y aislamiento de red; monitoreo de comportamiento con alertas por conexiones anómalas, detección de consumo excesivo y análisis de outputs para detectar exfiltración; restricción de uso mediante catálogo interno de MCPs aprobados y un proceso transparente para proponer nuevos; y formación a los equipos sobre los riesgos de los MCPs no verificados.

Los MCPs abren un universo de posibilidades para conectar LLMs con el mundo real, pero requieren que las organizaciones apliquen los mismos principios de gobierno, operación y seguridad que ya han aprendido con las APIs —y algunos nuevos específicos para la era de los agentes.