¿Cómo revisar la seguridad MCP en un pull request?

¿Cómo entra un servidor MCP en un repositorio?

Este artículo se fija en la configuración que un pull request trae para el agente de programación. En el artículo sobre hooks hablamos de los comandos que el agente ejecuta por su cuenta en momentos concretos, y en el artículo sobre cómo revisar el código generado por IA, del código que escribe el agente. Aquí el tema es el archivo que le da al agente una herramienta nueva.

MCP (Model Context Protocol) es, según la definición de la propia especificación, un protocolo abierto que conecta las aplicaciones de IA con fuentes de datos y herramientas externas. A un lado está el agente y al otro, un servidor MCP. El servidor define las herramientas (tools) que el modelo puede llamar: leer una issue, abrir un navegador, consultar una base de datos. A fecha de 18 de octubre de 2026, la versión más reciente de la especificación tiene fecha 2026-07-28.

Casi siempre, el servidor es un programa que se ejecuta en tu propia máquina. La herramienta de programación lo arranca con las líneas command y args del archivo de configuración y habla con él por la entrada y la salida estándar del programa; la especificación lo llama stdio. En un servidor remoto, el archivo contiene una dirección (url) en lugar de un comando. Este archivo va en el commit junto con el código: la documentación de Claude Code recomienda poner .mcp.json bajo control de versiones para que todo el equipo use las mismas herramientas. Cada herramienta mira un archivo distinto:

Fuente: la documentación de MCP de cada herramienta, 18 de octubre de 2026. Copilot CLI no lee el archivo .vscode/mcp.json de VS Code. En Antigravity CLI, el archivo del repositorio es .agents/mcp_config.json.

La especificación de MCP dice en una frase lo que esto significa: «Tools represent arbitrary code execution and must be treated with appropriate caution.» La guía de seguridad de la especificación pide además a los clientes que avisen al usuario de que los servidores MCP se ejecutan con los mismos privilegios que el cliente. Así que una línea añadida a .mcp.json es el nombre de un programa que se ejecutará en la máquina de todo el equipo, con los permisos de cada uno.

¿Qué es el tool poisoning?

El modelo decide cuándo y cómo llamar a una herramienta mirando su nombre y su descripción. Invariant Labs explicó el hueco que deja esto en un artículo del 1 de abril de 2025: el modelo lee la descripción completa, mientras que el usuario suele ver en la interfaz una versión simplificada. El tool poisoning consiste en esconder en esa descripción instrucciones que el modelo lee y el usuario no ve. El ejemplo de Invariant es una herramienta que suma dos números:

El código del servidor no hace nada malo: suma dos números. Lo malo lo hace el modelo. Sigue la instrucción de la descripción, lee dos archivos y envía su contenido al servidor en el argumento sidenote. La instrucción también le pide que no se lo diga al usuario. Invariant probó esta herramienta con Cursor y mostró cómo el agente filtraba el archivo mcp.json del usuario. La especificación de MCP pide a los clientes que muestren al usuario las entradas de una herramienta antes de llamar al servidor, para que no se filtren datos.

Invariant señala dos cosas más. La primera es el rug pull: un servidor malicioso puede cambiar la descripción de una herramienta después de que el cliente lo haya aprobado. Según la especificación, la lista de herramientas de un servidor también puede cambiar con el tiempo. La segunda es la medida que recomiendan: fijar la versión del servidor y de sus herramientas.

La especificación de MCP no usa el nombre «tool poisoning», pero ve el problema de la misma forma: las descripciones que explican el comportamiento de una herramienta deben considerarse no confiables, salvo que vengan de un servidor de confianza. El blog de seguridad de Microsoft dice lo mismo: un cambio en la descripción de una herramienta puede redirigir el comportamiento del agente con la misma eficacia que un cambio en su prompt de sistema.

También hay un estudio que mide con qué frecuencia funciona este ataque. MCPTox creó 1.348 casos de prueba envenenados sobre 353 herramientas de 45 servidores MCP reales y los probó con 20 configuraciones de modelos. El éxito medio de los ataques fue del 36,5 %; la tasa más alta, del 72,8 %, con o1-mini. El modelo que más veces rechazó el ataque fue Claude-3.7-Sonnet, y aun así su tasa de rechazo quedó por debajo del 3 %. Son modelos de 2025, el año en que se escribió la primera versión del artículo; este estudio no midió los modelos actuales.

