El verdadero intercambio detrás de cada conexión MCP

Encontraste un servidor MCP que hace algo genuinamente útil: lee tu espacio de Notion, consulta tu calendario de Cal.com o interroga tu API interna. Podría ahorrarte horas. Pero conectarlo significa entregarle a un agente de IA una llave hacia parte de tu vida digital.

Esa es la pregunta real que todo fundador debería hacerse: ¿qué estoy cediendo exactamente cuando doy clic en conectar?

El Model Context Protocol (MCP), introducido por Anthropic, estandariza cómo los asistentes de IA acceden a herramientas externas, bases de datos y archivos. Elimina la fragmentación que antes hacía que las integraciones de IA fueran costosas y lentas. Pero el protocolo en sí no incluye autenticación ni autorización. Cada servidor que despliegas hereda los permisos que se le otorgan, y cada solicitud fluye sin verificación a menos que agregues controles tú mismo [5][6][8].

Esto no está diseñado para alejarte de MCP. Está diseñado para asegurarse de que no entregues más acceso del que pretendes.

Qué tocan realmente los servidores MCP

Antes de evaluar cualquier servidor, entiende a qué categoría pertenece. Los servidores MCP se dividen en varios grupos amplios, y cada uno lleva un perfil de riesgo diferente:

Servidores de solo lectura. Estos extraen información de una fuente: una base de conocimientos, un CRM, una API pública. No crean ni modifican nada. El riesgo principal está en la exposición de datos: ¿puede el servidor filtrar lo que lee? [5]

Servidores con capacidad de escritura. Estos crean, actualizan o eliminan recursos: envían correos, publican en un tablero de proyectos, modifican registros de bases de datos. El radio de explosión es mayor porque un agente comprometido o confundido puede realizar acciones irreversibles. [5][7]

Servidores proxy o gateway. Estos se interponen entre tu cliente de IA y una API de terceros, actuando como puente OAuth. Introduce un riesgo de “deputado confundido”: el proxy puede ejecutar acciones bajo sus propios privilegios en lugar de los tuyos, o clientes maliciosos pueden explotar el registro dinámico para evitar los flujos de consentimiento. [7][8]

Servidores locales de archivos y sistema. Estos dan a los agentes acceso directo a tu sistema de archivos o comandos del shell. Incluso el acceso solo de lectura al sistema de archivos puede exponer archivos de configuración sensibles, claves API o notas internas. La ejecución de comandos añade riesgo de código arbitrario. [6][7]

Identificar en qué categoría cae un servidor debe ser tu primer paso antes de leer una sola línea de documentación.

Una lista de verificación práctica para evaluar servidores MCP

Cuando buscas herramientas que quitan dolores, la velocidad importa. Pero la velocidad no debería significar saltarse el paso donde verificas qué hace realmente una conexión.

1. Revisa el alcance de los permisos

Verifica a qué accede el servidor según su declaración y compáralo con lo que realmente necesita. Si un servidor que busca notas de reuniones solicita acceso completo al disco, esa es una discrepancia que vale la pena investigar. Los servidores sobreprivilegiados son una de las señales de alarma más comunes en el ecosistema MCP. [5][7]

Pregúntate:

  • ¿Coincide el alcance declarado con el propósito declarado?
  • ¿Hay permisos opcionales que parecen innecesarios para la tarea central?
  • ¿Puedes otorgar solo acceso de lectura y aún así obtener la funcionalidad que necesitas?

2. Examina el manejo de credenciales

¿Cómo almacena y usa el servidor los tokens de autenticación? La exposición de credenciales en texto plano en archivos de configuración locales es un riesgo real y documentado. Si un servidor almacena claves API o tokens en texto plano sin cifrado, esas credenciales son vulnerables al robo desde tu máquina. [6][7]

Busca estas señales:

  • Credenciales almacenadas en gestores de secretos cifrados o respaldados por el sistema operativo, no en archivos de configuración simples
  • Uso de tokens con alcance limitado y de corta duración en lugar de claves API permanentes
  • Documentación clara sobre dónde y cómo se persisten las credenciales
  • Que no requiera pegar credenciales directamente en la configuración del servidor

