Guía OWASP para servidores MCP: ocho dominios de seguridad para producción

Cuando se habla del Open Worldwide Application Security Project (OWASP) para Model Context Protocol (MCP), es habitual pensar primero en un Top 10. Sin embargo, la propuesta de OWASP es más amplia: incluye una guía de ingeniería, una referencia operativa, una taxonomía de riesgos y un proceso específico para evaluar servidores de terceros.

El documento central es A Practical Guide for Secure MCP Server Development, versión 1.0, publicado en febrero de 2026 por el OWASP GenAI Security Project dentro de su Agentic Security Initiative. Su punto de partida es que un servidor MCP concentra permisos delegados, herramientas dinámicas y llamadas encadenadas capaces de convertir una instrucción en una acción sobre sistemas y datos.

No es una certificación ni la especificación del protocolo. Es una guía de ingeniería que organiza el trabajo en ocho dominios y establece una barrera mínima antes de producción.

El mapa de OWASP para MCP

Los recursos cumplen funciones diferentes y conviene utilizarlos juntos.

La relación puede resumirse así: la guía diseña; la Cheat Sheet verifica; el Top 10 clasifica; la guía de terceros decide qué admitir; la especificación define el protocolo.

Qué evalúa OWASP en una implementación MCP

La arquitectura de referencia puede representarse como:

usuario → host MCP —la aplicación de IA— → cliente MCP → servidor MCP → herramientas, datos y APIs

OWASP analiza el recorrido completo, no solo el servidor. El modelo de amenazas debe identificar activos —tokens, archivos, datos, contexto, memoria y herramientas—, fronteras de confianza y cuatro identidades distintas: usuario, cliente MCP, identidad de la carga de trabajo que ejecuta el servidor (workload identity) y servicio posterior.

También debe separar los escenarios local y remoto. Un servidor por stdio puede heredar acceso a procesos, archivos y credenciales del equipo. Un servidor por Streamable HTTP incorpora riesgos de red, autenticación, entornos multi-tenant —varias organizaciones aisladas dentro del mismo servicio— y servicios posteriores. En ambos casos, el punto crítico es la combinación de contenido no confiable con autoridad efectiva.

Actualización de protocolo: la guía de OWASP precede a MCP 2026-07-28. La versión vigente eliminó las sesiones del protocolo, Mcp-Session-Id y initialize. Por tanto, las referencias de OWASP a “aislamiento de sesión” deben traducirse hoy a aislamiento de identidad, solicitud, contexto, cómputo y estado de aplicación, incluidos los identificadores emitidos por el servidor para mantener estado entre llamadas (server-minted handles). Las implementaciones compatibles con versiones de 2025 todavía pueden mantener sesiones.

La guía práctica de OWASP, dominio por dominio

La guía principal recorre ocho dominios. Cada uno responde a una parte distinta del ciclo de vida.

1. Secure MCP Architecture — Arquitectura MCP segura. OWASP propone documentar fronteras de confianza, identidades y autoridad antes de incorporar herramientas. El diseño debe separar cada usuario y tenant, distinguir estado de protocolo de identidad, aislar contexto y cómputo, y establecer límites de tiempo, memoria, concurrencia y profundidad de llamadas. La arquitectura local y la remota necesitan modelos de amenaza distintos.

2. Safe Tool Design — Diseño seguro de herramientas. Una herramienta debe tratarse como un contrato de seguridad. Su nombre, descripción, parámetros, salida, permisos, destinos, efectos secundarios, propietario y límites deben ser auditables. OWASP recomienda esquemas estrictos —incluido additionalProperties: false cuando corresponda—, clasificación por impacto y control de versión y valor hash. El contrato y el artefacto deben vigilarse para detectar cambios maliciosos posteriores a la aprobación.

3. Data Validation & Resource Management — Validación y gestión de recursos. Las entradas pueden haber sido generadas por un modelo influido por documentos o páginas externas; las salidas pueden contener instrucciones destinadas a modificar su comportamiento. OWASP recomienda combinar validación estructural y semántica, autorización del objeto y defensas frente a la inyección de comandos (command injection), la inyección SQL (SQL injection), el acceso fuera de las rutas permitidas (path traversal) y la falsificación de solicitudes del lado del servidor (Server-Side Request Forgery, SSRF). También propone límites de bytes, CPU, memoria, tiempo, reintentos y encadenamiento para evitar agotamiento de recursos.

