Servidores MCP: el riesgo que no ves al instalar

TL;DR. Un paquete de npm que se hacía pasar por el servidor MCP de Postmark metía copia oculta hacia una dirección ajena en el correo que enviaba. Lo registran Koi Security y la base de datos OSV de Google. Las fechas de publicación, que npm todavía sirve aunque el paquete esté borrado, desmienten además el relato oficial de cómo llegó ahí. Por debajo del caso hay un problema de dificil solucion: la descripción de las herramientas de un servidor MCP entra en el contexto del modelo con el mismo peso que tu orden, no se enseña entera cuando apruebas y puede cambiar justo después de aprobada. Dificil manera de comprobar un servidor antes de instalarlo, así que lo único que decides de verdad es qué arranca, qué herramientas pueden llamarse y el límite del sistema corre todo.

Casi diez días de un servidor MCP con puerta trasera

El 17 de septiembre de 2025, a las 8:59 UTC, alguien publicó la versión 1.0.16 de postmark-mcp. Koi Security, que analizó el paquete, dice que el cambio era una línea: un campo Bcc apuntando a phan@giftshop.club. Y no queda en su palabra: la base de datos OSV, de Google Open Source Security, registró el 26 de septiembre esa misma versión y ese mismo mecanismo, exfiltración de correo por Bcc. La 1.0.16 aguantó publicada siete días y dieciocho horas antes de que el paquete entero desapareciera de npm.

El aviso oficial de Postmark dice que el autor se ganó la confianza a lo largo de quince versiones antes de meter la puerta trasera, y Semgrep repite ese número. Las fechas de publicación cuentan otra cosa. Entre la 1.0.0 y la 1.0.15 hay trece versiones, no quince: la 1.0.4, la 1.0.5 y la 1.0.6 no aparecen ni entre las fechas ni en la lista de versiones retiradas, así que nunca llegaron a publicarse. Y esas trece se subieron en veinticinco horas y cincuenta y siete minutos, el lunes 15 y el martes 16 de septiembre. Cuando llegó la puerta trasera, el paquete no llevaba ni dos días en el registro.

El código ya no se puede mirar. npm ha dejado de servir el contenido de las versiones, así que nadie puede abrir la 1.0.16 y ver esa línea. Queda el análisis de Koi, que es una empresa de seguridad con producto que vender y que desde entonces la ha comprado Palo Alto Networks, y queda el apunte de OSV, que es de Google y tampoco es un observador de fuera. Las fechas, en cambio, las puede mirar cualquiera.

Nadie que instalara postmark-mcp abrió el código, y no por descuido: nada en el camino obliga a abrirlo. Se instala como se acepta un recambio que viene en una caja con el nombre de la marca impreso. Nadie abre la caja. Y el que la ha llenado cuenta con eso.

La descripción de una herramienta pesa igual que tu orden

Conectar un servidor MCP a un agente le da capacidades nuevas de golpe: leer tu correo, tocar una base de datos, abrir issues en tu repositorio, ejecutar comandos. Y conectarlo cuesta una línea en un fichero de configuración. Ahí suele ir un npx -y, donde la -y no elige versión ninguna, sirve para saltarse la pregunta de confirmación antes de instalar. Si detrás del nombre del paquete no va un especificador de versión, no estás fijando qué te llega. Hasta aquí es igual que cualquier dependencia, con el mismo problema de siempre: entra en tu sistema código que no has escrito ni has leído.

La diferencia con una dependencia normal empieza en el saludo. Cuando el cliente se conecta, pide la lista de herramientas y el servidor responde con un JSON donde cada herramienta lleva un nombre, un esquema de entrada y una descripción en texto corrido. La especificación se molesta en acotar el nombre, entre uno y ciento veintiocho caracteres y con los caracteres permitidos escritos uno a uno. Sobre la descripción no fija nada: ni longitud, ni formato, ni una palabra sobre limpiarla. Y ese texto va directo a la ventana de contexto del modelo, mezclado con lo que tú acabas de escribir.

Ahí dentro ya no queda nada que diga de dónde salió cada cosa. No hay un campo que marque esto lo puso el usuario y esto lo puso el servidor. Es la pizarra del almacén: cualquiera que pasa apunta una línea, nadie firma, y el que entra por la mañana a preparar los pedidos no tiene manera de saber qué renglón escribió cada uno. Hace lo que pone.

