Model Context Protocol (MCP) estandariza cómo las aplicaciones y los agentes de IA descubren y utilizan recursos, prompts y herramientas externas. Reduce la necesidad de integraciones a medida, pero no crea confianza automática. Un servidor MCP puede exponer correo, archivos, bases de datos o acciones críticas del negocio; por eso debe tratarse como una API privilegiada, con identidad, autorización, permisos mínimos, validación, registros y aprobación humana.
Qué es MCP
MCP define una arquitectura cliente-servidor para conectar aplicaciones de IA con datos y capacidades. Sus elementos habituales son:
- Host: la aplicación que ejecuta la experiencia de IA.
- Cliente MCP: mantiene la conexión con un servidor.
- Servidor MCP: expone las capacidades.
- Resources: contenido consultable.
- Tools: operaciones ejecutables.
- Prompts: plantillas o flujos reutilizables.
El protocolo normaliza la comunicación, pero la organización sigue siendo responsable de qué servidor instala, qué datos expone y qué acciones autoriza.
MCP frente a una API convencional
| Criterio | MCP | API directa |
|---|---|---|
| Descubrimiento | Capacidades descritas al cliente | Documentación e integración específicas |
| Orientación | Aplicaciones y agentes de IA | Cualquier software |
| Contexto | Recursos, herramientas y prompts | Endpoints y datos |
| Riesgo | Selección dinámica por modelo | Flujo más determinista |
| Control | Requiere política adicional | Puede estar embebido en la aplicación |
MCP no reemplaza la API subyacente: suele envolverla y añade una capa que también debe gobernarse.
Inventario de servidores
Cada servidor MCP necesita una ficha propia con, al menos:
- Propietario y repositorio.
- Versión y proveedor.
- Transporte y ubicación.
- Recursos, herramientas y prompts que expone.
- Sistemas de destino.
- Datos y su clasificación.
- Credenciales y scopes.
- Usuarios y agentes permitidos.
- Logs y retención.
- Actualización y retirada.
Los servidores locales instalados por usuarios también cuentan en este inventario. Debe bloquearse la conexión a servidores no aprobados cuando el riesgo lo justifique.
Modelo de confianza
No se confía en un servidor por aparecer en un registro, ni en un cliente por ser corporativo. Deben autenticarse las partes, validar la versión y limitar la capacidad expuesta.
Una amenaza puede comprometer cualquier eslabón de la cadena:
- El servidor MCP.
- El paquete o la dependencia.
- El cliente o el host.
- El modelo que decide qué herramientas usar.
- El contenido recuperado.
- El sistema final.
- Las credenciales delegadas.
El modelo de amenazas debe cubrir toda la cadena, no solo el servidor.
Autorización
La documentación oficial de MCP define la autorización para transportes HTTP siguiendo las convenciones de OAuth 2.1. La implementación debe evitar tokens estáticos de amplio alcance.
Los principios básicos son:
- Autenticación de usuario y de servicio.
- Tokens con la audiencia correcta.
- Scopes mínimos.
- Vida corta y rotación.
- Consentimiento claro.
- Revocación y baja.
- Separación de entornos.
- No reenviar tokens a destinos no autorizados.
En transporte STDIO, las credenciales suelen proceder del entorno. Deben aislarse y no exponerse nunca en prompts, logs o archivos de configuración inseguros.
Permisos por herramienta
Un servidor con acceso a correo no debería exponer «gestionar correo» como un permiso único. Conviene separar, como mínimo:
- Buscar.
- Leer.
- Crear borrador.
- Enviar.
- Borrar.
- Administrar reglas.
Cada herramienta debe definir sus argumentos, límites, destinatarios, volumen y necesidad de aprobación. Las operaciones de lectura no implican permiso de escritura.
Validación determinista
El modelo puede proponer una llamada, pero debe ser código determinista el que valide, entre otros aspectos:
- Esquema y tipos.
- Identidad y alcance.
- Recurso permitido.
- Reglas de negocio.
- Límites de cantidad.
- Contexto y entorno.
- Idempotencia.
- Necesidad de aprobación.
Una instrucción contenida en un documento o en la respuesta de una herramienta nunca puede ampliar permisos por sí misma.
Riesgos específicos
Confused deputy
Un servidor utiliza su propia autoridad para ejecutar una solicitud que el usuario no podría realizar directamente. Se mitiga vinculando token, usuario, recurso y propósito de la llamada.
Token passthrough
Reutilizar el token recibido en servicios downstream puede romper la audiencia y el control del acceso. El servidor debe usar flujos adecuados y credenciales específicas para cada destino.
Prompt injection indirecta
Un recurso contiene instrucciones maliciosas que inducen al agente a llamar herramientas que no debería. El contenido recuperado se trata siempre como dato no confiable y cualquier acción derivada requiere política externa.
Tool poisoning
La descripción o el comportamiento de una herramienta pueden engañar al modelo. Por eso las herramientas solo deben permitirse desde un catálogo firmado o aprobado, y cualquier cambio debe revisarse.
SSRF y acceso local
Un servidor que acepta URLs o rutas puede acabar accediendo a la red interna o a archivos que no debería. Se mitigan con listas permitidas, normalización de entradas y aislamiento.
Supply chain
Las implementaciones de referencia no son necesariamente aptas para producción. Deben revisarse el código, las dependencias, la firma, el SBOM, las actualizaciones y la seguridad general del paquete.
Enterprise-managed authorization
La extensión de autorización gestionada por empresa busca evitar que cada persona autorice servidores por su cuenta, sin una política central. Permite integrar la identidad corporativa, el onboarding, el offboarding y controles consistentes en toda la organización, algo que encaja con un enfoque de gateway corporativo de IA que centralice el gobierno de estas conexiones.
La organización debería centralizar:
- El catálogo de servidores.
- Los proveedores de identidad.
- Las políticas y los scopes.
- Las aprobaciones.
- La revocación.
- La observabilidad.
- Las excepciones.
Aprobación humana
No todas las herramientas necesitan confirmación humana. La matriz de control debe considerar el impacto y la reversibilidad de cada acción:
| Acción | Control |
|---|---|
| Leer dato permitido | Automática con log |
| Crear borrador | Automática o revisión posterior |
| Enviar mensaje | Confirmación contextual |
| Modificar registro crítico | Aprobación previa |
| Pago, borrado o privilegio | Doble control o fuera de alcance |
La pantalla de aprobación debe mostrar siempre la acción, los argumentos, el sistema afectado, las consecuencias y la fuente que la originó.
Registros
La traza de cada llamada debe incluir:
- Usuario, agente y servidor.
- Versión.
- Herramienta invocada.
- Argumentos protegidos.
- Política aplicada.
- Aprobación.
- Respuesta.
- Error y reintento.
- Latencia y coste.
- Identificador correlacionado.
Los datos sensibles deben minimizarse en el registro. El log tiene que permitir investigar un incidente sin convertirse en una copia indiscriminada de la información.
Disponibilidad e idempotencia
Los timeouts y los reintentos pueden duplicar acciones. Por eso cada operación de escritura debe utilizar una clave idempotente, además de establecer límites de llamadas, circuit breakers y mecanismos de compensación.
Si el servidor cae, el agente debe degradar con seguridad: informar de la incidencia, no inventar un resultado y no recurrir a una herramienta alternativa con más privilegios.
Ciclo de vida
Admisión
Revisión del propietario, el código, el proveedor, los datos, las herramientas y las amenazas del servidor.
Piloto
Entorno de pruebas, cuentas sintéticas y permisos limitados a lectura.
Producción
Versión fijada, monitorización, SLA y plan de rollback.
Cambio
Revisión de cualquier nueva herramienta, scope o dependencia antes de aprobarla.
Retirada
Revocar tokens, eliminar la configuración, conservar evidencia y confirmar el borrado.
Pruebas
Antes de dar por validado un servidor MCP conviene comprobar, al menos:
- Usuario sin permiso.
- Token de audiencia incorrecta.
- Herramienta manipulada.
- Argumentos fuera de rango.
- Recurso con prompt injection.
- URL interna o ruta transversal.
- Servidor caído.
- Respuesta malformada.
- Llamada duplicada.
- Proceso de offboarding.
Este tipo de pruebas adversariales es precisamente el terreno de un ejercicio de red teaming de IA aplicado a la capa de agentes y servidores MCP.
Plan de 60 días
Días 1 a 15
Inventario, caso de uso acotado y modelo de amenazas.
Días 16 a 30
Autorización, scopes, catálogo y políticas.
Días 31 a 45
Validación, aprobación, logs y pruebas adversariales.
Días 46 a 60
Piloto, métricas, correcciones y producción limitada.
Errores frecuentes
- Instalar servidores comunitarios sin revisión.
- Usar tokens personales de amplio alcance.
- Confiar en las descripciones de las herramientas.
- Mezclar permisos de lectura y escritura.
- Aprobar acciones sin mostrar los argumentos.
- Reenviar tokens a sistemas downstream.
- No validar URLs ni rutas.
- Registrar secretos en los logs.
- Reintentar llamadas sin idempotencia.
- No revocar accesos al dar de baja un servidor o un usuario.
Checklist
- Catálogo y propietario definidos.
- Versiones y código revisados.
- Autorización y audiencia correctas.
- Scopes y herramientas mínimas.
- Validación fuera del modelo.
- Aprobación según el impacto.
- Aislamiento de secretos y de red.
- Logs correlacionados y minimizados.
- Idempotencia y límites establecidos.
- Pruebas de inyección y de supply chain.
- Revocación y retirada previstas.
Preguntas frecuentes
¿MCP es seguro por defecto?
No. Proporciona mecanismos y una especificación, pero la seguridad real depende de la autorización, la implementación y las políticas que aplique cada organización.
¿Sustituye a OAuth?
No. Para transportes HTTP, MCP define un marco de autorización alineado con OAuth 2.1, no una alternativa a este.
¿Puede usarse solo para lectura?
Sí, y es un buen punto de partida. En ese caso debe limitarse el catálogo a recursos y herramientas no destructivas.
¿Un servidor de referencia sirve para producción?
No debe asumirse que sí. El propio repositorio oficial advierte de que las implementaciones de referencia son educativas y requieren una evaluación de seguridad antes de llevarlas a producción.
En Summum IA diseñamos el catálogo, la autorización, las políticas y las pruebas necesarias para integrar MCP sin ampliar privilegios de forma invisible. Si tu empresa quiere conectar agentes de IA a sistemas internos con este nivel de control, en nuestro servicio de integración MCP para empresas acompañamos cada fase, desde el inventario inicial hasta la producción limitada.