4. Prompt Injection Controls — Controles frente a la inyección de instrucciones. OWASP no considera suficiente reforzar el mensaje de sistema (system prompt). La arquitectura debe separar datos de instrucciones, conservar la intención original, controlar flujos entre servidores y colocar la política fuera del modelo. Para acciones destructivas, financieras o de divulgación, la confirmación humana debe mostrar acción, destino, datos y parámetros exactos; cualquier cambio requiere una nueva decisión.

5. Authentication & Authorization — Autenticación y autorización. En servidores HTTP protegidos, MCP utiliza un flujo basado en OAuth. El servidor publica los metadatos OAuth 2.0 del recurso protegido (OAuth 2.0 Protected Resource Metadata, RFC 9728); el cliente descubre y valida el servidor de autorización, utiliza PKCE e incluye resource; y el servidor MCP valida que el token de acceso tenga la audiencia prevista. OWASP refuerza el uso de alcances OAuth (scopes) mínimos y la autorización por herramienta, objeto y tenant en cada solicitud. El token emitido para el servidor MCP no debe reenviarse a una API posterior: ese servicio necesita una credencial o delegación distinta, con audiencia y alcance propios.

En stdio, el flujo OAuth de MCP no se aplica de forma directa. Las credenciales deben obtenerse desde un almacén seguro y entregarse únicamente al proceso autorizado. OAuth delega autorización; OIDC añade identidad. Un JWT requiere validar firma y restricciones, mientras que un token opaco utiliza introspección o el mecanismo definido por su servidor de autorización.

6. Secure Deployment & Updates — Despliegue y actualizaciones. El entorno debe operar sin privilegios, con sistema de archivos mínimo, tráfico saliente bloqueado por defecto, secretos fuera del contexto del modelo y límites por usuario o tenant. En Streamable HTTP se valida el encabezado HTTP Origin y se responde 403 cuando es inválido; un servicio exclusivamente local debe escuchar en 127.0.0.1 u otra dirección de bucle local (loopback), no en 0.0.0.0.

El dominio también cubre la cadena de suministro: procedencia, artefactos fijados mediante versión y valor hash, lista de materiales de software (SBOM), análisis de dependencias, controles en CI/CD, despliegue gradual y capacidad de reversión (rollback). TLS protege el tránsito entre los dos extremos de cada conexión. Para escenarios de alto riesgo, la Cheat Sheet recomienda firma a nivel de mensaje, un valor de un solo uso (nonce) y protección contra ataques de repetición (replay); es una defensa adicional, no un requisito universal del núcleo MCP.

7. Governance — Gobernanza. OWASP establece como control que servidores, herramientas e identidades tengan propietario, inventario, clasificación y fecha de revisión. Los permisos, credenciales y elevaciones de privilegio deben contar con expiración y capacidad de revocación. La gobernanza incluye identidades no humanas, retención de memoria y contexto, registros de auditoría con secretos y datos sensibles enmascarados o excluidos, y responsables de respuesta a incidentes. Esta disciplina permite detectar Shadow MCP Servers, es decir, servidores MCP no registrados que operan fuera del inventario y de los controles organizacionales.

8. Tools & Continuous Validation — Herramientas de seguridad y validación continua. La aprobación inicial no sustituye la evaluación durante todo el ciclo de vida. Antes de producción deben probarse escenarios de alteración maliciosa de herramientas (tool poisoning), alteración maliciosa de esquemas (schema poisoning) e inyección de instrucciones en las respuestas de herramientas, además de acceso entre tenants, autorización de objetos, SSRF, exfiltración y agotamiento de recursos. En operación se monitorean nuevas herramientas, valores hash, destinos, acciones administrativas y cambios de dependencias. La organización debe disponer de reversión, revocación y un mecanismo de desactivación de emergencia (kill switch).

MCP Security Minimum Bar (Review Checklist)

Después de los ocho dominios, la guía establece la MCP Security Minimum Bar (Review Checklist), o barrera mínima de seguridad para MCP. No resume todos los controles; define las condiciones que no deberían faltar al autorizar un lanzamiento.

• Identidad, autorización y política: identidades diferenciadas, alcance mínimo y decisiones independientes del modelo.
• Aislamiento y ciclo de vida: separación de usuario, tenant, contexto, estado y cómputo, con limpieza y límites verificables.
• Herramientas confiables: contrato y artefacto exactos, aprobados y vigilados contra cambios.
• Validación dirigida por esquemas: mensajes, entradas y salidas validados, junto con reglas semánticas y autorización del objeto.
• Despliegue y supervisión: entorno endurecido, secretos protegidos, cadena de suministro controlada, telemetría y revocación.