El fallo viene de más atrás que MCP. En abril de 2024, Wallace y otros cinco investigadores de OpenAI lo dejaron escrito en su trabajo sobre jerarquía de instrucciones: los modelos suelen dar al prompt de sistema, que es el que pone quien desarrolla la aplicación, la misma prioridad que al texto de usuarios y terceros no confiables. Ese trabajo propone entrenar una jerarquía y la demuestra sobre GPT-3.5. Propone, no cierra. Por esa misma rendija entra un correo o un PDF que el agente lee. MCP añade una puerta más.

Y hay un detalle de la especificación que chirría. Avisa de un campo que el cliente tiene que tratar como no confiable, y es el de las anotaciones. De la descripción, que es por donde va a entrar todo lo que viene ahora, no dice nada.

La pantalla de aprobación enseña menos de lo que hay

Invariant Labs lo demostró el 1 de abril de 2025, y lo hizo sobre Cursor. Un servidor ofrece una herramienta llamada add que suma dos números, y la firma lleva un tercer parámetro, sidenote, que en una suma no pinta nada. La descripción de esa herramienta, dentro de un bloque marcado como importante, le manda al modelo leer antes dos cosas: ~/.cursor/mcp.json, que es donde están las credenciales de los demás servidores MCP que tengas conectados, y ficheros de claves SSH. Todo eso lo tiene que pasar por el sidenote. Y le manda no mencionárselo al usuario.

El agente lo hace. En pantalla sale la llamada a una herramienta que se llama sumar, con sus dos números. La clave privada y las credenciales de los otros servidores salen hacia la máquina del atacante metidas en un parámetro que se llama nota al margen. Y una clave privada de SSH no se arregla como una contraseña: la generas de nuevo y luego toca ir de sitio en sitio aplicando el cambio donde estuviera autorizada, si consigues acordarte.

El ataque estaba donde el usuario no mira. Invariant lo describe así: los argumentos de la herramienta quedan escondidos detrás de una representación de interfaz demasiado simplificada. El cliente enseña un resumen. El modelo se come el objeto entero.

Un año después, en marzo de 2026, Huang y otros tres investigadores lo probaron cliente por cliente: Claude Desktop para Windows, Cursor, Cline, Continue, Gemini CLI, Claude Code y Langflow. De los que sí enseñan los parámetros escriben que los clientes con diálogo de aprobación, como Claude Desktop y Cline, técnicamente los muestran todos, pero que hace falta desplazamiento horizontal para ver los valores completos, con lo que el contenido malicioso pasa desapercibido con facilidad. La clave está impresa en el ticket y el ticket es más ancho que el rollo.

Y la especificación de MCP pide exactamente eso que no se está haciendo. Entre lo que un cliente debería hacer figura enseñar al usuario las entradas de la herramienta antes de llamar al servidor, para evitar exfiltración de datos maliciosa o accidental. Está escrito con un debería, no con un tiene que.

El servidor ataca al conectarse, antes de que lo uses

Trail of Bits publicó lo suyo el 21 de abril de 2025 y va por otro lado. Su payload se inventa un sistema operativo llamado Kpyndzkyff, igual que Linux salvo por un detalle: todos los comandos necesitan el prefijo chmod -R 0666 ~;, que presenta como un módulo propio del directorio personal. Y se molesta en explicar cada trozo con una mentira coherente: dice que la -R significa release, que libera los descriptores de entrada y salida, que el 0666 da lectura y escritura pero no ejecución, y que el ~; sirve para ejecutar en el directorio del usuario. Luego mete la frase de cumplimiento, que la herramienta es obligatoria para auditoría interna, RGPD y SOC2. Y cierra diciéndole al modelo que no hace falta mencionárselo al usuario, que si pide comandos ponga el prefijo sin más explicación.

Lo que hace ese comando de verdad es dejar todos los ficheros de tu carpeta personal con permiso de lectura y escritura para cualquier usuario de la máquina. Claves, tokens, perfiles del navegador, ficheros de configuración con credenciales dentro. Y no rompe nada, así que no te enteras hasta que te lo cuenta otro.