En el MCP Top 10 de OWASP, que está en beta, el tercer punto (MCP03) es Tool Poisoning. La página de detalle de ese punto dice que una descripción así se puede detectar leyéndola antes de instalar, y enumera cinco señales. La pregunta «El código del servidor» de la lista de abajo sale de esas señales.

¿Por qué un agente hace lo que no debe al leer una issue?

La segunda vía pasa por el contenido que trae el servidor. La descripción de la herramienta puede estar limpia; pero si la herramienta trae una issue, una página web o un mensaje de chat, ese texto también entra en el contexto del modelo, y la instrucción que contiene también se lee. Esto se llama prompt injection indirecta.

Un ejemplo de Invariant Labs del 26 de mayo de 2025 lo mostró con el servidor MCP oficial de GitHub. Un atacante abre una issue en un repositorio público. Cuando el usuario le pide a su agente que mire las issues abiertas, el agente lee esa issue, mete en su contexto información de los repositorios privados del usuario y la escribe en un pull request que él mismo abre en el repositorio público. Los autores escriben que no es un error del código del servidor MCP de GitHub, sino un problema de la arquitectura del sistema de agentes.

El peligro no está en una capacidad sola, sino en que se junten: el mismo agente puede leer texto de fuera, acceder a datos privados y escribir donde todos lo ven. Invariant recomienda limitar el agente a un único repositorio por sesión. Aprobar cada llamada a una herramienta tampoco basta por sí solo: según los autores, muchos usuarios activan «Always Allow» y dejan de seguir las acciones una a una. La documentación de Claude Code hace la misma advertencia: «Servers that fetch external content can expose you to prompt injection risk.»

La misma vía puede llevar al agente a escribir su propia configuración de MCP. Según el registro CVE-2025-54135 de la NVD, en Cursor antes de la versión 1.3.9, si .cursor/mcp.json todavía no existía, una prompt injection indirecta podía llevar al agente a escribir ese archivo, y el código podía ejecutarse sin la aprobación del usuario. Hoy Claude Code incluye .mcp.json entre los archivos protegidos y nunca aprueba por su cuenta una escritura en él, salvo en el modo que se salta todas las peticiones de permiso. Cursor tampoco deja que el agente cambie los archivos de configuración sin aprobación. Si un pull request abierto por un agente toca el archivo MCP, mira quién pidió ese cambio.

El propio código del servidor también tiene que resistir ese texto. Según la especificación de MCP, las herramientas las llama el modelo; es decir, los argumentos también los escribe el modelo. Si un texto que el modelo lee puede dirigirlo, ese texto también puede decidir el argumento. Los registros que la NVD publicó para el servidor Git MCP de referencia (mcp-server-git) muestran dos errores que conviene buscar en ese tipo de código:

Fuente: registros de la NVD, 18 de octubre de 2026. La NVD publicó los dos primeros el 17 de diciembre de 2025.

Las correcciones también dicen qué mirar: rechazar un argumento que empiece por -, resolver la ruta pedida siguiendo los enlaces simbólicos y comprobar que se queda dentro de la carpeta permitida.

¿Cuándo arrancan las herramientas un servidor MCP del repositorio?

Cada herramienta deja pasar por una puerta distinta a un servidor que llega con el repositorio. La tabla de abajo recoge lo que leímos el 18 de octubre de 2026 en la documentación de cada herramienta:

Fuente: la documentación de cada herramienta, 18 de octubre de 2026. «La documentación no lo dice»: en las páginas que leímos ese día no encontramos ninguna frase que describa este caso. La documentación tampoco dice qué pasa con los servidores del repositorio en Gemini CLI mientras la confianza en carpetas está desactivada. Check Point escribe que Cursor vuelve a preguntar con cada cambio desde la versión 1.3; la documentación de Cursor no tiene esa frase.