Para OWASP, la existencia de una política no demuestra que el control funcione. La barrera mínima necesita evidencia: configuraciones, pruebas, registros, decisiones de autorización y procedimientos de revocación.

Qué añade el MCP Security Cheat Sheet

El MCP Security Cheat Sheet complementa la guía con doce prácticas para revisión técnica. Manteniendo sus denominaciones oficiales, pueden agruparse en cuatro bloques:

• Autoridad y contratos: Principle of Least Privilege; Tool Description & Schema Integrity; Human-in-the-Loop for Sensitive Actions.
• Aislamiento y datos: Sandbox and Isolate MCP Servers; Input and Output Validation; Multi-Server Isolation & Cross-Origin Protection; Prompt Injection via Tool Return Values.
• Identidad e integridad: Authentication, Authorization & Transport Security; Message-Level Integrity and Replay Protection.
• Operación: Supply Chain Security; Monitoring, Logging & Auditing; Consent & Installation Security.

La Cheat Sheet funciona como lista operativa. No reemplaza el análisis de arquitectura ni convierte cada recomendación en un requisito normativo de MCP. Por ejemplo, la firma de mensajes es una medida avanzada de OWASP, no una capacidad obligatoria del protocolo base.

Relación entre la guía práctica y el OWASP MCP Top 10 beta

El OWASP MCP Top 10 sirve para nombrar escenarios de riesgo y justificar controles. No es el índice de la guía práctica, no sustituye la barrera mínima y, en su versión 0.1 beta, todavía puede cambiar.

La página beta mantiene nombres diferentes para MCP06 en distintas secciones. Este artículo utiliza Intent Flow Subversion, el nombre de su lista principal al 31 de julio de 2026.

Evaluación de servidores MCP de terceros

La guía para utilizar servidores MCP de terceros cambia la pregunta de “¿cómo se construye?” a “¿qué evidencia permite confiar en él?”. Con sus denominaciones oficiales, OWASP destaca cuatro amenazas específicas: tool poisoning —alteración maliciosa de una herramienta—, prompt injection —instrucciones maliciosas dentro del contexto—, memory poisoning —contaminación del estado persistente— y tool interference —interferencia entre herramientas—.

El proceso de admisión recomendado incluye:

1. verificar editor, repositorio, artefacto, licencia y contrato de herramientas;
2. revisar comando, argumentos, permisos, acceso al sistema de archivos y destinos de red;
3. probar en un entorno aislado (sandbox) sin secretos ni datos reales;
4. obtener aprobación de seguridad y del propietario del dominio afectado;
5. fijar versión y valor hash, generar una SBOM y desplegar de forma gradual;
6. monitorear vulnerabilidades y cambios, revalidar y mantener reversión y revocación.

La presencia de un servidor en un registro público facilita el descubrimiento, pero no equivale a aprobación organizacional.

Aplicación integrada de los recursos de OWASP

En diseño, la guía práctica organiza la arquitectura y los ocho dominios. Durante la revisión, la Cheat Sheet verifica controles concretos. El Top 10 ayuda a registrar y comunicar riesgos. La guía de terceros define el proceso de admisión cuando el servidor no fue desarrollado internamente. La especificación MCP resuelve cualquier duda sobre requisitos normativos del protocolo.

La contribución principal de OWASP no es únicamente una lista de vulnerabilidades. Es un método para relacionar arquitectura, herramientas, identidad, despliegue y gobernanza con evidencia verificable durante todo el ciclo de vida.

La evaluación previa debe establecer quién solicita cada acción, qué datos intervienen, qué política la autoriza, qué aislamiento la contiene y cómo puede revocarse. Ese criterio permite convertir una integración funcional en una integración controlable, auditable y revocable.

---

Fuentes y fecha de corte — 31 de julio de 2026: este artículo resume y adapta la guía práctica de desarrollo seguro, la Agentic Security Initiative, la guía para servidores de terceros, el MCP Security Cheat Sheet, el OWASP MCP Top 10, la especificación MCP 2026-07-28 y sus cambios de versión. Verifica las versiones y licencias vigentes antes de publicar, reutilizar material o convertir esta síntesis en un control de cumplimiento.