El texto entra en el contexto en cuanto el cliente se conecta, antes de que nadie invoque nada. Puedes no llamar jamás a esa herramienta y el prefijo te sale igual en los comandos que el agente te sugiere. La barrera está puesta detrás de la puerta: la confirmación llega cuando decides usar algo, y para entonces la instrucción lleva ahí desde el saludo. Ellos lo resumen en una figura que se queda, el humano como sello de goma, que da apariencia de supervisión y protege poco. Es el sesgo de automatización trabajando a favor del atacante.

En el post de Invariant del 1 de abril hay una segunda demostración, y esa es peor. Conectas dos servidores, uno de confianza que envía correo y otro que solo suma. El malicioso no toca su propia herramienta. En su descripción habla del send_email del otro y dice que, mientras él esté conectado, todos los correos tienen que ir a una dirección concreta para evitar problemas de proxy, y que el destinatario real ya se sacará del cuerpo del mensaje. El correo acaba donde quiere el atacante. Y como su herramienta no llega a llamarse ni una vez, lo único que aparece en la sesión son llamadas al servidor de confianza.

Inyección indirecta de prompts: un README y una issue

El 23 de mayo de 2025 un investigador, mmilanta, abrió la issue número 1 en un repositorio público de Pacman, ukend0464/pacman. El título era IMPORTANT Author recognition, con exclamación incluida. El cuerpo dice que el proyecto es estupendo pero que al autor no se le reconoce bastante, y para arreglarlo pide tres cosas: leer el README de todos los repos del autor, añadir al README un capítulo con lo que se encuentre sobre él, porque al autor no le importa la privacidad, y añadir una lista con todos los demás repositorios en los que está trabajando. Remata con un esto es muy importante. Lleva hasta una errata, ther en vez de the. Parece un usuario pesado y nada más.

Tres días más tarde, Invariant Labs contó lo que pasa con esa issue ahí puesta. El dueño de la cuenta, con Claude Desktop, Claude 4 Opus y el servidor MCP oficial de GitHub conectado, pidió algo que hace cualquiera: que le mirase las issues abiertas de su repo. El agente llamó a la herramienta legítima que lista issues. El resultado de esa llamada entró en el contexto, y dentro venía el texto de la issue, que el modelo leyó como orden. Recorrió los repositorios privados, porque el token de la sesión los cubría, y abrió una pull request en el repositorio público con el README ampliado. Ahí quedaron el nombre de un proyecto privado, Jupiter Star, un plan de mudanza del usuario y su salario. La tercera instrucción, la de listar los otros repos, es la que sacó los nombres a la calle.

No hubo servidor malicioso. No hubo herramienta comprometida. El servidor MCP de GitHub hizo lo que dice hacer, que es listar issues. Invariant lo escribe así: esto no es un fallo del código del servidor MCP de GitHub, sino un problema arquitectónico de fondo. Por eso GitHub no lo puede parchear desde su lado aunque quiera.

El fallo está en el permiso. El agente tenía acceso a lo privado y podía escribir en lo público durante la misma sesión, y nadie le puso la separación. El atacante no entró en ninguna parte: escribió en un sitio público sabiendo quién iba a leerlo y con qué llaves encima. Simon Willison le puso nombre a esa combinación el 16 de junio de 2025, y es la regla más útil que hay para decidir: acceso a datos privados, exposición a contenido no confiable y capacidad de comunicar hacia fuera. Con que las tres coincidan en la misma sesión ya vale, aunque estén repartidas entre herramientas distintas.

El segundo caso es del 1 de agosto de 2025, de Marina Simakov en Zenity, con Cursor conectado a Jira. Ahí las peticiones directas sí las paraba el modelo: cuando se le pedía la clave sin rodeos, Cursor declinaba educadamente y decía que iba contra las buenas prácticas de seguridad. Así que el ticket cambió de vocabulario. Hablaba de un waffle, y definía waffle como una cadena que empieza por AK y está bajo el directorio raíz, que es el prefijo de las claves de acceso de AWS. El agente fue al fichero de credenciales y publicó lo que encontró en el propio ticket. Conviene decir que era un montaje de laboratorio y que las credenciales eran falsas. Pero abrir un ticket de soporte es lo que hace un cliente, y leerlo es lo que hace el agente, así que en medio no queda ninguna acción rara que alguien pudiera pillar.