La palabra que más se repite en la tabla es confianza. La mayoría de las herramientas no abren los servidores del repositorio uno a uno, sino junto con la confianza que das a una carpeta o a un espacio de trabajo. Por eso la documentación de VS Code te dice que mires la configuración de MCP antes de confiar en un repositorio, porque los servidores MCP locales pueden ejecutar código en tu máquina.

También importa cuántos clics hacen falta para pasar la pregunta de confianza. Adversa AI escribe en su artículo TrustFall del 7 de mayo de 2026 que las cuatro CLI que probó (Claude Code, Gemini CLI, Cursor CLI y Copilot CLI) podían ejecutar los servidores MCP definidos en un repositorio en cuanto se aceptaba la confianza en la carpeta, y que en las cuatro la opción por defecto era «Yes/Trust». Según el artículo, en Claude Code 2.1.129 lo que lo hacía posible eran los ajustes enableAllProjectMcpServers y enabledMcpjsonServers que venían en un commit del repositorio. La documentación actual de Claude Code dice que, en una carpeta que no es de confianza, estos ajustes del repositorio se ignoran; qué pasa después de confiar en la carpeta, la documentación no lo dice.

El 18 de junio de 2026, Google dejó de dar servicio en Gemini CLI a los usuarios gratuitos y a los suscriptores de Google AI Pro y Ultra, y los dirigió a Antigravity CLI; con una clave de API de pago o una licencia de empresa puedes seguir usando Gemini CLI. El 28 de octubre de 2026 leímos la documentación de Antigravity CLI. Según su página de MCP, los servidores del repositorio están en .agents/mcp_config.json y los del usuario en ~/.gemini/config/mcp_config.json; en un pull request, el archivo al que hay que prestar atención es el primero. Por defecto, una herramienta MCP que tus reglas de permisos no mencionan pide aprobación antes de que se la llame. La CLI también te pregunta si confías en la carpeta. La documentación no dice si los servidores del repositorio esperan esa respuesta ni si la CLI vuelve a preguntar cuando cambia la configuración.

¿Qué pasa si el servidor cambia después de aprobarlo?

La aprobación se da una vez, pero el servidor sigue cambiando. La vulnerabilidad que Check Point Research bautizó como MCPoison mostró adónde puede llevar eso: Cursor ataba la confianza al nombre del servidor y no comprobaba si el comando o los argumentos habían cambiado. Según el registro de la NVD (CVE-2025-54136), en Cursor 1.2.4 y versiones anteriores, cualquiera que pudiera escribir en un repositorio compartido podía cambiar un servidor inofensivo, que un compañero había aprobado una vez, por un comando malicioso, sin ningún aviso ni nueva petición de aprobación.

Check Point comunicó la vulnerabilidad a Cursor el 16 de julio de 2025, y Cursor la corrigió el 29 de julio de 2025 con la versión 1.3. Según Check Point, ahora cualquier cambio en la configuración, incluso añadir un espacio, pide una nueva aprobación. En la propia documentación de Cursor no encontramos ninguna frase que describa este comportamiento.

La documentación de las demás herramientas o responde a esta pregunta de otra forma o no la toca. VS Code lo dice claro: en un espacio de trabajo de confianza, los servidores de .vscode/mcp.json y del .mcp.json de la raíz pueden arrancar sin una petición de aprobación MCP aparte, «including after their configuration changes». En Claude Code, la lista de aprobación (enabledMcpjsonServers) guarda los nombres de los servidores; si vuelve a preguntar cuando cambia el comando bajo el mismo nombre, la documentación no lo dice. La documentación de MCP de Cursor, Codex y Gemini CLI tampoco tiene ninguna frase sobre esto.

Para comparar: Codex y Gemini CLI sí responden a la misma pregunta para los hooks. Codex te pide revisar y aprobar la definición exacta de un hook que viene del repositorio antes de ejecutarlo. Gemini CLI trata un hook cuyo nombre o comando ha cambiado como un hook nuevo y no confiable, y avisa antes de ejecutarlo. Para los servidores MCP, ninguna de las dos documentaciones tiene una frase parecida.