Si un servidor no puede explicar su manejo de credenciales, considéralo una señal de alerta. [6]

3. Busca validación y sanitización de entradas

La ejecución no autorizada de comandos es una vulnerabilidad conocida en servidores MCP implementados de forma deficiente. Cuando los datos proporcionados por el usuario se pasan a comandos a nivel del sistema sin sanitización, se abre la puerta a la inyección de comandos. [7]

Aunque no puedas auditar el código fuente de cada servidor, puedes buscar señales de diseño defensivo:

  • Servidores que validan y sanitizan entradas antes de usarlas en comandos
  • Entornos de ejecución sandboxed que limitan a qué puede acceder un servidor
  • Documentación que menciona límites de entrada y operaciones permitidas

4. Vigila el riesgo en la cadena de suministro

Los servidores MCP dependen de componentes de software y pipelines de construcción, lo que los hace vulnerables a ataques a la cadena de suministro. Una dependencia comprometida puede convertir un servidor aparentemente inofensivo en un vector de ataque. [5][7]

Cosas prácticas que revisar:

  • ¿Es el servidor de código abierto con un historial de commits visible?
  • ¿Están las dependencias fijadas y auditoras?
  • Para servidores alojados en la nube, ¿el proveedor ofrece verificación criptográfica para confirmar que te estás conectando al endpoint legítimo?
  • ¿El proyecto ha pasado por una revisión de seguridad o ha publicado una política de seguridad?

Firmar y verificar componentes MCP es una práctica hacia la que la comunidad se dirige, pero la adopción es desigual. [7]

5. Desconfía de la fatiga de consentimiento y la manipulación de confianza

La fatiga de consentimiento es un patrón de ataque real. Un servidor MCP malicioso o diseñados descuidadamente puede activar repetidamente solicitudes de permiso hasta que hagas clic sin leerlas. Con el tiempo, puedes terminar concediendo mucho más acceso del que pretendías. [6]

Protégete haciendo:

  • Leer cada mensaje de permiso cuidadosamente las primeras veces que un servidor nuevo lo solicite
  • Denegar o limitar permisos en el primer contacto, y expandirlos solo si el servidor demuestra ser confiable
  • Usar servidores que solicitan permisos uno por uno en lugar de agrupar acceso amplio de inmediato

6. Evalúa el riesgo del deputado confundido

El problema del deputada confundido ocurre cuando un servidor MCP ejecuta acciones usando sus propios privilegios en lugar de actuar estrictamente en tu nombre. Si el servidor carece de controles de delegación adecuados, podrías adquirir acceso indirecto a recursos que no deberías controlar — o peor aún, el servidor podría actuar más allá de lo que autorizaste. [7][8]

Esto es especialmente relevante para servidores proxy que conectan tu cliente de IA a APIs de terceros usando un ID de cliente OAuth estático. En configuraciones vulnerables, clientes maliciosos pueden explotar el registro dinámico y cookies de consentimiento para obtener códigos de autorización sin consentimiento apropiado. [8]

Al elegir un servidor estilo proxy, prefiere implementaciones que salvaguarden la delegación por usuario y nunca mezclen tu identidad con las credenciales propias del servidor.

7. Considera el aislamiento en tiempo de ejecución

Un sandboxing insuficiente aumenta la probabilidad de una brecha. Un servidor que se ejecuta en aislamiento total de tu entorno principal limita el daño incluso si se compromete. [6][7]

Las opciones de sandboxing varían según la configuración. Algunos hosts de MCP te permiten restringir el acceso a la red, a archivos o la ejecución de comandos por servidor. Evalúa si tu host soporta estas restricciones y configúralas antes de habilitar cualquier conexión nueva.

8. Investiga el historial del servidor