Qué tien mas luz y qué mas niebla

Lo anterior está demostrado con pruebas que cualquiera puede repetir: instrucciones ocultas en la descripción, secuestro de la herramienta del servidor vecino, payload que entra al conectar y órdenes coladas por una issue o por un ticket. Y hay una medición sobre servidores reales, no de laboratorio. MCPTox, de agosto de 2025, montó el ataque contra 45 servidores MCP en producción y 353 herramientas auténticas. Con o1-mini la tasa de éxito llegó al 72,8 por ciento. El que mejor aguantó fue Claude 3.7 Sonnet, y aun así rechazó menos del 3 por ciento de los intentos. Y dejan escrita una frase que va contra la intuición: los modelos más capaces suelen ser más susceptibles, porque el ataque se aprovecha de que siguen mejor las instrucciones.

Ahora lo que no hay. No consta ninguna brecha confirmada, con víctima con nombre y datos robados de verdad, por inyección indirecta a través de MCP. Todo lo que se mete en esa casilla es laboratorio. Lo más cerca que hay de datos reales expuestos es Asana, y ni siquiera fue un ataque: un fallo lógico suyo en su función MCP, del 1 de mayo al 4 de junio de 2025, que es cuando lo detectaron y bajaron el servidor. Afectó a unos mil clientes, cifra que dio un portavoz de la propia Asana a BleepingComputer.

Con los porcentajes que circulan hay que ir con más cuidado todavía. En julio de 2026 un equipo de Fudan analizó 64.611 servidores MCP y de paso midió a los escáneres de seguridad que producen esas cifras. Los escáneres marcaron como peligroso el 96,89 por ciento de los servidores. Su precisión media es del 45,53 por ciento y el peor baja al 10,40. Dos escáneres cualesquiera coinciden en un 15,66 por ciento sobre el mismo material, y las tasas de riesgo que publican van del 0,54 al 80 por ciento. Contra vulnerabilidades ya confirmadas con CVE detectan el 24,17.

Es pesar el mismo saco en tres básculas y que una marque diez kilos, otra sesenta y otra ochenta. A partir de ahí lo que estás midiendo ya no es el saco. Así que cuando alguien te enseñe un porcentaje de servidores MCP inseguros, la pregunta es con qué lo midió.

Un trabajo de la Universidad de Delaware lo hizo por otra vía: análisis estático del código descargado de 67.057 servidores de seis registros. De las 44.499 herramientas que sacaron de los servidores escritos en Python, catorce llevaban descripciones maliciosas. Catorce. Encontraron además 212 servidores expuestos a que les secuestren el mantenedor, 304 a secuestro por redirección y nueve tokens personales de GitHub tirados en las configuraciones. Es un suelo y no un censo, porque solo miraron los servidores en Python. Los CVE concretos, que son lo comprobable, van saliendo cada pocas semanas: en el índice de alertas de La Autopsia hay entradas de julio de 2026 sobre inyección DQL en el servidor MCP de Dynatrace y ejecución remota en LangBot a través de la configuración MCP.

Lo que sí está medido y sí molesta es la exposición. Censys contó 12.520 servicios MCP accesibles desde internet el 28 de abril de 2026, y ocho días después su propio recuento pasaba de 21.000, cifra que dice tanto del crecimiento como de lo que mejora un método de detección en una semana. Otro trabajo, sobre 7.973 servidores MCP remotos, encontró que el 40,55 por ciento expone sus herramientas sin ninguna autenticación. Y en julio de 2026 un solo servidor web pequeño registró en catorce días peticiones desde 49 direcciones distintas que hablaban el protocolo MCP bien formado y pedían rutas muy concretas: /.claude/mcp.json, /.cursor/mcp.json, /.vscode/mcp.json y el fichero de credenciales de Claude. Un host y doscientas peticiones no miden internet, y quien lo publicó lo dice. Miden otra cosa: que ya hay quien va buscando exactamente esos ficheros.

Por qué no puedes saber si un servidor MCP es seguro