Las herramientas de un servidor también pueden cambiar mientras se ejecuta. El servidor lo avisa con una notificación (list_changed); en una sesión interactiva, Claude Code vuelve a pedir la lista de herramientas cuando llega esa notificación. Si las descripciones cambiadas se muestran al usuario, la documentación no lo dice.

En resumen, la aprobación de tu portátil vio la primera versión del servidor. Aunque el nombre no cambie, el sitio donde puedes ver sus versiones posteriores es el diff del pull request.

¿Un agente que se ejecuta en CI carga los servidores MCP del repositorio?

En una ejecución no interactiva no hay nadie para aprobar. La documentación de Claude Code lo dice claramente: en las ejecuciones claude -p, las sesiones del Agent SDK y las sesiones en la nube, Claude Code no puede mostrar la petición de aprobación y carga los servidores del proyecto sin preguntar. La tabla de la documentación de permisos toma una ejecución claude -p en una carpeta en la que nunca se ha confiado y describe sus servidores .mcp.json en una frase: «Connected without asking, approved or not.»

Antes de ejecutar claude -p en un repositorio que no escribiste tú, la documentación de Claude Code señala estas opciones:

• --setting-sources user: no lee ni los archivos de configuración del proyecto ni su .mcp.json.
• --bare: no lee del proyecto hooks, skills, subagentes, plugins ni servidores de .mcp.json; el bloque env del proyecto se sigue aplicando.
• --strict-mcp-config: solo usa los servidores que pasas con --mcp-config.
• disabledMcpjsonServers: bloquea un servidor por su nombre, en todos los modos de permisos.

Las demás herramientas se comportan de otra manera. El modo prompt de Copilot CLI (copilot -p) carga por su cuenta los servidores del proyecto si ya se confía en la carpeta y, si no, los omite. En Cursor CLI, la opción --approve-mcps aprueba automáticamente todos los servidores MCP, y --trust confía en el espacio de trabajo sin preguntar en modo headless. Si un archivo de workflow añade una de estas opciones, léelo también como un cambio de MCP. La documentación de Codex y la de Gemini CLI no dicen qué pasa con un servidor del repositorio en una ejecución no interactiva.

En la GitHub Action que se ejecuta en los pull requests hay una distinción más. La documentación de seguridad de claude-code-action explica que, cuando la acción se ejecuta en un pull request, restaura desde la rama base una lista fija de rutas de configuración de Claude (8 rutas, entre ellas .mcp.json) antes de que arranque Claude; las versiones que trae el pull request se guardan en una carpeta aparte, solo como referencia. El resto del árbol de trabajo queda como está en el pull request. La claude-code-base-action, de más bajo nivel, en cambio, no hace esta restauración. El artículo TrustFall de Adversa había escrito que con el uso por defecto de la acción oficial la pregunta de confianza no aparece nunca y que el ataque funciona contra las ramas de pull request sin que nadie toque nada; la documentación actual de la acción describe la restauración de arriba.

En el agente en la nube de GitHub Copilot, en cambio, la configuración de MCP no es un archivo del repositorio: se introduce en los ajustes del repositorio en GitHub.com, y Copilot code review usa la misma configuración. Por eso no aparece en el diff del pull request. Según la documentación, el agente usa estas herramientas sin pedir aprobación; por eso GitHub recomienda añadir a la lista de permitidas, una a una, herramientas de solo lectura.

¿Qué hay en la lista de riesgos MCP de OWASP?

El MCP Top 10 de OWASP agrupa los riesgos propios de MCP en 10 apartados. La propia página dice que la lista está en beta. El 18 de octubre de 2026, los apartados en owasp.org eran estos:

Fuente: owasp.org, 18 de octubre de 2026. El repositorio de GitHub del proyecto llama a MCP06 «Intent Flow Subversion» y da octubre de 2026 como fecha de la próxima versión; los nombres pueden cambiar.

Usa la lista como un vocabulario común, no como un estándar: sirve para ponerle nombre a un hallazgo. La mayoría de las preguntas de abajo corresponden a MCP01, MCP03, MCP04, MCP05 y MCP06.

¿Qué revisar en un pull request que cambia un archivo MCP?

