Un playbook de seguridad para MCP y uso de herramientas

Saber que existen vulnerabilidades en MCP es una cosa; tener un playbook organizacional que asigne dueño, proceso y respuesta a cada categoría de riesgo es otra. La investigación MCPSHIELD mapeó "7 threat categories and 23 distinct attack vectors organized across four attack surfaces" analizando más de 177.000 herramientas MCP registradas - lo que da a cualquier equipo de seguridad un punto de partida concreto para organizar controles, no solo identificarlos.

Por qué ningún control aislado es suficiente

El hallazgo más importante de MCPSHIELD no es la lista de vulnerabilidades - es que ningún mecanismo de defensa aislado cubre más del 34% de la superficie de amenaza mapeada. Eso cambia la lógica de un playbook de seguridad: en vez de elegir "el mejor control", el objetivo es combinar controles complementarios. La arquitectura que el propio MCPSHIELD propone combina control de acceso basado en capacidades, atestación criptográfica de herramientas, rastreo de flujo de información y aplicación de políticas en tiempo real - y aun esa combinación alcanza un 91% de cobertura teórica, no el 100%.

Tool registry como artefacto de gobernanza, no solo técnico

Un tool registry central - que liste toda herramienta MCP aprobada, su alcance, su dueño y su última revisión de seguridad - es lo que convierte "autenticación" y "autorización" de conceptos técnicos en un proceso auditable. GitHub recomienda validar JWT contra JWKS y verificar la audiencia del token; ese control solo funciona a escala organizacional si existe un registro central que defina qué herramientas existen y quién puede invocarlas.

Alcance mínimo y validación de inputs como política, no como buena práctica opcional

Cada tool expuesta vía MCP debe tener el menor alcance posible - nunca acceso total a un sistema. Ningún input que venga del agente debe confiarse sin sanitización, porque el agente está, por definición, expuesto a contenido que no controla totalmente (resultado de búsqueda, documento externo, respuesta de otra herramienta).

Logging, política de runtime y threat modeling como ciclo continuo

GitHub recomienda logging estructurado con IDs de correlación y distributed tracing vía OpenTelemetry, capturando específicamente eventos de seguridad - intentos de autenticación, fallos de autorización, patrones inusuales. Eso solo se convierte en playbook cuando existe un proceso definido de revisión de esos registros, no solo su recolección. La política de runtime (rate limiting, circuit breakers en el gateway) y el threat modeling periódico - revisitando la lista de 23 vectores de ataque de MCPSHIELD a medida que se añaden nuevas herramientas - cierran el ciclo.

Aprobación humana: dónde realmente necesita entrar

No toda llamada a herramienta necesita aprobación humana - eso volvería inútil al agente. El playbook necesita distinguir: las herramientas de solo lectura y bajo riesgo pueden correr de forma autónoma; las herramientas que escriben, eliminan o mueven dinero requieren un punto de control humano antes de ejecutarse, especialmente cuando se invocan desde triggers automáticos.

Los diez controles del playbook

1. Autenticación - OAuth 2.1, validación de token contra JWKS
2. Autorización - alcance por identidad extraída del token, no asumida
3. Alcance mínimo - nunca acceso total a un sistema mediante una herramienta
4. Validación de inputs - nunca confiar en un parámetro que venga del agente
5. Tool registry - inventario central con dueño y alcance por herramienta
6. Tool governance - proceso de aprobación para cada herramienta nueva
7. Logging - eventos de seguridad capturados aparte de los registros generales
8. Política de runtime - rate limit y circuit breaker en el gateway
9. Aprobación humana - punto de control obligatorio para acciones de escritura/eliminación
10. Threat modeling - revisión periódica contra la taxonomía de vectores conocidos

Fuentes

• GitHub - How to build secure and scalable remote MCP servers - https://github.blog/ai-and-ml/generative-ai/how-to-build-secure-and-scalable-remote-mcp-servers/
• Arxiv - MCPSHIELD - https://arxiv.org/abs/2604.05969