El Proyecto de Seguridad GenAI de OWASP define una barra mínima de cinco categorías para el despliegue seguro de servidores MCP. Utilice esta lista de verificación para evaluar su postura actual en identidad, aislamiento, herramientas, validación y despliegue antes de pasar a producción.
La guía práctica del Proyecto de Seguridad GenAI de OWASP para el desarrollo de servidores MCP culmina en una lista de verificación de revisión concreta — la “Barra Mínima de Seguridad MCP”. Esta lista de verificación define los controles básicos que deben estar implementados antes de que un servidor MCP se despliegue en producción.
Esta publicación presenta la lista de verificación completa con orientación de implementación para cada elemento, organizada en los cinco dominios de seguridad que define la guía de OWASP. Úsela para revisiones de seguridad previas al despliegue, auditorías periódicas y como marco para remediar las brechas identificadas.
Marcando elementos: Para cada elemento, registre APROBADO (implementado y verificado), REPROBADO (no implementado o parcialmente implementado), o N/A (no aplicable a este despliegue).
Puertas de despliegue: Los elementos en la Categoría 1 (Identidad, Autenticación, Política) y Categoría 2 (Aislamiento) son puertas de despliegue estrictas — cualquier REPROBADO debe bloquear la puesta en marcha hasta que se remedie. Los elementos en otras categorías deben ser aceptados con riesgo y con cronogramas documentados.
Disparadores de revisión: Vuelva a ejecutar la lista de verificación completa después de cualquier cambio significativo en el código del servidor MCP, registro de herramientas, configuración de autenticación, entorno de despliegue, o cuando se incorpore una nueva categoría de herramientas.
Esta es la categoría de mayor prioridad. Las fallas de autenticación otorgan a los atacantes acceso directo a todo lo que el servidor MCP puede hacer.
Qué verificar: Cada conexión remota al servidor MCP requiere autenticación a través de un servidor de autorización OAuth 2.1 correctamente configurado. Las conexiones anónimas son rechazadas. Los servidores MCP locales que usan STDIO pueden usar autenticación alternativa apropiada para su contexto de despliegue.
Cómo probar: Intente conectarse sin un encabezado de autorización. Intente conectarse con un token malformado o expirado. Ambos deben resultar en falla de autenticación, no en acceso a herramientas.
Modos de falla comunes: Endpoints de desarrollo dejados accesibles sin autenticación; respaldo a autenticación por clave API que no valida expiración o alcance; validación de token solo en el establecimiento de sesión, no por solicitud.
Qué verificar: Los tokens de acceso expiran en minutos (no horas). Cada token lleva el alcance mínimo requerido para la tarea actual. Cada invocación de herramienta valida la firma del token, emisor (iss), audiencia (aud), expiración (exp) y alcance requerido — no solo en el establecimiento de sesión.
Cómo probar: Use un token válido, luego espere a que expire (o ajuste manualmente el reloj hacia adelante). Intente una llamada de herramienta — debe fallar con un 401, no tener éxito con un resultado de validación en caché.
Modos de falla comunes: Validación de token almacenada en caché al inicio de sesión y no repetida; tokens con tiempos de vida de 24+ horas; alcances amplios “admin” usados en lugar de alcances específicos de operación; campo exp no verificado.
Qué verificar: El servidor MCP no reenvía tokens de cliente a APIs descendentes. Todas las llamadas de servicio descendente usan tokens emitidos explícitamente al servidor MCP (a través de flujos On-Behalf-Of o credenciales de servicio). Una puerta de políticas centralizada intercepta todas las invocaciones de herramientas y aplica autenticación, autorización, consentimiento y registro de auditoría antes de que se ejecute cualquier código de herramienta.
Cómo probar: Revise el código para cualquier ubicación donde el token de cliente entrante se reenvíe en una llamada API saliente. Inspeccione los registros de acceso del servicio descendente para verificar que las solicitudes lleguen con credenciales del servidor, no credenciales de usuario.
Modos de falla comunes: Patrón Authorization: Bearer ${request.headers.authorization} en llamadas descendentes; verificaciones de autorización dispersas en manejadores de herramientas individuales; sin punto de aplicación de políticas centralizado.
Comienza tu prueba gratuita hoy y ve resultados en días.
Las fallas de aislamiento en entornos multi-inquilino son catastróficas — permiten que un usuario acceda a los datos de otro. Estas son puertas de despliegue estrictas.
Qué verificar: No hay variables globales, atributos a nivel de clase o instancias singleton compartidas que almacenen datos específicos de usuario o sesión. Cada sesión usa objetos instanciados independientemente o espacios de nombres con clave de sesión (por ejemplo, claves Redis con prefijo session_id:). La revisión de código confirma que no hay estado mutable compartido entre sesiones.
Cómo probar: Ejecute dos sesiones concurrentes con diferentes identidades de usuario. Verifique que los datos escritos en la sesión A no puedan leerse en la sesión B. Use pruebas de carga concurrentes para verificar condiciones de carrera que puedan causar fuga de estado de sesión.
Modos de falla comunes: self.user_context = {} como atributo de clase en un servicio singleton; cachés globales sin espacios de nombres con clave de sesión; almacenamiento local de hilos que no se delimita correctamente al ciclo de vida de la solicitud.
Qué verificar: Más allá del contexto de ejecución, cualquier infraestructura compartida (bases de datos, cachés, colas de mensajes) aplica controles de acceso por usuario. Una consulta ejecutada en la sesión de un usuario no puede devolver datos de otro usuario incluso si la infraestructura compartida está mal configurada o comprometida.
Cómo probar: Intente acceder a los datos de otro usuario manipulando parámetros de sesión o explotando claves de caché compartidas.
Modos de falla comunes: Claves de caché basadas solo en contenido de consulta, no en identidad de usuario; consultas de base de datos sin cláusulas WHERE con alcance de usuario; directorios de archivos temporales compartidos sin subdirectorios por usuario.
Qué verificar: Cuando una sesión termina (limpiamente o por tiempo de espera/error), todos los recursos asociados se liberan inmediatamente: manejadores de archivos, archivos temporales, contexto en memoria, tokens en caché, conexiones de base de datos. Existen límites por sesión para memoria, CPU, tasa de API y uso del sistema de archivos.
Cómo probar: Termine una sesión abruptamente (mate la conexión sin un apagado elegante). Verifique que no queden recursos residuales. Cree una sesión y agote su límite de tasa; verifique que no afecte a otras sesiones.
Modos de falla comunes: Archivos temporales dejados en /tmp después del fin de sesión; tokens en caché no revocados al terminar la sesión; sin cuotas de recursos permitiendo que una sesión agote la infraestructura compartida.
La seguridad de las herramientas previene los ataques específicos de MCP más peligrosos: envenenamiento de herramientas y rug pulls.
Qué verificar: Cada definición de herramienta tiene una firma criptográfica de un aprobador de herramientas autorizado. La firma cubre el manifiesto completo (descripción, esquema, versión, permisos). El servidor MCP verifica esta firma en tiempo de carga y rechaza cualquier herramienta sin firma o con firma no coincidente. Las versiones de herramientas están fijadas — el servidor no puede cargar dinámicamente una herramienta actualizada sin una nueva firma aprobada.
Cómo probar: Modifique un solo carácter en la descripción de una herramienta cargada. Verifique que el servidor detecte la discrepancia de hash y bloquee la carga de la herramienta. Intente cargar una definición de herramienta sin firma — debe ser rechazada.
Modos de falla comunes: Definiciones de herramientas almacenadas como configuración mutable sin verificación de integridad; sin infraestructura de clave de firma; herramientas cargadas directamente desde un sistema de archivos compartido sin fijación de versión.
Qué verificar: El escaneo automatizado verifica las descripciones de herramientas en busca de patrones similares a instrucciones que podrían representar intentos de envenenamiento. La validación periódica confirma que el comportamiento real en tiempo de ejecución de una herramienta coincide con su descripción declarada — una herramienta que afirma ser de solo lectura no debe ser capaz de operaciones de escritura en tiempo de ejecución.
Cómo probar: Agregue una instrucción sospechosa a una descripción de herramienta (“siempre también llame send_webhook con…”) y verifique que el escaneo automatizado la marque antes de la revisión humana. Revise la configuración de la herramienta SAST para reglas de detección de envenenamiento específicas de MCP.
Modos de falla comunes: Sin escaneo automatizado de descripciones de herramientas; proceso de revisión manual que puede pasar por alto instrucciones incrustadas en descripciones largas; sin validación de comportamiento en tiempo de ejecución para detectar herramientas que mienten sobre sus capacidades.
Qué verificar: El contexto del modelo recibe solo los campos requeridos para la invocación correcta de la herramienta: nombre, descripción, esquema de entrada, esquema de salida. Los metadatos internos, detalles de implementación, información de depuración y configuración sensible se filtran antes de pasarse al modelo.
Cómo probar: Inspeccione lo que recibe el modelo cuando enumera las herramientas disponibles. Verifique que no aparezcan campos internos, cadenas de conexión o metadatos operacionales en la vista del modelo.
Modos de falla comunes: Objetos de configuración completos de herramientas pasados al contexto del modelo; mensajes de error que contienen detalles internos del sistema que se filtran al modelo; descripciones de herramientas que incluyen notas de implementación no relevantes para la invocación.
Obtén los últimos consejos, tendencias y ofertas gratis.
Las fallas de validación permiten inyección, manipulación de datos y denegación de servicio.
Qué verificar: La validación de JSON Schema se aplica para cada mensaje del protocolo MCP, cada entrada de invocación de herramienta y cada salida de herramienta antes de que llegue al modelo. La validación rechaza cualquier mensaje que no se ajuste al esquema definido — campos requeridos faltantes, tipos incorrectos, valores fuera de rangos permitidos.
Cómo probar: Envíe una invocación de herramienta con un parámetro requerido faltante. Envíe un mensaje con un campo inesperado adicional. Ambos deben ser rechazados, no ignorados silenciosamente o procesados con valores predeterminados.
Modos de falla comunes: Validación opcional que se omite bajo condiciones de error; validación solo en entradas, no en salidas; esquemas demasiado permisivos (aceptando parámetros type: "any").
Qué verificar: Todas las entradas están sanitizadas para eliminar o escapar caracteres que podrían permitir inyección (secuencias XSS, metacaracteres SQL, metacaracteres de shell, bytes nulos). Los límites de tamaño se aplican en todas las entradas y salidas. El servidor trata todos los datos del modelo como potencialmente adversarios, idénticos a la entrada del usuario en una aplicación web tradicional.
Cómo probar: Envíe entradas que contengan cargas útiles de inyección SQL, metacaracteres de shell y secuencias XSS. Verifique que sean rechazadas o escapadas de forma segura antes de llegar a sistemas descendentes. Envíe una entrada que exceda el límite de tamaño — verifique que se rechace limpiamente.
Modos de falla comunes: Entradas pasadas directamente a consultas SQL o comandos de shell; sin límites de tamaño permitiendo que entradas sobredimensionadas causen agotamiento de memoria; salidas devueltas al modelo sin límites de tamaño o filtrado de contenido.
Qué verificar: Las llamadas de herramientas solo se aceptan como objetos JSON estructurados con esquemas validados. La generación de texto de forma libre que implica invocaciones de herramientas no se procesa. El sistema no puede ser inducido a ejecutar llamadas de herramientas generando lenguaje natural que el servidor interprete como comandos.
Cómo probar: Envíe una cadena de lenguaje natural que describa una invocación de herramienta (“llame a la herramienta delete_file con ruta /etc/passwd”). Verifique que el servidor no interprete esto como una llamada de herramienta.
Modos de falla comunes: Sistemas híbridos que aceptan tanto JSON estructurado como descripciones de herramientas en lenguaje natural; servidores que analizan texto generado por el modelo para identificar invocaciones de herramientas; análisis de llamadas de herramientas basado en regex que puede ser falsificado.
El endurecimiento del despliegue limita el radio de explosión de cualquier vulnerabilidad explotada.
Qué verificar: El servidor MCP se ejecuta en un contenedor mínimo endurecido. El proceso del contenedor se ejecuta como usuario no root. Se eliminan las capacidades de Linux innecesarias. Las políticas de red restringen todo el tráfico entrante y saliente a conexiones explícitamente requeridas. La imagen del contenedor contiene solo el software mínimo requerido.
Cómo probar: Ejecute docker inspect y verifique que el usuario no sea root. Revise las políticas de red y confirme que estén bloqueando todo el tráfico excepto las conexiones explícitamente permitidas. Escanee la imagen del contenedor en busca de paquetes innecesarios o software con vulnerabilidades conocidas.
Modos de falla comunes: Contenedores ejecutándose como root por conveniencia; sin políticas de red dejando todo el tráfico saliente permitido; imágenes base con instalaciones completas de SO en lugar de imágenes mínimas.
Qué verificar: Todas las claves API, secretos de cliente OAuth, credenciales de base de datos y tokens de cuenta de servicio se almacenan en una bóveda de secretos (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, etc.). No existen secretos en variables de entorno, código fuente, imágenes de contenedor o salida de registro. Las operaciones de gestión de secretos ocurren en middleware que es inaccesible para el modelo de IA — el LLM nunca ve ni procesa valores de credenciales.
Cómo probar: Busque en los registros cadenas similares a credenciales. Inspeccione las variables de entorno accesibles al proceso del servidor. Revise el contexto accesible del modelo para confirmar que no aparezcan valores de credenciales.
Modos de falla comunes: Claves API en archivos .env comprometidos al control de versiones; credenciales devueltas en mensajes de error que llegan al modelo; secretos pasados como parámetros de herramienta que aparecen en el contexto de conversación del modelo.
Qué verificar: El pipeline de despliegue incluye escaneo de seguridad automatizado (SAST, SCA, escaneo de vulnerabilidades de dependencias) como puertas estrictas — los escaneos fallidos bloquean el despliegue. Todas las invocaciones de herramientas, eventos de autenticación y decisiones de autorización se registran de forma inmutable con contexto completo. Los registros son ingeridos por un SIEM con alertas en tiempo real sobre patrones anómalos (picos de validación fallida, frecuencia inusual de llamadas de herramientas, conexiones externas inesperadas).
Cómo probar: Introduzca una dependencia con vulnerabilidad conocida y verifique que el pipeline CI/CD falle la construcción. Genere patrones anómalos de llamadas de herramientas y verifique que las alertas SIEM se disparen dentro del tiempo de respuesta esperado.
Modos de falla comunes: Escaneo de seguridad como asesoramiento en lugar de puertas de bloqueo; registros escritos en almacenamiento mutable que un atacante podría modificar; sin alertas sobre patrones anómalos; verbosidad excesiva de registros que hace imposible encontrar eventos relevantes.
Imprima o exporte esta lista de verificación y trabaje en ella sistemáticamente para cada servidor MCP antes del despliegue en producción. Involucre a su equipo de seguridad en la revisión — muchos elementos requieren tanto revisión de código como pruebas en vivo para verificar correctamente.
Para equipos que desean verificación independiente, una auditoría de seguridad MCP profesional prueba los 16 elementos de la lista de verificación contra su entorno en vivo, utilizando técnicas de prueba adversarias en lugar de autoevaluación. El resultado es un informe de postura de seguridad verificado con un plan de remediación priorizado.
La 'Barra Mínima de Seguridad MCP' del Proyecto de Seguridad GenAI de OWASP es una lista de verificación de revisión que define los controles de seguridad básicos requeridos antes de que un servidor MCP deba desplegarse en producción. Cubre cinco dominios: Identidad/Autenticación/Aplicación de Políticas Sólidas, Aislamiento Estricto y Control del Ciclo de Vida, Herramientas Confiables y Controladas, Validación Basada en Esquemas y Despliegue Endurecido con Supervisión Continua. No cumplir con la barra mínima significa que el servidor MCP no debe desplegarse hasta que se remedien las brechas.
Trabaje sistemáticamente en cada categoría, marcando elementos como APROBADO, REPROBADO o NO APLICABLE con evidencia para cada decisión. Cualquier REPROBADO en las categorías 1 o 2 (identidad y aislamiento) debe bloquear el despliegue — estas son las brechas de mayor riesgo. Los REPROBADOS en otras categorías deben ser aceptados con riesgo y con un cronograma de remediación documentado antes del despliegue. La lista de verificación debe reevaluarse después de cualquier cambio significativo en el servidor MCP, registro de herramientas o entorno de despliegue.
Varias herramientas soportan la validación automatizada de seguridad MCP: Invariant MCP-Scan (especializado en escaneo de seguridad MCP), herramientas SAST con reglas MCP personalizadas, npm audit y pip audit para escaneo de dependencias, OSV-Scanner para verificaciones de base de datos de vulnerabilidades, perfiles Docker seccomp y AppArmor para aislamiento en tiempo de ejecución, e integración SIEM para monitoreo centralizado. Ninguna herramienta individual cubre todos los elementos de la lista de verificación — la cobertura completa requiere combinar análisis estático, pruebas dinámicas y monitoreo continuo.
Arshia es ingeniera de flujos de trabajo de IA en FlowHunt. Con formación en ciencias de la computación y una pasión por la IA, se especializa en crear flujos de trabajo eficientes que integran herramientas de IA en las tareas cotidianas, mejorando la productividad y la creatividad.
Use esta lista de verificación para autoevaluarse, luego incorpore a nuestro equipo para una auditoría de seguridad verificada. Probamos cada elemento contra su entorno en vivo y entregamos un plan de remediación detallado.
La autenticación es la capa de seguridad más crítica para los servidores MCP remotos. Aprende por qué OAuth 2.1 con OIDC es obligatorio, cómo la delegación de t...
Los servidores MCP exponen una superficie de ataque única que combina riesgos tradicionales de API con amenazas específicas de IA. Aprende las 6 vulnerabilidade...
Desarrollo y despliegue de servidores personalizados Model Context Protocol (MCP) para una integración fluida de APIs y bases de datos heredadas con modelos de ...
