¿Qué es la Seguridad en MCP?
La seguridad en MCP es lo que impide que un servidor de Model Context Protocol se convierta en la vía más fácil de entrar a un sistema. El protocolo estandariza cómo los agentes descubren e invocan herramientas; no decide quién puede invocarlas, a qué pueden llegar ni qué pasa cuando la descripción de una herramienta se vuelve hostil. Esas decisiones viven en el servidor: autenticación, validación de origen y transporte, herramientas de alcance estrecho, límites de tasa y traza de auditoría.
Definición
La seguridad en MCP es el conjunto de controles aplicados a un servidor de Model Context Protocol y a sus clientes —autenticación y autorización, validación de origen y transporte, acotación de herramientas, tratamiento de entradas y salidas, límites de tasa y auditoría— para que exponer capacidades a un agente de IA no signifique exponer los sistemas que hay detrás.
Puntos clave
- MCP estandariza la fontanería, no la confianza: cada servidor decide su propia postura.
- La descripción de una herramienta es entrada no confiable para el modelo: puede instruir y puede cambiar después de haber sido aprobada.
- Los servidores locales por stdio y los remotos por HTTP tienen modelos de amenaza distintos; los errores peligrosos son otros.
- Las comprobaciones de origen y los límites de tasa van en el servidor, porque los clientes no están bajo tu control.
- «Solo lectura» es una propiedad de la implementación, nunca del nombre de la herramienta.
Contexto
MCP da al agente una forma uniforme de descubrir e invocar capacidades. Esa uniformidad es a la vez el valor y el riesgo: un mismo cliente puede apuntar a muchos servidores, y cada servidor es una decisión de confianza nueva que en la práctica toma quien pega una URL en un fichero de configuración.
Dominan dos formas de despliegue. Un servidor local por stdio corre con los privilegios del propio usuario en su máquina: no hay frontera de red, así que las preguntas son qué puede leer y si llama a casa. Un servidor remoto por HTTP es un endpoint público: las preguntas pasan a ser quién llama, desde dónde, con qué frecuencia y si se puede engañar a un navegador para que llame en nombre de un usuario.
Para esta base de conocimiento operamos una de cada forma —un endpoint HTTP público y un paquete stdio publicado—, así que los controles que siguen se describen tal y como están implementados, no como una lista genérica.
Arquitectura
Decide primero la exposición: capacidad pública de solo lectura, capacidad autenticada o solo local. Todo lo demás se deriva de esa respuesta, y la mayoría de incidentes vienen de un servidor que nunca la tomó.
Valida el transporte antes de hacer trabajo. En servidores HTTP, comprueba la cabecera Origin contra una lista de permitidos y rechaza las llamadas cross-site iniciadas por navegador antes de que corra ningún handler: el DNS rebinding y el abuso tipo CSRF llegan por ahí.
Mantén el servidor sin estado siempre que el protocolo lo permita. Sin almacén de sesión no hay fijación de sesión, ni contaminación entre peticiones, ni estado que filtrar entre llamantes.
Acota las herramientas. Una herramienta, una capacidad, sin verbos que cambien según un argumento: una herramienta de «consulta» que además escribe es una escalada de privilegios esperando el parámetro adecuado.
Limita la tasa por llamante y responde con un 429 real y Retry-After. Un agente que reintenta es tráfico normal; un agente que reintenta sin límite es una herramienta de denegación de servicio apuntando a tu propio backend.
Registra cada llamada con la forma suficiente para reconstruir un abuso —herramienta, resultado, latencia, identidad del llamante— y nada que convierta el propio log en la brecha.
Trata todo resultado de herramienta como contenido no confiable en el camino de vuelta. Un servidor que hace de proxy de datos externos es, por construcción, un canal de inyección indirecta.
Componentes
Beneficios
- Un servidor MCP bien acotado es una superficie de ataque menor que la integración ad hoc que sustituye: un protocolo, un punto de auditoría, un sitio donde revocar.
- La ausencia de estado y las herramientas estrechas hacen que el servidor sea barato de razonar: la revisión de seguridad cabe en una página.
- Errores estándar y cabeceras de límite de tasa hacen predecible el comportamiento del cliente, lo que ya es en sí una propiedad defensiva.
- Como todo cruza una sola frontera, la medición sale gratis: el abuso y el uso aparecen en los mismos logs y se distinguen.
Riesgos
- Rug pull de herramientas: un servidor que se comporta en el momento de la aprobación y cambia sus descripciones después, cuando el cliente ya ha dejado de preguntar.
- Servidores locales demasiado amplios: un servidor stdio con el sistema de ficheros y las credenciales del usuario es una capacidad de agente completa sin frontera de red que la detenga.
- Diputado confundido: el servidor tiene credenciales que el llamante no tiene, así que quien llegue a él hereda su alcance.
- Exposición pública silenciosa: un servidor remoto desplegado sin autenticación, sin comprobación de origen y sin límite de tasa es descubrible y gratis de abusar.
- Relé de inyección: salida de herramienta tomada de terceros y entregada al modelo como si fuera instrucción de confianza.
Herramientas y tecnologías
Ejemplos
- Esta base de conocimiento expone un endpoint MCP HTTP público y de solo lectura. Es sin estado por diseño, así que ninguna sesión puede fijarse ni reproducirse; las herramientas devuelven únicamente contenido publicado; y cada llamada está limitada por llamante hasheado, con un 429 real y Retry-After.
- Antes de escribir la regla de Origin de ese endpoint medimos su propio tráfico: casi ninguna petición traía cabecera Origin, ninguna traía null y todas las que sí la traían venían de este sitio. La regla que se desplegó sigue a la medición —rechazar llamadas con origen de navegador desde cualquier otro sitio y permitir el tráfico de agentes sin cabecera, que es la audiencia real— en lugar de copiar la política por defecto de una aplicación web.
- El paquete stdio publicado para esta misma base de conocimiento corre en local sin credenciales y sin acceso al sistema de ficheros, porque lo único que necesita es una llamada saliente al endpoint público. A un servidor local que no necesita nada, no hay que darle nada.
FAQs
- ¿MCP hace a los agentes más seguros o menos?
- Más seguros por integración, más arriesgados en conjunto. Un solo protocolo significa un solo sitio donde revisar y revocar, pero también abarata conectar un agente a otro sistema, y cada conexión es una decisión de confianza nueva que alguien tiene que tomar.
- ¿Necesito autenticación en un servidor de solo lectura?
- No necesariamente, si los datos son genuinamente públicos. Lo que sí necesitas es límite de tasa y traza de auditoría: público no significa gratis, y un endpoint público sin límites es un amplificador apuntando a tu propia infraestructura.
- ¿Por qué comprobar la cabecera Origin si los agentes no la envían?
- Precisamente porque no la envían. El tráfico sin cabecera es la audiencia legítima; una petición que sí trae un Origin ajeno es un navegador actuando en nombre de otra persona, que es justo el caso que conviene rechazar.
- ¿Qué es un rug pull de herramientas y cómo me defiendo?
- Un servidor que presenta descripciones inocuas cuando el usuario lo aprueba y las cambia después. Las defensas son fijar la versión del servidor, revalidar las descripciones cuando cambian y no conceder a un servidor remoto capacidades que no concederías a una dependencia de código.