Cuando el servidor MCP guarda tus credenciales: el vector de ataque silencioso de la IA en producción

La incorporación de agentes de IA en procesos empresariales ha abierto una vía práctica para que sistemas y datos en producción sean accesibles desde los modelos: se llama Model Context Protocol (MCP) y, según su especificación original, fue promovido por Anthropic para que asistentes y agentes puedan llamar a herramientas y datos en vivo. Lo que ha empezado a notarse en auditorías y reportes técnicos es que el servidor MCP —ese intermediario que conecta al agente con APIs, ficheros y bases de datos— suele convertirse en el depósito de las credenciales necesarias para actuar. Cuando esas credenciales están mal protegidas, la capacidad de un atacante para leer datos se transforma en capacidad para actuar en nombre del agente.

Técnicamente, un servidor MCP expone un conjunto de acciones que el agente puede invocar y, para ejecutar esas acciones, necesita credenciales: claves de servicio, tokens OAuth, variables de entorno con secretos o cadenas de configuración. En muchas implementaciones prácticas, esas credenciales acaban en archivos de configuración locales o en variables de entorno en texto plano; en otras, se replican entre entornos (desarrollo, staging, producción) porque no existe un almacén centralizado ni procesos de rotación automática. Además, el agente opera con identidades no humanas (NHIs) que permiten no solo leer sino modificar y ejecutar cambios. Por eso, robar un token del servidor MCP no es simplemente filtrar datos: es obtener una llave con la que realizar operaciones en los sistemas que el agente tenía acceso para gestionar.

Los vectores de exposición que están confirmados por múltiples análisis y por incidentes públicos incluyen, entre otros: archivos de configuración en texto plano o variables de entorno que contienen tokens; proliferación y duplicación de credenciales sin rotación; prompt injection, donde contenido malicioso en un documento o en una web induce al agente a exponer secretos o ejecutar acciones indebidas; permisos excesivos asignados por comodidad durante el desarrollo que luego llegan a producción; y riesgos de cadena de suministro al conectar a servidores MCP no confiables. Un ejemplo público citado en informes técnicos es la vulnerabilidad asignada como CVE-2025-6514 en mcp-remote —un proxy OAuth utilizado en clientes y con más de 400.000 descargas— donde un servidor malicioso pudo desencadenar inyección de comandos del sistema operativo y ejecución remota de código, permitiendo así el robo de credenciales en la máquina cliente. Para más información técnica sobre MCP y su diseño, puede consultarse el repositorio público de la especificación en GitHub: https://github.com/anthropic/mcp, y el registro público de la vulnerabilidad en MITRE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-6514.

Quiénes están en riesgo es una pregunta práctica: cualquier organización que integre agentes de IA con acceso a sistemas internos y que dependa de servidores MCP para delegar acciones está potencialmente afectada. Esto incluye equipos de desarrollo que despliegan agentes en pipelines, equipos de soporte que usan asistentes para operar sobre tickets y datos, y arquitecturas cloud que exponen APIs que los agentes deben invocar. También están en riesgo los supply chains que confían en componentes de terceros (por ejemplo, proxies o utilidades como mcp-remote) sin controles de integridad y actualización.

Las consecuencias reales que pueden derivarse son variadas y de gravedad práctica: desde fugas de documentación interna y secretos de API hasta acciones maliciosas realizadas con los NHIs robados (borrado de registros, escalado de privilegios, movimiento lateral en nube). Además, la naturaleza autónoma de los agentes hace que el tiempo entre compromiso y daño pueda ser muy corto, y que la evidencia de un abuso quede dispersa entre logs de distintos sistemas si no hay trazabilidad centralizada.

Debemos distinguir: los hechos descritos arriba están confirmados por la especificación técnica de MCP y por incidentes públicos reportados; las afirmaciones sobre frecuencia (por ejemplo, que el almacenamiento en texto plano es “rutinario”) son estimaciones basadas en auditorías y en prácticas observadas en despliegues rápidos de proyectos de IA; y sigue existiendo incertidumbre sobre el alcance agregado del problema a nivel de todas las organizaciones que han desplegado MCP internamente (no hay todavía un inventario global público).

Ante ese panorama, las medidas concretas que equipos de seguridad y desarrolladores deben aplicar de inmediato son claras y aplicables:

1) Eliminar secretos en texto plano y centralizarlos en un vault gestionado. Mover claves y tokens fuera de archivos de configuración y variables de entorno hacia un gestor de secretos con control de acceso y registro de acceso. Si se busca una solución comercial con funciones de enmascaramiento y comprobación por confirmación, existen herramientas en el mercado que implementan estas ideas; por ejemplo, Keeper Secrets Manager ofrece flujos de uso para agentes y controles de revelado con confirmación: https://www.keepersecurity.com/secrets-manager/.

2) Emplear credenciales de corta duración y rotación automática. Evitar claves estáticas. Generar tokens efímeros con expiración y renovación automática reduce significativamente la ventana de exposición si hay una fuga.

3) Forzar el principio de menor privilegio. Asignar a cada agente solo los permisos mínimos necesarios para su tarea y comprobar mediante revisiones y reglas automáticas que esos permisos no se incrementen por comodidad de desarrollo. Para definiciones y guías de control de acceso, conviene remitirse a las guías de buenas prácticas de control de accesos y least privilege: https://csrc.nist.gov/Glossary/term/least_privilege.

4) Mantener a un humano en el bucle para operaciones sensibles. Acciones como revelar un secreto sin mascarar, borrar datos de producción o ejecutar cambios en infraestructuras críticas deben requerir confirmación humana autenticada y registro de la aprobación.

5) Instrumentar logging, auditoría y detección específica para agentes. Registrar cada petición del agente, la identidad NHI utilizada y el recurso afectado; habilitar alertas de comportamiento anómalo (por ejemplo, solicitudes fuera de horario o de recursos inusuales) y conservar logs suficientes para auditoría forense.

6) Inventariar y controlar todos los servidores MCP y proxies de cliente. Actuar contra “shadow MCP”: escanear repositorios, máquinas de desarrollo y entornos cloud para localizar instancias, aplicar parches y revocar tokens si se detecta software vulnerable (por ejemplo, actualizar o retirar mcp-remote afectado por CVE-2025-6514).

7) Proteger contra prompt injection y contenido adverso. Filtrar, sanear y verificar la procedencia del contenido que los agentes procesan; mantener mecanismos de validación y, cuando sea necesario, limitar el acceso de los agentes a documentos externos no confiables.

En resumen, MCP introduce una capa operativa que facilita la utilidad de los agentes de IA pero también concentra riesgo: el servidor MCP a menudo termina como custodio de credenciales con capacidad de actuar en sistemas críticos. Las defensas no son exóticas: centralizar secretos, usar credenciales efímeras, aplicar least privilege, añadir revisiones humanas en puntos críticos, auditar acciones y mantener un inventario completo son pasos técnicos y organizativos que deben aplicarse ahora para mitigar un riesgo que, de otro modo, puede pasar desapercibido hasta que el daño sea irreversible.