Incluso los servidores bien intencionados pueden comportarse de manera sospechosa. La investigación de seguridad de Backslash categorizó los riesgos reales de MCP en tres tipos: servidores maliciosos construidos para explotar, servidores sospechosos que se comportan más allá de su alcance declarado, y servidores vulnerables cuyo diseño crea aberturas para el uso indebido. Los servidores maliciosos confirmados son raros, pero las vulnerabilidades son ampliamente extendidas porque muchos se construyeron por velocidad, no por resiliencia. [10]

Observa comportamientos que se salgan del propósito declarado del servidor: permisos excesivos, flujos de datos inesperados o estructuras que no se alinean con patrones estándar. Estas son señales que merecen una inspección más cercana. [10]

Cuándo dar media vuelta

No todo servidor MCP vale la pena la conexión, incluso si parece útil.

Date la vuelta si:

  • El servidor requiere permisos amplios que exceden su función declarada
  • Almacena credenciales en texto plano sin cifrado ni gestión de secretos
  • No tiene documentación de seguridad visible ni traza de auditoría
  • Es un proxy de código cerrado que no puede verificar su cadena de suministro
  • Solicita acceso a sistemas a los que no le entregarías las llaves a un miembro junior del equipo

La conveniencia de una sola conexión es real. Pero el costo de una clave API comprometida, datos de clientes filtrados o una acción no autorizada realizada en tu nombre puede superar con creces el tiempo ahorrado.

Cómo encaja esto en tu rutina de evaluación de herramientas

Ya evalúas herramientas por funcionalidad, precio y ajuste. Añade la postura de seguridad a esa lista. Para servidores MCP específicamente, la evaluación puede ser rápida sin ser descuidada:

  1. Identifica la categoría del servidor: solo lectura, escritura, proxy o acceso local.
  2. Compara el alcance de permisos con el propósito declarado.
  3. Verifica cómo se manejan las credenciales.
  4. Busca validación de entradas, sandboxing y transparencia en la cadena de suministro.
  5. Decide si el riesgo es proporcional al tiempo y al dolor que el servidor elimina.

Si un servidor pasa esas cinco verificaciones y aún parece valioso, conéctalo. Si falla alguna, busca una alternativa o omitelo por completo.

Preguntas frecuentes

¿Es MCP inherentemente inseguro? No. MCP es un protocolo, no un producto. Su seguridad depende de cómo se implementen y configuren los servidores individuales. El protocolo deja intencionalmente la autenticación y autorización al responsable de la implementación, lo que significa que la responsabilidad recae en ti y en el desarrollador del servidor. [5][6][8]

¿Necesito una herramienta de seguridad empresarial para usar MCP de forma segura? No necesariamente. La vigilancia básica — revisar permisos, verificar el manejo de credenciales, limitar el alcance — recorre un camino largo. Las herramientas de nivel empresarial como el control de acceso basado en políticas y las barreras de seguridad en tiempo de ejecución pueden agregar capas de protección, especialmente para equipos que gestionan múltiples agentes, pero los fundadores solitarios pueden comenzar con la lista de verificación anterior. [5][7]

¿Puedo auditar un servidor MCP antes de conectarlo? Para servidores de código abierto, sí: puedes inspeccionar el código, las dependencias y la configuración. Para servidores alojados o de código cerrado, tu capacidad se limita a la documentación y la reputación. En ambos casos, el enfoque más seguro es comenzar con permisos mínimos y expandirlos solo a medida que ganas confianza. [7][10]

¿Cuál es el riesgo que más pasan por alto los fundadores? La fatiga de consentimiento y el problema del deputada confundido. Ambos son sutiles. Uno te hace hacer clic a través de permisos sin darte cuenta; el otro significa que el servidor actúa con su propia autoridad en lugar de la tuya. Ninguno aparece en una comparación de características. [6][8]

¿Debo usar el registro oficial de MCP? El registro oficial proporciona un punto de partida, pero la inclusión no garantiza la seguridad. El registro es una herramienta de descubrimiento, no un proceso de verificación. Aún necesitas evaluar cada servidor individualmente usando las verificaciones descritas aquí. [5][7]

Fuentes