Una guía práctica para comprender el OWASP MCP Top 10 y proteger las herramientas, los datos y los sistemas corporativos conectados a agentes de IA.
De asistente conversacional a actor dentro del sistema
La inteligencia artificial está evolucionando desde asistentes que responden preguntas hacia agentes capaces de consultar documentación, interactuar con aplicaciones y ejecutar operaciones. Model Context Protocol (MCP) facilita estas integraciones mediante una interfaz común entre la aplicación de IA y las fuentes de datos o herramientas que necesita utilizar.Un servidor MCP puede exponer recursos y herramientas capaces de consultar una plataforma de soporte, acceder a un repositorio o invocar una API. El modelo recibe la descripción de esas capacidades y decide cuál utilizar. Esta arquitectura acelera el desarrollo, pero introduce un cambio fundamental: una respuesta incorrecta puede dejar de ser solo texto y convertirse en una acción sobre un sistema real.
La decisión del modelo no equivale a una autorización
El modelo puede seleccionar una herramienta porque interpreta que es útil para completar la tarea. Sin embargo, esa decisión es probabilística y puede verse condicionada por el mensaje del usuario, el historial de conversación o el contenido de un documento externo. Por ello, la autorización no debe residir en el prompt ni depender de que el modelo “comprenda” una política.Cada operación debe verificarse en el servidor MCP y en el sistema de destino utilizando la identidad y los permisos efectivos del usuario. Si una persona no puede consultar o modificar un recurso directamente, tampoco debería conseguirlo a través del agente.
OWASP MCP Top 10: lectura ejecutiva de los principales riesgos
OWASP mantiene un Top 10 específico para MCP que agrupa riesgos de credenciales, privilegios, herramientas, dependencias, contexto y gobierno. A agosto de 2026, el proyecto se encuentra en fase beta y publica la versión v0.1; OWASP prevé una siguiente revisión en octubre de 2026. Debe utilizarse como guía viva de análisis y no como una certificación de seguridad cerrada.
MCP01 — Gestión deficiente de tokens y exposición de secretos
Descripción general. Los servidores MCP necesitan credenciales para conectarse a repositorios, bases de datos, servicios cloud y otras aplicaciones corporativas. El problema aparece cuando estas credenciales se incluyen en archivos de configuración, variables accesibles al proceso, conversaciones, memorias persistentes o registros de depuración. MCP amplía especialmente este riesgo porque un secreto puede atravesar varias capas y terminar almacenado en lugares que inicialmente no se consideraban repositorios de credenciales.Riesgo empresarial. Credenciales embebidas, tokens de larga duración o secretos presentes en memoria, logs y trazas pueden terminar expuestos mediante una inyección, un error de diagnóstico o un servidor comprometido.
Caso documentado. Check Point Research documentó las vulnerabilidades CVE-2025-59536 y CVE-2026-21852 en Claude Code. Un repositorio malicioso podía incluir configuraciones y hooks capaces de provocar ejecución de código y exfiltrar credenciales y tokens cuando un desarrollador trabajaba con el proyecto. El caso demuestra que los archivos de configuración asociados a herramientas MCP forman parte de la superficie de confianza: si contienen comandos o referencias manipuladas, los secretos disponibles en el entorno pueden quedar expuestos.
https://research.checkpoint.com/2026/rce-and-api-token-exfiltration-through-claude-code-project-files-cve-2025-59536/
Control prioritario. Centralizar secretos, utilizar tokens breves y limitados, impedir que lleguen al contexto del modelo y revisar logs y repositorios.
MCP02 — Escalada de privilegios por ampliación del alcance
Descripción general. La ampliación del alcance se produce cuando un agente comienza utilizando permisos reducidos, pero va acumulando nuevas capacidades por comodidad, pruebas temporales o cambios de configuración. Un asistente que inicialmente solo necesitaba consultar incidencias podría terminar disponiendo de acceso para modificar tickets, descargar archivos o administrar el sistema. El riesgo no reside necesariamente en una única concesión crítica, sino en la suma progresiva de privilegios.Riesgo empresarial. Los permisos inicialmente concedidos para una prueba pueden acumularse hasta permitir modificar repositorios, administrar sistemas o extraer datos. El riesgo aparece cuando los alcances son amplios, persistentes o no se revisan.
Caso documentado. En mayo de 2025, Invariant Labs demostró un ataque contra el servidor MCP oficial de GitHub. El agente utilizaba un Personal Access Token con acceso a repositorios públicos y privados. Una instrucción maliciosa colocada en una incidencia pública podía influir en el agente, hacer que consultara repositorios privados y publicara la información obtenida en un pull request visible. La inyección fue el detonante, pero el impacto dependía de la amplitud del token y de reunir lectura de contenido no confiable, acceso privado y capacidad de publicación en una misma identidad.
Referencia: https://invariantlabs.ai/blog/mcp-github-vulnerability
Control prioritario. Aplicar mínimo privilegio, caducidad automática, separación entre lectura y escritura y revisiones periódicas de permisos.
MCP03 — Envenenamiento de herramientas
Descripción general. Los agentes utilizan el nombre, la descripción y el esquema de una herramienta para decidir cuándo y cómo invocarla. Estos metadatos no son únicamente documentación: pasan a formar parte del contexto que dirige al modelo. En un ataque de Envenamiento “Tool Poisoning”, una herramienta aparentemente legítima incluye instrucciones ocultas o engañosas, suplanta a otra herramienta o devuelve resultados diseñados para influir en las siguientes decisiones.Riesgo empresarial. Una herramienta, su descripción, su esquema o su resultado pueden manipular la selección y el comportamiento del modelo. OWASP incluye técnicas como actualizaciones maliciosas, schema poisoning y herramientas falsas o duplicadas.
Caso documentado. Invariant Labs creó una herramienta MCP aparentemente inofensiva que proporcionaba un “dato curioso del día”. Su descripción contenía instrucciones ocultas destinadas al modelo. Al convivir con un servidor legítimo de WhatsApp, la herramienta maliciosa podía alterar la forma en que el agente utilizaba las funciones de mensajería y provocar el envío del historial de conversaciones a un número controlado por el atacante. La demostración se realizó sobre servidores y clientes MCP reales; el comportamiento se originaba en metadatos que las interfaces convencionales normalmente no muestran.
Referencia: https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks
Control prioritario. Inventariar y aprobar herramientas, fijar versiones, verificar integridad y revisar cambios en descripciones, esquemas y respuestas.
MCP04 — Ataques a la cadena de suministro
Descripción general. Un servidor MCP depende de SDK, paquetes, imágenes de contenedor, conectores, plugins y herramientas procedentes de diferentes proveedores. Una dependencia comprometida se ejecuta dentro de una ruta de confianza y puede acceder al contexto, modificar herramientas, capturar credenciales o introducir una puerta trasera. En entornos agénticos, una misma actualización puede alterar automáticamente el comportamiento de numerosos agentes.Riesgo empresarial. Servidores MCP, conectores y plugins dependen de paquetes y componentes externos. Una dependencia vulnerable o comprometida puede alterar el comportamiento del agente o introducir una puerta trasera.
Caso documentado. En 2026, OX Security publicó una investigación sobre una debilidad sistémica relacionada con la configuración del transporte STDIO de MCP. El patrón inseguro se había propagado a distintos productos y adaptadores, incluidos LangFlow, Flowise y Letta AI. En determinadas implementaciones, configuraciones MCP controlables podían alcanzar la creación de subprocesos y terminar ejecutando comandos. La relevancia para MCP04 reside en la propagación: un patrón presente en componentes reutilizados acabó afectando a varios proyectos y amplificando el alcance del problema.
Referencia: https://www.ox.security/blog/mcp-supply-chain-advisory-rce-vulnerabilities-across-the-ai-ecosystem/
Control prioritario. Mantener una SBOM, fijar dependencias, verificar procedencia y firmas, monitorizar vulnerabilidades y controlar actualizaciones.
MCP05 — Inyección y ejecución de comandos
Descripción general. Algunos servidores MCP permiten administrar infraestructura, ejecutar herramientas de desarrollo o interactuar con el sistema operativo. Para hacerlo, transforman los parámetros recibidos del agente en comandos, consultas o llamadas a APIs. Si esos valores se concatenan directamente dentro de una shell, un atacante puede introducir metacaracteres y añadir operaciones no previstas porque aunque el parámetro proceda de un modelo no lo hace seguro.Riesgo empresarial. Entradas procedentes de usuarios, documentos o servicios externos pueden alcanzar una shell, una consulta, una API o un intérprete sin validación. La capacidad del modelo para construir parámetros no convierte esos parámetros en confiables.
Caso documentado. El servidor mcp-server-kubernetes, hasta la versión 2.4.9, presentaba una vulnerabilidad de inyección de comandos en herramientas como kubectl_scale, kubectl_patch y explain_resource. Incorporaba parámetros no validados a llamadas mediante child_process.execSync, permitiendo introducir metacaracteres y ejecutar comandos con los privilegios del proceso. El advisory también documentó cómo una prompt injection indirecta, introducida por ejemplo en los logs de un pod, podía conducir desde el contenido externo hasta la ejecución arbitraria. Se corrigió en la versión 2.5.0.
Referencia: https://github.com/Flux159/mcp-server-kubernetes/security/advisories/GHSA-gjv4-ghm7-q58q
Control prioritario. Evitar shells cuando exista una API segura, usar listas permitidas y parámetros estructurados, aislar la ejecución y limitar identidad y red.
MCP06 — Subversión del flujo de intención / prompt injection contextual
Descripción general. El flujo de intención representa el objetivo que el usuario espera que cumpla el agente. Puede alterarse cuando el modelo encuentra instrucciones adicionales dentro de un ticket, documento, correo, página web o resultado de una herramienta. El modelo no siempre diferencia entre información que debe analizar e instrucciones que debe seguir ya que un contenido que para una aplicación convencional sería un dato puede convertirse en un canal secundario de control.Riesgo empresarial. El contenido recuperado por el agente puede actuar como un segundo canal de instrucciones y desviar la tarea hacia el objetivo de un atacante. Un ticket, una página web o un PDF pueden contener el payload.
Caso documentado. La investigación sobre Supabase MCP mostró un escenario reproducible en el que Cursor utilizaba el servidor MCP con una credencial service_role capaz de omitir los controles de Row-Level Security. Cuando el agente procesaba un ticket de soporte con instrucciones maliciosas, podía interpretarlo como una orden, consultar tablas privadas y devolver la información a través del propio ticket. El objetivo original quedaba sustituido por el objetivo del atacante.
Referencia: https://generalanalysis.com/blog/supabase-mcp-blog
Control prioritario. Tratar todo contenido recuperado como datos no confiables, separar instrucciones y contexto, reducir las herramientas disponibles y confirmar acciones sensibles.
MCP07 — Autenticación y autorización insuficientes
Descripción general. En una arquitectura MCP intervienen varias identidades: usuario, cliente, modelo, agente, servidor y sistema de destino. El riesgo aparece cuando la identidad original se pierde por el camino o se sustituye por una cuenta técnica compartida. Autenticar la conexión tampoco es suficiente: cada herramienta debe comprobar si el usuario puede ejecutar esa operación y acceder específicamente al objeto, proyecto o cliente solicitado.Riesgo empresarial. En ecosistemas con usuarios, modelos, agentes y servicios es fácil perder la identidad original o utilizar una cuenta técnica compartida. Sin controles por operación, el agente puede superar los permisos del usuario.
Caso documentado. JFrog descubrió CVE-2025-6515 en oatpp-mcp. La implementación generaba identificadores de sesión a partir de direcciones de memoria, por lo que podían predecirse o reutilizarse. Un atacante podía crear y cerrar sesiones, esperar a que uno de esos identificadores fuera asignado a una víctima y enviar solicitudes usando el ID conocido. El servidor trataba esas peticiones como pertenecientes a la sesión legítima y podía introducir prompts o eventos en la comunicación de otro cliente.
Referencia: https://jfrog.com/blog/mcp-prompt-hijacking-vulnerability/
Control prioritario. Propagar la identidad de extremo a extremo, aplicar RBAC o ABAC en cada herramienta y validar propiedad, tenant y finalidad de acceso.
MCP08 — Falta de auditoría y telemetría
Descripción general. Una operación MCP puede recorrer usuario, modelo, servidor, herramienta y aplicación de destino. Si cada componente genera registros independientes, puede resultar imposible reconstruir quién inició la acción, qué contexto influyó en el modelo y por qué se permitió la operación. También existe el problema contrario: registrar conversaciones completas puede introducir secretos y datos personales en la plataforma de monitorización.Riesgo empresarial. Sin registros de invocaciones, cambios de contexto y resultados, una acción indebida puede pasar inadvertida y ser difícil de investigar. Registrar todo sin criterio también puede exponer prompts o secretos.
Caso documentado. En 2026, Bishop Fox analizó las capacidades de registro disponibles en servidores MCP al incorporar soporte para el protocolo en su herramienta Otto. La investigación señaló que los servidores remotos pueden comportarse como una caja negra: el cliente observa la petición y la respuesta, pero no necesariamente la ejecución interna, los recursos consultados o las acciones intermedias. También recogió una diferencia significativa entre percepción y visibilidad: muchos responsables confiaban en sus políticas, pero una minoría afirmaba disponer de visibilidad completa sobre permisos, herramientas y accesos a datos. No es una CVE, sino una carencia operativa observada en despliegues reales.
Referencia: https://bishopfox.com/blog/otto-support-logging-visibility-in-mcp-servers
Control prioritario. Crear trazas correlacionadas y protegidas, registrar decisiones y autorizaciones relevantes, minimizar datos sensibles y generar alertas.
MCP09 — Servidores MCP en la sombra
Descripción general. Los servidores MCP en la sombra son despliegues instalados fuera de los procedimientos corporativos de inventario, revisión y monitorización. Pueden aparecer cuando un desarrollador instala un conector para una prueba o un equipo publica una integración sin involucrar a seguridad. Esos servidores pueden conservar credenciales, escuchar en interfaces no previstas o exponer herramientas con acceso al sistema operativo.Riesgo empresarial. Equipos de desarrollo pueden desplegar servidores fuera del gobierno corporativo para experimentar con rapidez. Esos nodos pueden usar credenciales por defecto, APIs abiertas o acceso excesivo a datos.
Caso documentado. Backslash Security analizó implementaciones MCP públicas y encontró cientos de servidores configurados para escuchar en 0.0.0.0, haciendo que servicios concebidos para uso local pudieran ser accesibles desde otros equipos de la misma red. Los investigadores denominaron a esta exposición NeighborJack.
También localizaron decenas de servidores con capacidad de ejecutar comandos sin validación suficiente y varios casos en los que coincidían exposición de red y ejecución arbitraria.
Referencia: https://www.backslash.security/blog/hundreds-of-mcp-servers-vulnerable-to-abuse
Control prioritario. Descubrir e inventariar despliegues, ofrecer una plataforma aprobada, controlar comunicaciones salientes y credenciales y definir un proceso ágil de alta.
MCP10 — Inyección y compartición excesiva de contexto
Descripción general. El contexto puede incluir mensajes, documentos recuperados, resultados de herramientas, memoria histórica y datos intermedios de otros agentes. Compartirlo mejora la continuidad, pero aumenta la posibilidad de que información de una tarea aparezca en otra. La separación debe aplicarse por usuario, organización, sesión y finalidad, no basta con pedir al modelo que ignore información que nunca debió recibir.Riesgo empresarial. Memorias persistentes o contextos mal aislados pueden mezclar información entre usuarios, agentes, tareas o clientes. El contexto mejora la experiencia, pero también puede convertirse en un canal de fuga.
Caso documentado. En junio de 2025, Asana deshabilitó temporalmente su funcionalidad MCP después de descubrir un fallo que podía provocar exposición de información entre organizaciones. Según las comunicaciones sobre el incidente, proyectos, equipos, tareas y otros objetos pertenecientes a una organización podían quedar accesibles para otra. El problema afectaba al aislamiento entre tenants: si la recuperación de recursos no queda vinculada al tenant correcto, el modelo puede recibir información que el usuario nunca estuvo autorizado a consultar.
Referencia: https://authzed.com/blog/timeline-mcp-breaches
Control prioritario. Aislar sesiones y tenants, minimizar y caducar la memoria, clasificar los datos, impedir su reutilización no autorizada y probar fugas entre contextos.
Cómo afectaría en un proyecto corporativo
Pensemos en un asistente conectado a una plataforma de soporte o Help Desk. Su función es consultar incidencias, resumir conversaciones y proponer respuestas. La integración parece de bajo riesgo hasta que también puede descargar adjuntos, modificar tickets o acceder a casos de varios clientes.Un documento manipulado podría contener instrucciones dirigidas al modelo. Si el servidor utiliza una cuenta con acceso general y no comprueba los permisos en cada solicitud, el aislamiento entre clientes terminaría dependiendo del comportamiento del agente. En ese escenario convergen MCP06, MCP07 y MCP10 y si además no existe trazabilidad, MCP08 dificultaría detectar y reconstruir el incidente.
Como principio de diseño, una instrucción de sistema puede orientar al agente, pero no sustituye una frontera de seguridad. Los controles deterministas deben limitar lo que ocurre cuando el modelo se equivoca o es manipulado.
Un marco mínimo para adoptar MCP con seguridad
▪️Comenzar con operaciones de lectura y datos de sensibilidad limitada antes de habilitar modificaciones.
▪️Mantener un inventario de servidores, herramientas, responsables, datos accesibles, credenciales y dependencias.
▪️Separar lectura, escritura y administración mediante credenciales y alcances diferentes.
▪️Exigir confirmación humana o una autorización adicional para operaciones irreversibles, financieras o
de alto impacto.
▪️Probar prompt injection indirecta, aislamiento entre usuarios y tenants, autorización por objeto y
manipulación de herramientas.
▪️Integrar MCP en revisión de código, gestión de vulnerabilidades, monitorización y respuesta ante incidentes.
Conclusión
La adopción del protocolo Model Context Protocol (MCP) está acelerando la integración de los sistemas de inteligencia artificial con aplicaciones, bases de datos, repositorios y servicios corporativos. Sin embargo, esta capacidad también convierte a los agentes de IA en nuevos actores dentro de la infraestructura: pueden consultar información sensible, utilizar credenciales y ejecutar acciones con consecuencias reales.
Por este motivo, proteger un ecosistema basado en MCP requiere algo más que revisar prompts o aplicar controles aislados. Es necesario analizar la arquitectura completa, los flujos de datos, las identidades, los permisos, las herramientas disponibles, la gestión de secretos, las dependencias, la trazabilidad y la forma en que los agentes interactúan con los sistemas corporativos.
Internet Security Auditors ofrece un servicio de Auditoría Integral de Seguridad para Ecosistemas de IA, adaptable a la arquitectura y al nivel de madurez de cada organización. Su alcance puede incluir:
▪️Auditoría técnica de plataformas de IA, infraestructuras, entornos MLOps y configuraciones.
▪️Evaluación de aplicaciones, chatbots, sistemas RAG y APIs integradas con IA.
▪️Pruebas de seguridad y ejercicios de red teaming sobre LLM, agentes y capas de orquestación.
▪️Auditoría específica de servidores MCP, conectores, plugins y herramientas.
▪️Revisión de autenticación, autorización, gestión de secretos y tratamiento de datos sensibles.
▪️Pruebas de prompt injection, fuga de contexto, abuso de herramientas y escalada de privilegios.
▪️Fuzzing, análisis de dependencias, revisión de código y modelado de amenazas.
▪️Evaluación del registro de eventos, la telemetría, la trazabilidad y la capacidad de respuesta ante incidentes.
El servicio combina pruebas ofensivas y revisión técnica para identificar vulnerabilidades, configuraciones inseguras y riesgos operativos antes de que puedan afectar a los datos, los usuarios o los sistemas conectados. Como resultado, la organización obtiene hallazgos priorizados, evidencias técnicas, recomendaciones concretas y un plan de acción adaptado a su entorno.
Si su organización está desarrollando agentes, incorporando servidores MCP o conectando modelos de IA con sistemas internos, este es el momento de comprobar si esas capacidades operan dentro de unos límites de seguridad realmente verificables.
Solicite una evaluación de su ecosistema de IA o una auditoría específica de sus integraciones basadas en MCP con Internet Security Auditors.
Referencias
🔗OWASP Foundation, “OWASP MCP Top 10,” OWASP. [En línea]. Disponible en: https://owasp.org/www-project-mcp-top-10/.
🔗OWASP GenAI Security Project, “A Practical Guide for Secure MCP Server Development,” 16 feb. 2026. Disponible en: https://genai.owasp.org/resource/a-practical-guide-for-secure-mcp-server-development/.
🔗OWASP GenAI Security Project, “OWASP Top 10 for Agentic Applications for 2026,” 9 dic. 2025. Disponible en: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/.
🔗OWASP GenAI Security Project, “CheatSheet: A Practical Guide for Securely Using Third-Party MCP Servers 1.0,” 4 nov. 2025. Disponible en: https://genai.owasp.org/resource/cheatsheet-a-practical-guide-for-securely-using-third-party-mcp-servers-1-0/.
🔗PortSwigger, “Web LLM attacks,” Web Security Academy. Disponible en: https://portswigger.net/web-security/llm-attacks.
🔗Invariant Labs, “GitHub MCP Exploited: Accessing Private Repositories via MCP,” 26 may. 2025. Disponible en: https://invariantlabs.ai/blog/mcp-github-vulnerability.
🔗Invariant Labs, “MCP Security Notification: Tool Poisoning Attacks,” 1 abr. 2025. Disponible en: https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks.
🔗OX Security, “MCP STDIO Command Injection: Full Vulnerability Advisory,” OX Security. Disponible en: https://www.ox.security/blog/mcp-supply-chain-advisory-rce-vulnerabilities-across-the-ai-ecosystem/.
🔗Flux159, “mcp-server-kubernetes vulnerable to command injection in several tools,” GitHub Security Advisory, GHSA-gjv4-ghm7-q58q, 8 jul. 2025. Disponible en: https://github.com/Flux159/mcp-server-kubernetes/security/advisories/GHSA-gjv4-ghm7-q58q.
🔗General Analysis, “Supabase MCP can leak your entire SQL database.” Disponible en: https://generalanalysis.com/blog/supabase-mcp-blog.
🔗JFrog Security Research, “CVE-2025-6515: Prompt Hijacking Attack Affects MCP Ecosystem,” JFrog. Disponible en: https://jfrog.com/blog/mcp-prompt-hijacking-vulnerability/.
🔗Bishop Fox, “Otto Support: Logging and Visibility in MCP Servers.” Disponible en: https://bishopfox.com/blog/otto-support-logging-visibility-in-mcp-servers.
🔗Backslash Research Team, “Threat Research: Hundreds of MCP Servers Vulnerable to Abuse,” Backslash Security, 25 jun. 2025. Disponible en: https://www.backslash.security/blog/hundreds-of-mcp-servers-vulnerable-to-abuse.
🔗AuthZed, “A Timeline of Model Context Protocol (MCP) Security Breaches.”. Disponible en: https://authzed.com/blog/timeline-mcp-breaches.