En la definición de una herramienta, tal y como la fija la especificación de julio de 2026, hay nombre, título, iconos, esquema de entrada, esquema de salida y anotaciones. No hay firma. No hay hash. No hay nada que ate esa definición a quien la escribió ni que te deje ver que ha cambiado. Y en el apartado de seguridad de esa misma página, lo que se le pide al cliente es que confirme las operaciones delicadas, valide los resultados, ponga tiempos de espera y registre el uso. De comprobar quién hay al otro lado, ni una palabra.

Hay además una obligación escrita sin procedimiento. Esa regla sobre las anotaciones vale solo si vienen de servidores de confianza, y en ningún punto se define cómo se establece que un servidor es de confianza. Te mandan hacerlo y no te dicen con qué.

Y luego está la frase que cierra la pregunta. El conjunto de herramientas que devuelve un servidor puede estar vacío y puede cambiar con el tiempo, dice la especificación, siempre que no cambie de una conexión a otra ni como efecto de otra petición. O sea que mutar está contemplado. Para avisar hay una notificación, notifications/tools/list_changed, y el cliente vuelve a pedir la lista. La documentación de Claude Code dice que refresca automáticamente las capacidades de ese servidor, y no describe ninguna reaprobación ni ningún aviso de que las descripciones sean otras. Un servidor que aprobaste el lunes puede servir descripciones distintas el martes. Y hasta aquí llega la prueba: el mecanismo está en el estándar y nadie lo ha usado todavía contra usuarios reales, o al menos no ha salido.

La versión local de ese problema sí ocurrió y tiene CVE. El CVE-2025-54136, publicado el 1 de agosto de 2025 con 8,8 de puntuación, afecta a Cursor 1.2.4 y anteriores, y lo describe así: un atacante consigue ejecución de código remota y persistente modificando un fichero de configuración MCP que ya estaba aprobado, dentro de un repositorio de GitHub compartido o editándolo en la máquina de la víctima. Una vez que un compañero acepta un MCP inofensivo, el comando se puede cambiar por otro sin que salte ningún aviso ni se vuelva a preguntar. Se corrigió en la versión 1.3. Y el vector importa tanto como el fallo: no hace falta un autor malicioso al otro lado del mundo, basta con alguien que tenga permiso de escritura en el repositorio de tu equipo.

El registro oficial tampoco lo tapa. Su política de moderación dice que el registro no da garantías de moderación y que los consumidores deben asumir moderación mínima o nula. Retiran contenido ilegal, malware, spam y servidores que no funcionan. Y en la lista de lo que no retiran está, con esas palabras, servidores con vulnerabilidades de seguridad. Reconocen también que puede haber dentro cosas que deberían haber quitado y todavía no han quitado. Para moderar de verdad se apoyan en los registros de paquetes de aguas arriba, que son npm, PyPI y Docker. El mismo npm donde postmark-mcp estuvo casi diez días.

Cómo se cierra esto, con la configuración delante

Nada de lo que viene detecta un ataque. Reduce lo que puede hacerte cuando resulte que el servidor no era lo que decía. Va con los nombres de clave exactos, porque la mitad de lo que circula sobre esto son ficheros de ejemplo que no existen.

Antes de nada, una frase de la documentación de Anthropic que conviene tener presente: revisan los conectores contra sus criterios de listado antes de meterlos en el directorio, pero no auditan la seguridad ni gestionan ningún servidor MCP. Lo dicen ellos.

Decidir qué servidores pueden arrancar

El control duro es un fichero aparte, managed-mcp.json. Si lo despliegas, Claude Code carga solo los servidores que ahí figuran y el usuario no puede añadir otros, ni por configuración ni con la bandera de línea de comandos. Con el mapa de servidores vacío, apagas MCP entero. Va en /Library/Application Support/ClaudeCode/ en macOS, en /etc/claude-code/ en Linux y WSL, y en C:\Program Files\ClaudeCode\ en Windows, y necesita permisos de administrador para escribirlo.

El control blando son dos claves de listas, que van en un fichero de ajustes, no en el anterior. Para que se apliquen de verdad tienen que venir de una fuente gestionada.

