Un repaso en lenguaje sencillo de los diez riesgos del OWASP MCP Top 10, desde tokens filtrados y envenenamiento de herramientas hasta servidores en la sombra y sobreexposición del contexto. Cada entrada incluye un ataque documentado, una solución clara y un plan de una semana para aplicarlas en orden.
Un solo servidor MCP puede dar a un agente de IA acceso a tus repositorios, tu bandeja de entrada y tu base de datos en una sola tarde, y aprobarlo suele costar un clic. Esa comodidad es justo lo que el OWASP MCP Top 10 pretende frenar. Recoge los diez riesgos con más probabilidad de hundir un despliegue del Model Context Protocol, desde tokens filtrados hasta servidores que nadie del equipo de seguridad conoce. Este artículo repasa cada entrada en orden, muestra cómo es el ataque con un ejemplo real o documentado y cierra cada sección con la solución que conviene aplicar primero.
La lista procede del proyecto OWASP MCP Top 10, versión 2025, dirigido por Vandana Verma Sehgal. La página del proyecto la sitúa actualmente en una fase de pruebas beta y piloto, así que la redacción y el orden todavía pueden cambiar. Considera las diez entradas un vocabulario común, no un estándar cerrado.
MCP es el protocolo que permite a un modelo llamar a herramientas. Un cliente MCP (la aplicación que aloja el modelo) se conecta a uno o más servidores MCP, y cada servidor expone herramientas, recursos y prompts que el modelo puede usar. Cada una de esas conexiones es una decisión de confianza: el servidor confía en que el cliente se comporte bien, el cliente confía en las descripciones y salidas del servidor, y el modelo confía en cualquier texto que llegue a su ventana de contexto.
El Top 10 señala los puntos donde esa confianza se rompe. Estos son los diez de un vistazo:
| ID | Riesgo | Significado sencillo | Primera solución, la más barata |
|---|---|---|---|
| MCP01 | Mala gestión de tokens y exposición de secretos | Las credenciales se filtran por el código, los logs o el contexto | Tokens de vida corta y escaneo de secretos |
| MCP02 | Escalada de privilegios por ampliación de alcance | Los permisos crecen más allá de lo que necesita la tarea | Mínimo privilegio con caducidad |
| MCP03 | Envenenamiento de herramientas | La descripción o la salida de una herramienta lleva instrucciones ocultas | Fijar y calcular el hash de las definiciones de herramientas |
| MCP04 | Ataques a la cadena de suministro de software y manipulación de dependencias | Un paquete malicioso o secuestrado se convierte en tu servidor | Inventariar y fijar cada dependencia |
| MCP05 | Inyección de comandos y ejecución | Texto no confiable llega a una shell | Sin shell, listas de argumentos y validación |
| MCP06 | Subversión del flujo de intención | El contenido recuperado redirige el objetivo del agente | Tratar el texto recuperado como datos y aprobar las escrituras |
| MCP07 | Autenticación y autorización insuficientes | Los servidores no comprueban quién hace la llamada | OAuth 2.1 y comprobaciones por herramienta |
| MCP08 | Falta de auditoría y telemetría | Nadie puede ver lo que hizo el agente | Registrar cada llamada a herramientas |
| MCP09 | Servidores MCP en la sombra | Servidores no aprobados funcionan fuera del control | Inventario y lista de permitidos |
| MCP10 | Inyección de contexto y sobreexposición | El contexto se filtra entre usuarios o tareas | Aislar el contexto por usuario |
💡 Nota sobre el nombre: la página general del proyecto llama a la sexta entrada "Prompt Injection via Contextual Payloads", mientras que su página de detalle para MCP06 se titula "Intent Flow Subversion". Ambas apuntan al mismo lugar, y este artículo usa el título de la página de detalle.
Es el problema de seguridad más antiguo, solo que con ropaje nuevo. Los secretos de API escritos en el código, los tokens de larga duración y las credenciales pegadas en prompts o archivos de configuración acaban en logs, en el historial del chat y en la memoria del modelo. Una vez que un secreto está dentro de la ventana de contexto, basta con que una inyección de prompt pida al modelo que lo repita.
El escenario de OWASP: un desarrollador sube un secreto durante las pruebas, el servidor MCP lo lee al arrancar y, más tarde, el asistente lo muestra en una respuesta dirigida a otra persona.
Qué hacer:
💡 Consejo: los secretos con un prefijo fijo son fáciles de localizar. Las claves de la API de PicassoIA empiezan por
pia_sk_, así que una regla de escaneo de una sola línea puede marcarlas en cualquier repositorio. Añade una regla similar para cada proveedor que uses.
Los permisos empiezan ajustados y se aflojan con el tiempo. Un token creado para un repositorio se amplía "solo para este sprint", un agente obtiene permisos de escritura porque el acceso de lectura resultaba molesto y nadie revoca nada. El modelo acaba con mucho más poder del que necesita cualquier tarea, así que una sola instrucción errónea causa mucho más daño.
El escenario de OWASP: una inyección de prompt oculta en una incidencia pública de GitHub redirige a un agente con amplio acceso al repositorio, y el agente copia código privado en una pull request pública.
Qué hacer:
Los modelos eligen herramientas leyendo sus nombres y descripciones, lo que convierte esas descripciones en una superficie de ataque. Una herramienta envenenada oculta instrucciones en sus metadatos, en su esquema o en su salida. En abril de 2025, Invariant Labs demostró el ataque con una herramienta inocente de suma cuya descripción oculta ordenaba al agente leer un archivo de configuración MCP local y un archivo SSH privado, y luego enviar el contenido en un parámetro sobrante mientras la respuesta hablaba de aritmética.
Una variante más peligrosa es el rug pull (un cambio repentino tras la aprobación): una herramienta se comporta bien cuando la apruebas, y después cambia su descripción tras la instalación.
Qué hacer:
Un servidor MCP es código que escribió otra persona y que se descarga de un registro. Un paquete comprometido o suplantado obtiene el mismo acceso que concedes al auténtico. En septiembre de 2025, un paquete de npm llamado postmark-mcp copió una integración genuina de Postmark y añadió una sola línea que enviaba una copia oculta de cada correo saliente a una dirección controlada por el atacante. Los investigadores de Koi Security lo señalaron como el primer servidor MCP malicioso detectado en uso real, y el artículo de Snyk detalla el caso. Llegó a rondar unas 1.500 descargas semanales antes de que lo retiraran.
Qué hacer:
Los agentes construyen comandos a partir de texto. Cuando ese texto lo controla un atacante (un comentario de una incidencia, un nombre de archivo, una página web), la shell hace el resto. Según el desglose de la lista que publica Cycode, la CVE-2025-6514 en mcp-remote tenía una puntuación CVSS de 9,6, afectaba a un paquete con más de 437.000 descargas y permitía la inyección de comandos del sistema operativo. Se sitúa en la frontera entre esta entrada y MCP04.
La diferencia entre lo arriesgado y lo seguro suele estar en una sola línea:
import re
import subprocess
# Risky: untrusted text is spliced into a shell string
subprocess.run(f"git log --author={author}", shell=True)
# Safer: fixed command, argument list, validated input, no shell
if not re.fullmatch(r"[A-Za-z0-9._@][A-Za-z0-9 ._@-]{0,63}", author):
raise ValueError("invalid author")
subprocess.run(["git", "log", "--author", author], shell=False, check=True)
Qué hacer:
El agente lee una página web, una incidencia o un PDF, y ese contenido contiene instrucciones. Un modelo no puede distinguir de forma fiable los datos de las órdenes, así que puede seguirlas. El resultado es el secuestro de objetivos: el agente sigue pareciendo que hace tu tarea mientras sirve a otro.
El caso real más claro llegó de Invariant Labs en mayo de 2025, contra el servidor MCP oficial de GitHub. Un atacante abre una incidencia maliciosa en un repositorio público. Cuando el propietario pide a su agente que revise las incidencias abiertas, el agente lee la incidencia, recibe la inyección, extrae datos de repositorios privados hacia su contexto y los publica en una pull request del repositorio público. Los investigadores lo llamaron flujo de agente tóxico, dijeron que era un problema de arquitectura y no un fallo en el código del servidor, y sospecharon que muchas personas eligen una política de aprobación "permitir siempre", que elimina la comprobación humana.
Qué hacer:
💡 Consejo: un clasificador es una capa, no toda la defensa. Llama Guard 4 12B en PicassoIA es un modelo de moderación de contenido que puede revisar el texto antes de que llegue a tu agente, pero es un clasificador de seguridad y no un detector de inyecciones específico, así que mantén las aprobaciones y el mínimo privilegio.
Algunos servidores MCP nunca preguntan quién hace la llamada. Un endpoint expuesto sin autenticación permite que cualquiera invoque sus herramientas, y un servidor que comprueba la identidad una sola vez, pero nunca los permisos en cada llamada, deja que un usuario con pocos privilegios dispare acciones de alto privilegio.
Un caso concreto es la CVE-2025-49596 en MCP Inspector de Anthropic, con una puntuación CVSS de 9,4. Las versiones anteriores a la 0.14.1 no tenían autenticación entre el cliente Inspector y su proxy, así que las peticiones sin autenticar podían lanzar comandos por stdio. Encadenado con un fallo del navegador y con falsificación de peticiones entre sitios, bastaba visitar una web maliciosa para ejecutar código en el equipo de un desarrollador.
Qué hacer:
Sin registros, cada otro riesgo de esta lista se vuelve invisible. El robo de tokens, la inyección de comandos y la inyección de prompts pueden ocurrir sin que quede nada registrado, y la respuesta a incidentes se convierte en conjeturas. Esta entrada amplifica a las otras nueve.
Un registro útil de llamadas a herramientas es sencillo. Por cada llamada, registra:
| Campo | Por qué importa |
|---|---|
| Quién o qué hizo la llamada | Vincula la acción a un usuario, agente o servicio |
| Qué servidor y qué herramienta | Muestra qué capacidad se usó |
| Argumentos (con hash o censurados) | Permite reconstruir la intención sin guardar secretos |
| Tamaño y estado del resultado | Expone lecturas masivas y fallos silenciosos |
| Marca de tiempo e ID de sesión | Reconstruye el orden de los eventos |
Qué hacer:
Un desarrollador levanta un servidor experimental un viernes, sigue funcionando con credenciales por defecto y ajustes abiertos, y el lunes ya tiene datos reales. Nadie lo aprobó, nadie lo supervisa y nunca aparece en un inventario. Eso es un servidor MCP en la sombra.
Dónde buscar primero:
Qué hacer:
Las ventanas de contexto compartidas o persistentes se filtran. Cuando un agente atiende a varios usuarios o inquilinos y el contexto no está aislado, los datos de una persona pueden aparecer en la sesión de otra. El escenario de OWASP es un único agente que atiende a muchos usuarios y filtra datos personales de un usuario a una sesión distinta.
Ya ha ocurrido en un producto real. BleepingComputer informó de que Asana advirtió a sus usuarios en junio de 2025 de que un fallo lógico en su nueva función MCP exponía datos de algunas organizaciones a otras. Unos 1.000 clientes resultaron afectados, y Asana desactivó la función del 5 al 17 de junio mientras corregía el error. Fue un error lógico, no un hackeo, y el fallo llevaba activo cerca de un mes antes de que Asana lo detectara.
Qué hacer:
No puedes cerrar los diez en una semana, así que empieza por donde el daño es mayor y el trabajo es menor.
| Día | Tarea | Riesgos cubiertos |
|---|---|---|
| Lunes | Inventariar cada servidor y configuración de cliente MCP | MCP09 |
| Martes | Escanear repositorios en busca de secretos, rotar los antiguos y acortar la vida de los tokens | MCP01 |
| Miércoles | Añadir autenticación y comprobaciones de permisos por herramienta | MCP07, MCP02 |
| Jueves | Fijar versiones, calcular hashes de las descripciones de herramientas y configurar alertas de cambios | MCP03, MCP04 |
| Viernes | Activar el registro de llamadas a herramientas y exigir aprobación para las escrituras | MCP08, MCP06 |
💡 Errores comunes: aprobar "permitir siempre" para ahorrar clics, confiar en un servidor porque tiene muchas descargas y registrar todo menos los argumentos de las herramientas que importan.
Una lista de comprobación de seguridad cala más hondo cuando la gente puede visualizarla. Cada imagen de este artículo usa un sustituto físico y sencillo para un fallo abstracto: un aro lleno de pases para la ampliación de alcance, una puerta abierta para la autenticación débil, un libro de registro en blanco para la falta de auditoría. Puedes crear el mismo tipo de recursos visuales para tus modelos de amenazas, presentaciones de formación y wikis internas.
Pruébalo en PicassoIA. Abre un modelo de texto a imagen como Seedream 5 Pro, Qwen Image 3 o GPT Image 2, describe un objeto real que represente tu riesgo y añade la iluminación y la lente que quieras. Genera algunas variaciones, elige la más nítida e incorpórala a tu próxima revisión. Si también escribes la documentación, los modelos de lenguaje (LLM) de PicassoIA pueden ayudarte a redactar la primera versión antes de editarla a mano.
Elige tu idioma