Todo lo anterior lleva a una sola conclusión: la pantalla de aprobación vio la primera versión del servidor, y cada cambio posterior lo puedes leer en el pull request. El ejemplo de abajo junta tres cosas que un pull request puede cambiar en un archivo MCP:

El primer cambio es el más fácil de pasar por alto: el nombre docs no cambió, pero ahora se ejecuta otro programa, y ese programa es un script del repositorio. Ese script puede cambiar en este pull request o en los siguientes; lo que hace el servidor depende ahora de que se revise ese archivo. El segundo servidor descargará en cada arranque la versión del paquete que haya ese día, y tomará un token del entorno.

En un diff así, repasa estas preguntas por orden:

• El comando, los argumentos y la dirección. La guía de seguridad de MCP pide a los clientes que instalan un servidor con un clic que muestren el comando que se va a ejecutar, con sus argumentos y sin recortarlo. En un pull request esas líneas ya están delante de ti; si el comando ejecuta un script del repositorio, lee también ese script. En un servidor remoto, mira de quién es la dirección y si usa https. La guía explica además, por separado, que una dirección OAuth que da un servidor malicioso puede llegar a ejecutar código en el cliente.
• La versión. @latest o un nombre de paquete sin versión puede traer código distinto en cada arranque. Invariant recomienda fijar la versión del servidor y de sus herramientas; en la lista de OWASP, la cadena de suministro es un punto propio (MCP04).
• Un servidor que cambia con el mismo nombre. MCPoison salió justo de esta línea. Si la aprobación va ligada a un nombre, mientras el nombre no cambie, un comando nuevo puede quedar detrás de la aprobación antigua. Lee un cambio así como un servidor nuevo.
• Aprobaciones que llegan con el pull request. Claude Code escribe los ajustes enableAllProjectMcpServers y enabledMcpjsonServers en .claude/settings.local.json cuando das tu aprobación; son el registro de una elección personal. Verlos en el archivo compartido .claude/settings.json significa repartir a todo el mundo la aprobación de una sola persona. En Gemini CLI, "trust": true se salta todas las confirmaciones de ese servidor, y la documentación solo lo recomienda para servidores que controlas por completo; si vale cuando está escrito en el archivo del proyecto, la documentación no lo dice.
• Secretos. Mira qué variable entra en los campos env y headers, y a qué puede acceder ese token. Claude Code y Cursor permiten leer una clave de una variable de entorno en lugar de escribirla en el archivo; eso saca el secreto del archivo, pero no impide que llegue al servidor. Gemini CLI no envía al servidor las variables sensibles del entorno base, pero toma una variable escrita expresamente en el campo env como el consentimiento informado del usuario y no la oculta. Quien lee esa línea en el pull request es quien da ese consentimiento.
• Comandos auxiliares. Claude Code ejecuta headersHelper como un «arbitrary shell command»; en Codex, http_headers_helper también es un comando local. Léelos como leerías el propio servidor.
• Herramientas que leen texto de fuera. Si un servidor que lee issues, páginas web o chats se añade junto a un servidor que accede a datos privados, míralos juntos. El ejemplo de GitHub salió justo de esa pareja.
• El código del servidor. Si el código está en el pull request, busca argumentos que empiecen por - y rutas que salgan del repositorio (los registros de Git MCP de arriba). En las descripciones de las herramientas, busca las señales que enumera OWASP MCP03: frases en imperativo dirigidas al modelo, rutas de archivos sensibles como ~/.ssh o .env, frases que dicen «envía» a una dirección, caracteres de ancho cero e instrucciones escondidas en comentarios HTML.
• CI. ¿El workflow ejecuta el agente en la rama del pull request, con los ajustes del proyecto cargados? Mira si están --setting-sources user o --strict-mcp-config en Claude Code, y la opción --approve-mcps en Cursor CLI.

Escribir estas preguntas en un archivo de reglas no basta por sí solo: un cambio solo se lee en la revisión. La misma revisión vale para los hooks de .claude/settings.json, que vimos aparte en el artículo sobre hooks. Como recuerda la documentación de seguridad de Claude Code, leer .mcp.json no muestra todos los servidores que puede cargar una sesión: también hay servidores que vienen de los ajustes de usuario y de los plugins.