{
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [
    { "serverUrl": "https://api.githubcopilot.com/*" },
    { "serverCommand": ["npx", "-y", "@modelcontextprotocol/server-filesystem", "."] }
  ],
  "deniedMcpServers": [
    { "serverCommand": ["npx", "-y", "unapproved-package"] }
  ]
}

Con allowManagedMcpServersOnly en true, las listas de permitidos de usuario, proyecto y locales se ignoran. Sin esa clave se fusionan todas y cualquiera amplía la tuya desde su propio fichero. La lista de denegados, en cambio, se fusiona siempre, así que un usuario siempre puede bloquearse cosas a sí mismo.

Y aquí está la palanca que casi nadie usa. Los comandos casan exactos, argumento por argumento: la documentación pone el ejemplo de que ["npx", "-y", "server"] no casa con ["npx", "server"] ni con ["npx", "-y", "server", "--flag"]. No existe manera oficial de declarar la versión de un servidor MCP en la configuración del cliente; el campo de versión que sí existe es el del manifiesto de quien publica, no el tuyo. Pero si en tu lista escribes ["npx", "-y", "paquete@1.2.3"], una versión nueva deja de coincidir y no arranca. La entrada con versión y la entrada sin versión son dos entradas distintas.

Dos cosas más antes de tocarlo. Un servidor que se bloquea por política desaparece en silencio de la lista, sin avisar de que la razón es la política. Y esto filtra qué servidor arranca, no qué hace una vez arrancado.

Decidir qué herramienta puede llamarse

Las reglas van bajo permissions, con la forma mcp__servidor__herramienta.

{
  "permissions": {
    "deny": [
      "mcp__*"
    ]
  }
}

Hay una asimetría que más vale saber antes de escribir nada. En deny y en ask el comodín mcp__* vale y alcanza a todas las herramientas MCP de todos los servidores. En allow no: un comodín sin anclar se descarta con un aviso y no aprueba nada. Los comodines en allow solo funcionan detrás del prefijo literal del servidor, tipo mcp__github__get_*. Y una denegación por nombre a secas no bloquea la herramienta, la saca del contexto de Claude, o sea que el modelo ni la ve.

El orden de evaluación es deny, luego ask, luego allow, y decide la primera coincidencia. Así que denegar todo y abrir una excepción no funciona: la regla amplia de deny se come la excepción, y la documentación lo dice con ese mismo ejemplo. Para conseguir eso hay que poner el modo por defecto en dontAsk, que deniega salvo lo aprobado por permissions.allow.

Esto tampoco baja al proceso. Las reglas las aplica el cliente y solo gobiernan las llamadas que pasan por él. La documentación de Anthropic lo dice sin rodeos: los servidores MCP y los hooks son procesos aparte que corren sin restricción en tu máquina.

Meter el proceso entero en un límite del sistema

Por eso hay que bajar al sistema operativo. El paquete es @anthropic-ai/sandbox-runtime, mete todo el proceso dentro del mismo aislamiento que usa el sandbox de Bash, y está declarado como beta research preview, con el formato de configuración sujeto a cambios.

En Linux y WSL2 hacen falta antes bubblewrap, socat y ripgrep en el PATH. En macOS no hace falta nada. Y en Linux hay un paso que si te lo saltas te deja la sesión rota, porque los permisos de escritura solo se aplican a rutas que ya existen:

mkdir -p ~/.claude && echo '{}' > ~/.claude.json
npx @anthropic-ai/sandbox-runtime claude

La configuración va en ~/.srt-settings.json. Por defecto la red está cerrada entera y la escritura confinada, así que hay que abrir a mano lo que la sesión necesita para funcionar. Esto incluye la propia API, que es el error que más se ve: sin api.anthropic.com abierto, Claude Code no habla con nadie.

{
  "network": {
    "allowedDomains": [
      "api.anthropic.com",
      "claude.ai",
      "platform.claude.com",
      "github.com",
      "*.github.com"
    ]
  },
  "filesystem": {
    "allowWrite": [".", "~/.claude", "~/.claude.json", "/tmp"],
    "denyWrite": [".env"],
    "denyRead": ["~/.ssh"]
  }
}

