MCP ha resuelto uno de los problemas más importantes de los agentes de IA: cómo conectar un modelo con herramientas y datos externos mediante un protocolo común.
Eso simplifica enormemente la integración. Un agente puede descubrir tools, consultar recursos y trabajar con aplicaciones que antes requerían conectores completamente personalizados.
Pero hay una consecuencia inevitable: cuanto más fácil resulta conectar capacidades a una IA, más importante se vuelve controlar qué capacidades estamos conectando, quién puede utilizarlas y bajo qué autoridad.
MCP no es inseguro por definición. Al contrario: su especificación incorpora un trabajo considerable alrededor de autorización y seguridad. El problema aparece cuando una integración trata el protocolo como si fuese simplemente “USB para IA” y olvida que detrás de cada tool puede existir acceso a sistemas reales.
Qué es MCP desde el punto de vista de seguridad
Model Context Protocol permite que servidores expongan al cliente diferentes capacidades.
- Resources: contexto y datos.
- Prompts: mensajes o workflows reutilizables.
- Tools: funciones que el modelo puede ejecutar.
Las especificaciones actuales incluyen además capacidades agentivas y mecanismos de autorización que siguen evolucionando a medida que aparecen nuevos patrones de uso.
Desde la perspectiva defensiva, MCP crea una frontera entre:
Modelo → Cliente/Host MCP → Servidor MCP → API / Datos / Sistema externo.
NEURON HUMAN
Cada salto necesita identidad, autorización, control de datos y trazabilidad.
Las tools son el punto donde el lenguaje se convierte en acción
Ésta es probablemente la idea más importante para entender MCP Security.
Una tool no es una respuesta del modelo. Puede ser una operación sobre el mundo real.
- consultar una base de datos;
- enviar un mensaje;
- crear un ticket;
- modificar un repositorio;
- ejecutar un cálculo;
- interactuar con una API administrativa.
La propia especificación de MCP señala que las tools pueden representar rutas de ejecución arbitraria y que deben tratarse con la cautela correspondiente.
Eso significa que el modelo puede proponer utilizar una tool, pero la arquitectura debería conservar la capacidad de decidir independientemente si el efecto está autorizado.
MCP no puede decidir por nosotros qué es confiable
Un protocolo puede definir mensajes, flujos y requisitos de interoperabilidad. No puede conocer automáticamente el nivel de confianza que nuestra organización debería conceder a cada servidor.
Por eso una integración segura necesita una política explícita para responder preguntas como:
- ¿quién administra este servidor?
- ¿qué versión ejecuta?
- ¿qué tools expone?
- ¿qué datos puede recibir?
- ¿qué APIs tiene detrás?
- ¿qué cambios requieren una nueva revisión?
Tool Poisoning: el servidor puede influir sobre el razonamiento
Las descripciones y annotations de tools ayudan al modelo a decidir qué capacidad utilizar.
La especificación MCP indica que esas annotations deben considerarse no confiables salvo que procedan de un servidor confiable.
Eso protege una frontera importante: una descripción no debería convertirse en un canal para reescribir la intención del usuario.
Este problema merece su propio análisis porque puede existir incluso sin que la tool maliciosa llegue a invocarse. Una definición puede intentar influir al modelo para que utilice otra capacidad legítima.
Autenticación no significa autorización
Un servidor puede reconocer correctamente quién está haciendo una petición y aun así aceptar una operación que no debería estar permitida.
MCP utiliza OAuth para escenarios HTTP protegidos y la especificación ha evolucionado de forma importante en 2026 para endurecer esos flujos.
La distinción básica sigue siendo:
Autenticación: quién eres. Autorización: qué puedes hacer aquí, ahora y sobre este recurso.
NEURON HUMAN
El audience del token importa
Uno de los errores clásicos en sistemas distribuidos es aceptar un token válido simplemente porque su firma es correcta y procede de un issuer conocido.
Eso no es suficiente.
La especificación de autorización de MCP exige que los servidores validen que el access token fue emitido específicamente para ellos. El cliente debe indicar el recurso objetivo y el servidor debe rechazar tokens destinados a otros servicios.
La propiedad que queremos conservar es:
Token válido + recurso incorrecto = token no autorizado para esta operación.
Token passthrough: una comodidad que rompe fronteras
Otro anti-patrón especialmente importante es recibir un token del cliente y reenviarlo sin más a un servicio posterior.
La documentación de MCP prohíbe expresamente este token passthrough.
Entre otros problemas puede provocar:
- saltarse controles del propio servidor MCP;
- perder trazabilidad sobre qué cliente inició la acción;
- usar credenciales con un audience incorrecto;
- crear escenarios de confused deputy.
El problema del Confused Deputy
Un confused deputy aparece cuando un componente con autoridad legítima termina utilizando esa autoridad en beneficio de otro actor que no debería tenerla.
En MCP puede aparecer, por ejemplo, cuando un servidor proxy conecta clientes con una API de terceros y mezcla incorrectamente identidades, consentimientos o credenciales.
La guía oficial de seguridad de MCP dedica una sección específica a esta familia de ataques y exige controles de consentimiento por cliente en los escenarios afectados.
Consentimiento: “el usuario aceptó” no siempre es suficiente
La especificación MCP da mucho peso al control del usuario, y con razón.
Pero un consentimiento solo aporta seguridad cuando el usuario comprende qué está aprobando.
Una interfaz como:
“La IA quiere utilizar la herramienta Email. ¿Permitir?”
aporta mucha menos información que:
“Enviar el archivo financiero Q2 a external@example.com utilizando la cuenta corporativa de David.”
El consentimiento debería estar ligado al efecto real, no únicamente al nombre de la tool.
Los resultados de las tools también son datos no confiables
Una tool puede ser perfectamente legítima y devolver contenido malicioso.
Por ejemplo, una herramienta de búsqueda consulta una web controlada por un tercero. El resultado se devuelve correctamente al agente, pero contiene instrucciones adversariales.
Esto significa que confiar en el servidor MCP no implica necesariamente confiar en todos los datos que atraviesan ese servidor.
Los servidores MCP son supply chain
Cuando instalamos o conectamos un servidor MCP de terceros estamos incorporando software, dependencias y capacidades a nuestro sistema agentivo.
Por tanto debemos tratarlo como parte de la supply chain:
- origen del paquete;
- versión;
- firma/procedencia cuando exista;
- dependencias;
- permisos;
- actualizaciones;
- cambios de tools y schemas.
Una actualización puede ser funcionalmente pequeña y, sin embargo, cambiar de manera sustancial la autoridad que recibe el agente.
La especificación MCP de 2026 sigue endureciendo autorización
La evolución del protocolo refleja que estas cuestiones no son teóricas.
En la revisión de julio de 2026 se introdujeron nuevos endurecimientos en autorización, entre ellos validación del parámetro iss en determinadas respuestas de autorización para cerrar escenarios de mix-up entre authorization servers.
Esto es una señal importante: MCP está madurando y la seguridad de sus integraciones también tiene que hacerlo.
Cómo diseñaría una integración MCP defensiva
1. Inventario explícito de servidores y tools
Ninguna capacidad debería aparecer de forma silenciosa.
2. Trust por servidor, no por protocolo
Que algo hable MCP no lo convierte en confiable.
3. Mínimo privilegio y scopes
Cada servidor y tool debería recibir únicamente la autoridad necesaria.
4. Autorización del efecto
La decisión de usar una tool y la decisión de permitir su efecto deberían poder separarse.
5. Tokens ligados al recurso
Issuer correcto no basta. Audience/recurso también deben ser correctos.
6. Prohibir token passthrough
El servidor debe utilizar credenciales adecuadas para cada downstream, no reciclar la autoridad recibida del cliente.
7. Validar cambios de herramientas
Nueva descripción, nuevo schema o nueva capacidad deben generar una revisión de seguridad.
8. Correlacionar toda la trayectoria
Servidor → tool → argumentos → autorización → API downstream → resultado → acciones posteriores.
Qué debería observar un Blue Team
- registro de nuevos servidores;
- cambio de tool metadata;
- cambio de scopes;
- tokens con audience inesperado;
- fallos de PKCE/issuer validation;
- invocaciones sin aprobación cuando ésta era requerida;
- tool A leyendo datos y tool B enviándolos;
- servidor legítimo devolviendo contenido externo adversarial.
Qué debería probar un Purple Team
- token para recurso A presentado al servidor B;
- token passthrough simulado;
- consentimiento de un cliente reutilizado por otro;
- tool metadata adversarial;
- tool result con Prompt Injection;
- actualización de servidor que añade una tool;
- cambio de schema que amplía parámetros sensibles;
- acción de alto impacto sin contexto suficiente en la confirmación.
Dónde encaja MindGuard
En MindGuard estamos tratando MCP como una frontera de autoridad y flujo de datos, no únicamente como una integración.
Eso implica analizar servidores, tools, identidad, scopes, decisiones, resultados y efectos dentro de la misma cadena de seguridad.
Conectar una herramienta es fácil. Entender la autoridad que acabamos de entregar es la parte difícil.
MINDGUARD RESEARCH
MCP no elimina el problema de seguridad: lo hace visible
La estandarización es positiva. Nos permite dejar de inventar un conector diferente para cada herramienta y construir ecosistemas interoperables.
Pero precisamente porque MCP hace más sencillo ampliar las capacidades de un agente, necesitamos que la seguridad evolucione a la misma velocidad.
El protocolo puede ayudarnos a estructurar la comunicación. La responsabilidad de decidir qué debe confiarse, qué debe autorizarse y qué debe observarse sigue siendo nuestra.
Una conexión estandarizada no es una conexión automáticamente segura.
NEURON HUMAN
Referencias
- Model Context Protocol — Specification
- Model Context Protocol — Tools
- Model Context Protocol — Authorization
- Model Context Protocol — Security Best Practices
- MCP — 2026-07-28 Specification
Preguntas frecuentes
¿Qué es MCP?
Model Context Protocol es un protocolo abierto para conectar aplicaciones de IA con herramientas, recursos y otros servicios mediante interfaces estandarizadas.
¿MCP incluye seguridad?
Sí. La especificación incluye requisitos y recomendaciones de autorización, consentimiento, privacidad y seguridad de tools. Sin embargo, la implementación sigue teniendo que definir trust, permisos y políticas adecuadas.
¿Qué es token passthrough?
Es el anti-patrón de recibir un token en el servidor MCP y reenviarlo sin la separación de autoridad adecuada hacia otro servicio. La especificación lo prohíbe por los riesgos de bypass, trazabilidad y confused deputy.
¿Qué es un confused deputy?
Es un escenario donde un componente con privilegios legítimos termina utilizando su autoridad para realizar una operación en beneficio de un actor que no debería disponer de esos privilegios.
¿Debemos confiar en cualquier servidor MCP?
No. El protocolo define interoperabilidad, no confianza automática. Cada servidor debe evaluarse según origen, código, permisos, tools, datos, actualizaciones y contexto de uso.
