Cada MCP server en HostedMCP tiene una nota breve al final: los servidores listados se ejecutan con los permisos que tú les otorgues, así que revisa el código fuente antes de instalar. Ponemos esto ahí porque el problema de seguridad más común en MCP no es un exploit ingenioso. Es alguien pegando una URL de una base de datos con permisos de escritura total en un servidor que encontró hace cinco minutos.
Esta guía cubre ambos tipos de riesgo. Los ordinarios, como el uso de credenciales demasiado amplias, son donde comienzan la mayoría de los incidentes. Los de nivel de protocolo, como el token passthrough y los confused deputies, son importantes si construyes o alojas servidores. Hemos basado cada punto en las mejores prácticas de seguridad oficiales de MCP para la revisión del 2026-07-28, además de lo que vemos en nuestro propio catálogo.
Puntos clave
- La mayoría de los incidentes de MCP comienzan con errores ordinarios: credenciales demasiado amplias y servidores que nadie revisó.
- El modelo lee texto no confiable, por lo que cualquier herramienta que tenga puede ser manipulada por una página web, un issue o un correo electrónico.
- Los servidores locales se ejecutan con tus permisos; los servidores remotos deben seguir OAuth 2.1 y nunca deben realizar token passthrough.
- El acceso mínimo, la aprobación para cualquier acción de escritura, el uso de versiones fijas y tener menos servidores por agente previenen la mayoría de los problemas.
| Riesgo | A quién afecta | Defensa principal |
|---|---|---|
| Prompt injection a través de contenido | Cualquier persona cuyo agente lea páginas web, issues o correos | Aprobación antes de escribir; no usar herramientas irreversibles junto a entradas no confiables |
| Un servidor local se ejecuta como tú | Cualquier persona que instale servidores stdio | Editores de confianza, secretos con alcance limitado (scoped), versiones fijas |
| Errores de OAuth en servidores remotos | Desarrolladores y hosts de servidores | Seguir la especificación de autorización de MCP; no realizar token passthrough |
| Demasiado en un solo lugar | Agentes con muchos servidores | Dale a cada agente solo los servidores que su tarea necesite |
Por qué MCP cambia el panorama de la seguridad
Una integración tradicional es código que un desarrollador escribió, llamando a una API de la forma en que decidió de antemano. Con MCP, un modelo decide en tiempo de ejecución qué herramienta llamar y con qué argumentos, basándose en todo lo que hay en su contexto. Parte de ese contexto es texto que nadie en tu equipo escribió: una página web que el modelo consultó, un issue de GitHub, un correo electrónico o el resultado de otra herramienta.
Ese es el problema central resumido en una frase. El modelo es un agente que toma decisiones y lee entradas no confiables. La mayoría de los riesgos de MCP son alguna variante de "un texto no confiable dirigió una llamada a una herramienta" o "una herramienta tenía más acceso del necesario cuando eso ocurrió".
Riesgo 1: prompt injection a través de contenido
Supongamos que has conectado un MCP server de GitHub con permisos para comentar y cerrar issues, y le pides a tu agente que clasifique los nuevos issues. Un issue contiene, oculto en un log largo, una línea que le ordena al asistente cerrar todos los issues abiertos como duplicados. Un modelo que sigue instrucciones encontradas en los datos puede hacer exactamente eso.
Nada en el protocolo impide esto, porque el razonamiento del modelo no es algo que un protocolo pueda validar. Lo que ayuda es trabajar por capas. Los buenos hosts solicitan aprobación antes de ejecutar herramientas que modifican datos y te muestran los argumentos. Los buenos servidores marcan las herramientas que escriben o eliminan, para que los hosts puedan tratarlas de forma distinta. Además, puedes limitar el acceso del agente a lo estrictamente necesario para la tarea: clasificar requiere leer y etiquetar, no cerrar ni eliminar.
Atención
Un agente que lee contenido no confiable no debería tener herramientas que puedan realizar acciones irreversibles sin la confirmación de una persona. Esta es la regla que nosotros mismos seguimos.
Riesgo 2: un servidor local se ejecuta con tus permisos
Un servidor local es un programa en tu computadora, iniciado por tu aplicación de IA, que cuenta con tus permisos de usuario. Puede leer los archivos que tú puedes leer y acceder a la red a la que tú tienes acceso. Las mejores prácticas de seguridad de MCP tratan esto como un riesgo independiente: un servidor local malicioso o comprometido puede ejecutar comandos arbitrarios con los privilegios del cliente, razón por la cual los flujos de instalación de un solo clic deben obtener consentimiento explícito y mostrar el comando exacto.
Los servidores locales representan una gran parte de nuestro catálogo, especialmente entre las herramientas para desarrolladores, y muchos de ellos necesitan secretos. El 11 de noviembre de 2026, 11,660 servidores declararon variables de entorno, y 12,757 de esas variables fueron marcadas como secretos: API keys, tokens y contraseñas que residen en el archivo de configuración de tu cliente.
Cómo dicen los servidores de nuestro catálogo que se autentican, según los README que leyó nuestro modelo de enriquecimiento (medido November 14, 2026):
| Autenticación | Servidores | Compartir |
|---|---|---|
| Ninguna | 18.605 | 46% |
| API key u OAuth | 10.520 | 26% |
| API key o token | 9248 | 23% |
| OAuth | 2389 | 6% |
Qué hacer al respecto es, en su mayoría, sentido común aplicado de forma consistente.
Prefiere servidores del proveedor del producto o de un editor cuyo otro trabajo puedas consultar. Nuestras páginas de servidores muestran al editor y marcan los servidores oficiales.
Verifica que la fuente sea pública y esté activa. Un paquete sin un repositorio vinculado, o un repositorio cuya última modificación fue hace un año, es una apuesta más arriesgada. Cada página de HostedMCP muestra el último commit y la fecha de la última versión.
Lee la lista de herramientas antes de instalar. Si un servidor de "clima" tiene una herramienta que ejecuta comandos de shell, detente.
Limita el alcance del secreto. Dale a un servidor de base de datos un usuario de solo lectura. Dale a un servidor de GitHub un token de grano fino para un solo repositorio. Apunta un servidor de sistema de archivos a una carpeta de proyecto específica, nunca a tu directorio personal.
Consejo
Fija las versiones de cualquier cosa importante.
npx -y some-server@latestejecuta lo que sea que se haya publicado más recientemente cada vez que se inicia;npx -y some-server@1.4.2ejecuta la versión que revisaste.
La especificación menciona un riesgo local más que vale la pena conocer si ejecutas proxies: en una configuración donde una página web puede alcanzar un proxy MCP local, un error de cross-site scripting en esa página puede escalar a la ejecución de comandos a través del servidor stdio del proxy. Si ejecutas un gateway o proxy de MCP en localhost, trátalo como cualquier otro servicio local con una superficie de ataque.
Riesgo 3: servidores remotos y OAuth
Los servidores remotos no interactúan con tu máquina, pero almacenan tokens de muchos usuarios y se comunican con otros servicios en su nombre, lo que plantea un conjunto de problemas distinto. Las mejores prácticas de seguridad de MCP enumeran varios de ellos específicamente.
| Ataque | Qué sucede | Defensa |
|---|---|---|
| Token passthrough | Un servidor acepta un token que no le fue emitido, o reenvía el token del usuario hacia un servicio superior | Aceptar solo tokens emitidos para este servidor; nunca reenviarlos |
| Confused deputy | Un proxy con un client ID estático le otorga un código a un cliente malicioso sin consentimiento real | Consentimiento por cliente en el proxy |
| Server-side request forgery | El descubrimiento de OAuth dirige al cliente hacia URLs internas, como metadatos de la nube | Los clientes validan las URLs de descubrimiento |
| Mix-up attack | Un servidor de autorización malicioso envía un código al endpoint de tokens de un servidor legítimo | Validación de iss (RFC 9207), añadida el 2026-07-28 |
| Authorization URL abuse | Un servidor devuelve una URL javascript: o metacaracteres de shell |
Los clientes validan la URL antes de abrirla |
| Localhost redirect impersonation | Otro proceso local intercepta un código enviado a localhost |
Manejo cuidadoso de redirecciones en clientes de escritorio |
| Over-broad scopes | Un token filtrado puede hacer mucho más de lo necesario para la tarea | Solicitar el scope más restrictivo |
La regla detrás de la primera fila es directa: los MCP server no deben aceptar ningún token que no haya sido emitido explícitamente para ese MCP server.
La revisión del 2026-07-28 también dejó de utilizar OAuth Dynamic Client Registration en favor de Client ID Metadata Documents, y el diseño stateless reemplazó a las sesiones del protocolo, por lo que las preocupaciones antiguas sobre el secuestro de sesiones ahora se plantean como el secuestro de los manejadores de estado que emite un servidor. Si tu servidor mantiene estado, haz que esos manejadores sean imposibles de adivinar y vincúlalos al usuario.
Riesgo 4: demasiado en un solo lugar
El riesgo más silencioso es la concentración. Un solo agente con un MCP server de GitHub, un MCP server de Slack, un MCP server de base de datos y un MCP server de navegador puede leer código, leer mensajes, consultar clientes y visitar cualquier sitio web, todo dentro del mismo contexto. Una única instrucción inyectada tiene entonces muchas herramientas con las que trabajar, incluyendo formas de extraer datos.
Dividir las tareas ayuda. Dale a un agente solo los servidores necesarios para la tarea actual en lugar de todo lo que tengas disponible. Mantén los servidores que leen datos sensibles alejados de los servidores que pueden publicar hacia el mundo exterior o, al menos, haz que los servidores con salida requieran aprobación.
Una lista de verificación para quienes instalan servidores
Antes de añadir un servidor, dedicar unos minutos a revisar evita la mayoría de los problemas.
- Identifica quién lo publica. Ya sea un proveedor oficial o un mantenedor que puedas investigar.
- Confirma que el código sea público y que haya tenido actividad reciente.
- Lee el nombre y la descripción de cada herramienta. Cualquier cosa que no encaje con el propósito del servidor es una señal de alerta.
- Otorga el mínimo acceso posible: usuarios de solo lectura, tokens de un solo repositorio o de una sola carpeta.
- Mantén las acciones de escritura y eliminación bajo tu aprobación, y no las autorices de forma permanente hasta que confíes en el servidor.
- Fija las versiones de los servidores de los que dependas y actualiza de forma deliberada.
- Elimina los servidores que ya no uses. Cada servidor instalado representa una superficie de ataque y consume espacio en la ventana de contexto.
Cada página de servidor en HostedMCP muestra el editor, el último commit, las variables de entorno que necesita y su lista completa de herramientas, lo que permite completar los primeros cuatro puntos en un minuto.
Una lista de verificación para quienes desarrollan servidores
Si mantienes un servidor, asumes una mayor responsabilidad.
- Expón el conjunto más pequeño de herramientas necesarias para cumplir la tarea, nombrándolas según la acción que realizan.
- Marca las herramientas que escriben o eliminan con el hint de destrucción para que los hosts puedan pedir permiso primero.
- Valida cada argumento como si viniera de un atacante, porque podría ser así.
- Registra en stderr, nunca en stdout, y nunca registres secretos.
- Para servidores remotos, sigue la especificación de autorización de MCP: OAuth 2.1, acepta solo tokens emitidos para tu servidor, no permitas el paso de tokens (token passthrough) y usa alcances (scopes) restringidos.
- Trata los manejadores de estado como secretos: aleatorios, vinculados al usuario y de corta duración.
- Documenta cada permiso y variable de entorno que tu servidor necesite, utilizando únicamente valores de marcador de posición.
Nuestra guía para desarrollar un MCP server muestra los conceptos básicos con los SDK actuales, y MCP vs API explica por qué devolver menos datos también es una ventaja de seguridad.
Ejecutar MCP en equipo
Cuando varias personas empiezan a usar MCP en el trabajo, las instalaciones ad-hoc dejan de ser escalables. Unos pocos hábitos ayudan a que sea manejable.
| Hábito | Por qué ayuda |
|---|---|
| Una lista de servidores aprobada y fijada en el repositorio | Todos ejecutan las mismas versiones revisadas |
| Identidades separadas para los agentes | Los logs de auditoría muestran qué acciones realizó un agente; revocar su acceso no bloquea a nadie |
| Servidores alojados para productos SaaS | Sin API keys en las laptops; el acceso sigue los controles de administrador del producto |
| Registro de llamadas a herramientas | Tras un evento inesperado, el log muestra qué contenido guio al modelo |
| Actualizaciones revisadas como dependencias | El código nuevo con tus permisos se lee antes de ejecutarse |
Mantén una lista aprobada. Elige los servidores que tu equipo pueda usar, fija sus versiones y comparte la configuración a través del repositorio en lugar de usar el directorio personal de cada persona. El archivo .mcp.json con alcance de proyecto de Claude Code y el .vscode/mcp.json de workspace de VS Code existen precisamente para esto, y nuestras guías de clientes muestran dónde guarda cada herramienta la configuración del proyecto.
Asigna identidades propias a los agentes. Una cuenta de servicio o un token de bot para el agente, separado de las credenciales de cualquier persona, hace que sea evidente en los logs de auditoría qué acciones realizó un agente y te permite revocar su acceso sin bloquear a nadie.
Prioriza los servidores alojados para SaaS. Cuando un proveedor ejecuta el MCP server para su propio producto, te ahorras distribuir API keys a las laptops, y el acceso se rige por los mismos permisos de OAuth y controles de administrador que el resto del producto. Nuestra lista de servidores remotos es una forma rápida de ver qué proveedores ofrecen uno.
Registra las llamadas a herramientas. La mayoría de los hosts pueden registrar qué herramientas se ejecutaron y con qué argumentos. Guarda esos logs donde guardas otros logs de auditoría y revísalos cuando ocurra algo inesperado; normalmente muestran exactamente qué fragmento de contenido guio al modelo.
Revisa las actualizaciones como si fueran dependencias. Una actualización de un servidor es código nuevo ejecutándose con tus permisos. Lee el changelog de los servidores que pueden escribir en sistemas de producción, de la misma forma que lo harías con una librería.
Qué verifica y qué no verifica HostedMCP
Somos un directorio, no un auditor de seguridad, y es importante dejar clara esa distinción. Para cada listado, leemos el repositorio, los paquetes y el README, registramos el editor, el último commit, los lanzamientos y las variables de entorno declaradas, y mostramos la lista completa de herramientas. Los listados de editores masivos se marcan, y los forks y mirrors se fusionan con el original.
No ejecutamos los servidores ni auditamos su código. Un listado en HostedMCP significa que lo encontramos y lo describimos con precisión, no que sea seguro para tu entorno. Esa decisión depende de ti, y las listas de verificación de arriba son la forma en que nosotros lo haríamos.
Si eres nuevo en todo esto, qué es MCP y qué es un MCP server son buenos puntos de partida, y nuestra lista de servidores remotos es la forma más fácil de probar servidores que nunca tocan tu máquina.