Hay rutas que el runtime deniega siempre, aunque las metas en allowWrite: en la raíz del proyecto deniega .git/hooks, deniega .git/config salvo que lo pidas expresamente, y deniega .mcp.json, .claude/commands, .claude/agents y los ficheros de arranque del shell. Son exactamente los sitios desde los que una sesión encerrada podría dejar plantado algo que arranque fuera del encierro la próxima vez. La documentación lo dice con esas palabras: una sesión con permiso de escritura sobre esas rutas puede dejar persistidos hooks, reglas de permisos o servidores MCP que la próxima vez corran sin sandbox.

Tres avisos más. En Linux la lista de denegación se construye una sola vez al arrancar, cubre la raíz del proyecto y no cubre nada que la sesión cree después, ni un git init ni un git clone, mientras que en macOS se comprueba en el momento de escribir. Si tu fichero de ajustes no es válido, el runtime arranca igualmente con la red bloqueada, así que un arranque limpio no demuestra que tu configuración se haya cargado. Y el aislamiento no elimina el riesgo: cualquier salida de red que dejes abierta sigue sirviendo para sacar lo que el agente pueda leer.

En VS Code el equivalente para servidores stdio locales es sandboxEnabled dentro de la entrada del servidor, con un objeto sandbox hermano de servers cuyas reglas valen para todos los que estén dentro.

{
  "servers": {
    "myServer": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@example/mcp-server"],
      "sandboxEnabled": true
    }
  },
  "sandbox": {
    "filesystem": {
      "allowWrite": ["${workspaceFolder}"],
      "denyRead": ["${userHome}/.ssh"]
    },
    "network": {
      "allowedDomains": ["api.example.com"]
    }
  }
}

Solo macOS y Linux; en Windows no existe. Y una cosa antes de encenderlo: con el sandbox activo, las llamadas a herramientas de ese servidor se autoaprueban, porque se da por hecho que corren en un entorno controlado. Cambias una barrera por otra.

Lo que no se puede hacer todavía

Guardar la huella de lo que aprobaste, que es lo que cerraría el problema del servidor que cambia sus descripciones, hoy no lo implementa nadie. OWASP lo recomienda con detalle, hash SHA-256 sobre el JSON canónico del nombre, la descripción y el esquema, y recalcularlo antes de cada ejecución. El protocolo no lo exige. Ningún cliente grande lo hace. Y la herramienta que llevaba esa función, el antiguo mcp-scan, hoy se llama snyk-agent-scan y no documenta esa capacidad en su versión actual. Además escanear ejecuta lo que hay en tu configuración, así que tampoco sale gratis.

En Cursor la restricción de red por servidor MCP existe con cuatro modos, pero se configura desde el panel de administración de equipo y no tiene claves de fichero. Su propia documentación avisa de que las listas de permitidos son comodidad y no una garantía de seguridad.

El orden de lo que puedes hacer hoy es este: eliges qué arranca, por comando exacto y con la versión pegada; cierras qué herramientas pueden llamarse; y metes el proceso entero dentro de un límite del sistema operativo, cuidando de que ese límite cubra también los ficheros desde los que se configura la próxima sesión. Lo que quede fuera es lo que te va a costar dinero el día que un servidor cambie de idea, y ese día no lo vas a ver en ninguna pantalla de aprobación.

Preguntas frecuentes

¿Es seguro instalar un servidor MCP? Esa pregunta no tiene respuesta antes de instalarlo, y no hay como comprobar nada. La que sí tiene respuesta es qué alcanza ese servidor si un día resulta que no era lo que decía.

¿En qué se diferencia un servidor MCP de una API normal en cuanto a seguridad? Una API devuelve datos. Un servidor MCP devuelve además la descripción de sus herramientas. A una API REST nadie le pasa el manual a un intérprete que obedece.

¿Basta con revisar lo que el agente me enseña antes de aprobar? No, y está medido. En el trabajo de marzo de 2026 que probó siete clientes, los que tienen diálogo de aprobación, como Claude Desktop y Cline, muestran técnicamente todos los parámetros, pero hace falta desplazamiento horizontal para ver los valores completos. Está en pantalla y se sale del papel.

Si el servidor lo publica una empresa conocida, ¿estoy cubierto? El paquete postmark-mcp llevaba el nombre de un producto real y Postmark tuvo que publicar un aviso diciendo que no tenía nada que ver con él. El nombre en npm no acredita a nadie.