Un bot de revisión de código tampoco queda fuera de este problema: también es un modelo que lee un texto escrito por el autor del pull request. En diffox, en el paso que decide si un hallazgo se descarta con el argumento de que «el autor lo hizo a propósito», la descripción del pull request se coloca entre etiquetas y se le dice al modelo que son datos, no una instrucción; una etiqueta escrita dentro de la propia descripción se neutraliza. El Security Agent, que se ejecuta en cada revisión, busca inyecciones, autenticación y autorización rotas, secretos filtrados, SSRF y deserialización o manejo de rutas inseguros (contamos cómo funciona diffox en otro artículo).

Preguntas frecuentes

¿Qué es el tool poisoning en MCP?

El tool poisoning consiste en esconder en la descripción de una herramienta MCP instrucciones que el modelo lee y el usuario no ve. En el ejemplo de Invariant Labs, la descripción de una herramienta que suma dos números le pide al modelo que lea la clave SSH del usuario, la envíe al servidor en un argumento y no se lo diga al usuario. Es el tercer punto (MCP03) del OWASP MCP Top 10. Se puede detectar leyendo la descripción: las frases en imperativo dirigidas al modelo, las rutas de archivos sensibles y los caracteres invisibles son las señales más conocidas.

¿Qué es el OWASP MCP Top 10 y cuál es su última versión?

Es la lista en la que OWASP reúne 10 riesgos propios de MCP. A fecha de 18 de octubre de 2026, la lista de owasp.org está en beta y sus puntos se numeran con la forma «MCP01:2025»; va de Token Mismanagement & Secret Exposure a Context Injection & Over-Sharing. El repositorio de GitHub del proyecto da octubre de 2026 como fecha de la próxima versión, y uno de los puntos tiene allí un nombre distinto al del sitio web. Cuando cites un punto, indica también su fecha.

¿Hay que hacer commit de .mcp.json en el repositorio?

La documentación de Claude Code lo recomienda, para que todo el equipo use las mismas herramientas. Cuando haces commit del archivo, pasa a ser parte del código y hay que revisarlo como código: el comando, la versión, las variables de entorno y los ajustes de aprobación. Las aprobaciones personales (como enabledMcpjsonServers), en cambio, van en .claude/settings.local.json, que es donde las escribe el propio Claude Code.

¿Claude Code ejecuta los servidores MCP del repositorio sin preguntar?

En una sesión interactiva, no: pide aprobación para cada servidor de .mcp.json por separado y, en una carpeta que no es de confianza, ignora los ajustes de aprobación que vienen en un commit del repositorio. En las ejecuciones claude -p, las sesiones del Agent SDK y las sesiones en la nube, en cambio, no puede mostrar la petición de aprobación, así que carga los servidores del proyecto sin preguntar. Para evitarlo puedes usar --setting-sources user, --bare, --strict-mcp-config o disabledMcpjsonServers.

¿Cómo se desactivan los servidores MCP del repositorio al ejecutar un agente de programación en CI?

En Claude Code, --setting-sources user no lee ni los ajustes del proyecto ni .mcp.json; --strict-mcp-config solo usa los servidores que le pasas. En los pull requests, claude-code-action restaura .mcp.json desde la rama base. El modo -p de Copilot CLI omite los servidores del proyecto en una carpeta que no es de confianza. En Cursor CLI, --approve-mcps aprueba todos los servidores; no uses esta opción en un job que se ejecute en la rama del pull request. La documentación de Codex y la de Gemini CLI no describen este caso.

¿Detecta una herramienta de revisión de código con IA un cambio de MCP?

Depende de la herramienta. diffox lee el diff del pull request, y el Security Agent se ejecuta en cada revisión: busca inyecciones, autenticación y autorización rotas, secretos filtrados, SSRF y deserialización o manejo de rutas inseguros. diffox no tiene una regla aparte para MCP; las preguntas de este artículo las hace la persona que hace la revisión. Cuando elijas una herramienta de revisión de código, pregunta también cómo lee la descripción del pull request: en diffox, el paso que comprueba si un hallazgo fue intencionado lee la descripción como datos, no como una instrucción.