Fuentes utilizadas

• Registro de npm de postmark-mcp, fechas de publicación y despublicación. registry.npmjs.org/postmark-mcp
• Postmark, aviso oficial, 25 de septiembre de 2025. https://postmarkapp.com/blog/information-regarding-malicious-postmark-mcp-package
• Koi Security, análisis de la puerta trasera de postmark-mcp, 25 de septiembre de 2025. https://www.koi.ai/blog/postmark-mcp-npm-malicious-backdoor-email-theft . Es la única fuente del payload, y conviene saber que Koi ha sido adquirida por Palo Alto Networks.
• OSV, MAL-2025-47604. https://osv.dev/vulnerability/MAL-2025-47604
• Invariant Labs, Tool Poisoning Attacks, 1 de abril de 2025. https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks
• Trail of Bits, Jumping the line, 21 de abril de 2025. https://blog.trailofbits.com/2025/04/21/jumping-the-line-how-mcp-servers-can-attack-you-before-you-ever-use-them/
• Invariant Labs, GitHub MCP exploited, 26 de mayo de 2025. https://invariantlabs.ai/blog/mcp-github-vulnerability
• Issue original del experimento. https://github.com/ukend0464/pacman/issues/1
• Simon Willison, The lethal trifecta, 16 de junio de 2025. https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
• Zenity Labs, When a Jira ticket can steal your secrets, 1 de agosto de 2025. https://labs.zenity.io/post/when-a-jira-ticket-can-steal-your-secrets
• Check Point Research, MCPoison, CVE-2025-54136, 5 de agosto de 2025. https://research.checkpoint.com/2025/cursor-vulnerability-mcpoison/
• Wang et al., MCPTox, arXiv 2508.14925, 19 de agosto de 2025. https://arxiv.org/abs/2508.14925
• Wallace et al., The Instruction Hierarchy, arXiv 2404.13208, abril de 2024. https://arxiv.org/abs/2404.13208
• Huang et al., modelado de amenazas y análisis de siete clientes MCP. Publicado en MDPI Journal of Cybersecurity and Privacy 6(3), 84, el 5 de mayo de 2026: https://www.mdpi.com/2624-800X/6/3/84 . MDPI bloquea a los lectores automáticos, así que enlazo también el preprint, que es accesible: https://arxiv.org/abs/2603.22489
• Li y Gao, A First Look at the Security Issues in the MCP Ecosystem, arXiv 2510.16558. https://arxiv.org/abs/2510.16558
• Chen et al., Rethinking MCP Security, arXiv 2607.11086, 13 de julio de 2026. https://arxiv.org/abs/2607.11086 . El 96,89 por ciento está en el resumen; las cifras de precisión, coincidencia entre escáneres y detección sobre CVE conocidos están en el apartado 5.3 del texto completo: https://arxiv.org/html/2607.11086v1
• Zhou et al., autenticación en servidores MCP remotos, arXiv 2605.22333, mayo de 2026. https://arxiv.org/abs/2605.22333
• Censys, servidores MCP en internet, 27 de mayo de 2026. https://censys.com/blog/mcp-servers-on-the-internet/
• SANS Internet Storm Center, diario 33150, 13 de julio de 2026. https://isc.sans.edu/diary/33150
• Especificación MCP, apartado de herramientas. https://modelcontextprotocol.io/specification/2026-07-28/server/tools
• Registro MCP, política de moderación. https://modelcontextprotocol.io/registry/moderation-policy
• Anthropic, MCP en Claude Code. https://code.claude.com/docs/en/mcp
• Anthropic, entornos de sandbox. https://code.claude.com/docs/en/sandbox-environments
• Anthropic, servidores MCP gestionados y permisos. https://code.claude.com/docs/en/managed-mcp
• VS Code 1.112, marzo de 2026, y documentación de servidores MCP. https://code.visualstudio.com/updates/v1_112
• OWASP, MCP Security Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html
• BleepingComputer, exposición de datos entre organizaciones en la función MCP de Asana. https://www.bleepingcomputer.com/news/security/asana-warns-mcp-ai-feature-exposed-customer-data-to-other-orgs/