Volver a la Biblioteca
Seguridad y gobernanza

Lista de verificación de endurecimiento de seguridad MCP: 1,467 servidores expuestos y los controles que los cierran

Por Última actualización: 27 de julio de 2026

Actualización — 2026-08-18: OWASP GenAI MCP Server Security Baseline, MCP Project Sandboxing Baseline, bugs MCP Ruby SDK y file server — tres nuevos estándares y nuevas clases CVE

Tres desarrollos añaden dos nuevos estándares MCP y nuevas clases CVE: baseline de desarrollo OWASP GenAI, baseline de despliegue MCP Project, y vulnerabilidades en Ruby SDK y file server.

  1. OWASP GenAI MCP Server Security Baseline (18 de agosto) — controles de desarrollo. Guía práctica para desarrollo seguro de servidores MCP. Junto con OWASP MCP Top 10 (catálogo de riesgos) y MCP Project Sandboxing Baseline (controles de despliegue), forman un framework de seguridad MCP en capas.

  2. MCP Project Sandboxing Baseline (16 de agosto) — controles de despliegue de los autores del spec. El proyecto MCP publicó mejores prácticas requiriendo sandboxing o containerización para procesos spawned. La baseline más autoritativa de hardening MCP, de los autores del protocolo.

  3. Bugs MCP Ruby SDK y file server (16 de agosto) — nuevas clases CVE. DoS en Ruby SDK y file-disclosure por validación de ruta insuficiente. El catálogo CVE MCP ahora abarca Python, TypeScript, Java, Ruby y C# SDKs. Véase el MCP Module Code Standard.

Actualización — 2026-08-17: CVE-2026-75011 NetForensicMCP y la dimensión de control de exposición de datos de Forcepoint

Dos desarrollos extienden esta lista de verificación: un nuevo CVE de inyección de comandos STDIO y una nueva dimensión de control — exposición de datos — que Forcepoint reencuadró como una preocupación de seguridad MCP de primera clase.

  1. CVE-2026-75011 — NetForensicMCP 2.1.0 inyección de comandos. Causa raíz: misma clase de inyección de comandos STDIO que CISA KEV CVE-2026-42271 y OX Security Familia 1. Cerrado por Control 1 (registro de herramientas — sanitizar todas las entradas) y Control 7 (endurecimiento STDIO — sin entrada controlada por usuario en cadenas de comandos).

  2. Reencuadre de exposición de datos de Forcepoint — una nueva dimensión de control. "La autenticación arregla la puerta, no los datos." El backdoor de Postmark MCP es recontextualizado como incidente de exposición de datos. Cuatro preguntas de gobernanza: (1) ¿El agente tiene credenciales directas o intermediadas? (2) ¿El cumplimiento está al nivel de campo o de aplicación? (3) ¿Las acciones de alto riesgo están controladas por un humano? (4) ¿Hay un rastro de atribución completo?

Trend Micro escaneó internet y encontró 1.467 servidores MCP abiertos — sin autenticación, sin cifrado, accesibles por cualquiera. Practical DevSecOps encontró que el 82% de 2.614 servidores encuestados son vulnerables a path traversal. Un protocolo diseñado para conectar agentes de IA a sistemas empresariales se publicó sin una base de seguridad de producción, y los patrones de despliegue lo demuestran: la mayoría de los equipos expusieron MCP a internet antes de endurecerlo. Este checklist es la base que debería haber venido primero — 12 controles de transporte, autenticación, registro de herramientas, runtime y auditoría, cada uno verificable en menos de cinco minutos antes de que un servidor MCP toque tráfico de producción.

Puntos clave

  • 1,467 servidores MCP son accesibles públicamente sin autenticación ni cifrado — escaneo corregido de Trend Micro, julio de 2026. 1,227 de ellos ejecutan el transporte SSE deprecado que la especificación 2026-07-28 retira con un reloj de deprecación de 12 meses.
  • 82% de 2,614 servidores MCP encuestados son vulnerables a path traversal, y solo 8.5% usan OAuth — Practical DevSecOps MCP Security Statistics 2026 Report. Las clases de ataque están generalizadas en servidores desplegados, no son teóricas.
  • 3 CVEs aterrizaron en el SDK oficial de Python de MCP en julio de 2026 — CVE-2026-59950 (DNS rebinding/CSRF), CVE-2026-52869 (peticiones de sesión no verificadas), CVE-2026-52870 (manejadores de tareas abiertos). La implementación de referencia envió la misma clase de flaw que los servidores comunitarios.
  • 78.3% de tasa de éxito de ataque cuando 5 servidores MCP se conectan a 1 agente — Palo Alto Networks Unit 42. Cinco servidores es un despliegue típico, no uno grande. OX Security identificó un RCE arquitectónico que afecta 150M+ descargas, y la Cloud Security Alliance clasificó la seguridad de MCP como un problema de design-flaw sistémico.
  • La especificación MCP 2026-07-28 se publica como final el 28 de julio de 2026 — los cuatro SDKs Tier 1 (TypeScript, Python, Go, C#) hablan el nuevo núcleo sin estado, con una política de deprecación de 12 meses para el transporte SSE. La migración y el endurecimiento son el mismo trabajo.
  • Deadbugz convierte el runtime en superficie de ataque: el envenenamiento de metadatos espera hasta que confías en el servidor — Pillar Security divulgó el 23 de septiembre de 2026 una campaña activa en la cadena de suministro de MCP: 23 pull requests en 74 minutos ofrecían un servidor "productivity-suite" que se comporta normalmente durante tres llamadas a herramientas y luego reescribe los metadatos de sus herramientas para buscar claves SSH, credenciales de AWS, historial de shell y configuración de Kubernetes (Pillar Security). El escaneo en tiempo de aprobación no puede verlo — vea la actualización de 2026-09-30 más abajo.

Un despliegue MCP de producción que pasa los 12 controles de esta lista de verificación no es invulnerable — ningún sistema lo es — pero ya no está en la población que Trend Micro encontró, que Practical DevSecOps escaneó, o que la oleada de CVEs de julio atrapó. La lista de verificación mapea cada control a la categoría del OWASP MCP Top 10 que aborda, el CVE o exposición que previene, y el paso de verificación que un operador puede ejecutar en menos de cinco minutos. El Microsoft Agent Governance Toolkit — el primer runtime de gobernanza open-source enviado por un hyperscaler con cobertura 10/10 del OWASP MCP Top 10 — es la implementación de referencia. Este artículo es el complemento operativo: una revisión de endurecimiento escaneable para un Head of Engineering o líder de plataforma preparándose para exponer un servidor MCP a tráfico de producción.

Actualización — 2026-08-07: Productos de descubrimiento de servidores MCP de Black Hat 2026 — Cyera, SailPoint, Check Point

El inventario completo de productos de Black Hat 2026 (crn.com, 4 de agosto de 2026) añade tres productos que abordan directamente el Control 12 (detección de servidores en la sombra) y la dimensión de descubribilidad y gobernanza de servidores MCP de esta lista de verificación.

  1. Cyera Agent Guardian — descubrimiento de servidores MCP en la sombra. Cyera lanzó Agent Guardian para descubrir servidores MCP en la sombra y agentes de IA no sancionados en toda la empresa. Para el Control 12 (detección de servidores en la sombra), Cyera es la versión productizada del patrón de inventario y monitoreo de deriva: en lugar de mantener manualmente un inventario de servidores MCP y verificarlo contra un registro, Cyera descubre automáticamente servidores MCP en producción — incluyendo los que nunca fueron registrados. Los 1,467 servidores expuestos que Trend Micro encontró son la población accesible desde internet; Cyera aborda la población interna — servidores MCP ejecutándose dentro de la red corporativa que nadie conoce.

  2. SailPoint Identity Security — gobernanza de identidad de servidores MCP. SailPoint extendió su plataforma Identity Security para cubrir identidades de servidores MCP junto con identidades humanas y de agentes. Para el Control 4 (separación de identidad de agentes), SailPoint añade los servidores MCP como un tipo de identidad gestionada — cada servidor MCP tiene un ciclo de vida (provisionamiento, atestación, revocación) gestionado por la misma infraestructura de gobernanza de identidad que maneja identidades humanas.

  3. Check Point AI Network Firewall — monitoreo de comunicaciones MCP. Check Point lanzó un AI Network Firewall que monitorea el tráfico MCP — la comunicación entre agentes y servidores MCP — en busca de violaciones de política y exfiltración de datos. Para el Control 9 (límite de contexto), Check Point añade aplicación a nivel de red: un servidor de herramientas que intenta exfiltrar datos a través de sus respuestas MCP es detectado en el firewall, no solo por la lógica de alcance de contexto del agente.

La categoría de productos de seguridad MCP ahora tiene proveedores dedicados para descubrimiento de servidores en la sombra (Cyera), gobernanza de identidad (SailPoint) y monitoreo a nivel de red (Check Point) — tres superficies que los 12 controles de esta lista de verificación abordan pero que previamente requerían construcciones personalizadas. Los 1,467 servidores expuestos y el 82% de exposición a path traversal son la población que esta lista de verificación cierra; la ola de productos de Black Hat 2026 da a los operadores herramientas de proveedor para cerrarlas a escala.

La superficie de ataque, en números

El OWASP MCP Top 10 (Beta Release v0.1, Phase 3 of 5) cataloga 10 categorías de riesgo nombradas a lo largo del ciclo de vida del sistema habilitado por MCP. Los números detrás de ellas son lo que convierte "la gobernanza es buena práctica" en "la gobernanza es una puerta de producción":

  • 1,467 servidores expuestos — el escaneo corregido de Trend Micro encontró 1,467 servidores MCP accesibles públicamente sin autenticación ni cifrado, desde un conteo inicial de 492. 1,227 ejecutan el transporte SSE deprecado. Al menos tres exponen registros médicos de pacientes vía una herramienta progress_note. La herramienta execute_sql aparece en 70 hosts.
  • 82% de exposición a path traversal — Practical DevSecOps midió 82% de vulnerabilidad a path traversal y 8.5% de adopción de OAuth en 2,614 servidores encuestados. 97M+ descargas mensuales de MCP significa que la exposición escala con la adopción.
  • 150M+ descargas afectadas por RCE arquitectónico — OX Security enmarcó la causa raíz de inyección de comandos STDIO como un flaw a nivel arquitectónico, no CVEs aislados. La Cloud Security Alliance lo clasificó como un problema de design-flaw sistémico en la infraestructura de agentes de IA.
  • 3 CVEs en el SDK en julio de 2026 — CVE-2026-59950 (falta de validación Host/Origin, DNS rebinding/CSRF), CVE-2026-52869 (peticiones de sesión no verificadas), CVE-2026-52870 (manejadores de tareas abiertos). El SDK oficial de Python — la implementación de referencia de la que hereda todo servidor MCP en Python — envió la misma clase de flaw que los servidores comunitarios que soporta.
  • 3 nuevas superficies de ataque en la especificación final — backslash.security identificó tres nuevas superficies de ataque introducidas por el rediseño sin estado en la especificación 2026-07-28. Las nuevas capacidades crean nuevos puntos de entrada que la comunidad de seguridad aún está mapeando.

El análisis de cataam.com enmarca el estado de la seguridad de MCP con precisión: "La seguridad de MCP está aproximadamente donde estaba la seguridad web hace quince años — los ataques son viejos, solo el objetivo es nuevo." La lista de verificación de endurecimiento de abajo es el conjunto de controles que movió la seguridad web de 82% de exposición a path traversal a una línea base donde se espera que los sistemas de producción pasen. Los mismos controles aplican aquí.

Los 12 controles de endurecimiento

La lista de verificación se organiza en cinco capas que mapean al OWASP MCP Top 10 y a los cambios de la especificación MCP 2026-07-28:

MCP Security Hardening Checklist 12 controls across 5 layers — maps to OWASP MCP Top 10 1 Transport & Network Spec 2026-07-28 + OWASP MCP07 2 controls CONTROL 1 SSE to Streamable HTTP migration 12-month deprecation — 1,227 servers affected CONTROL 2 Network isolation & origin validation CVE-2026-59950 — DNS rebinding defense 2 Authentication & Identity OAuth 2.1 + OIDC — spec mandate 2 controls CONTROL 3 OAuth 2.1 + OIDC enforcement RFC 8707 + RFC 9207 — 8.5% baseline CONTROL 4 Agent identity separation NIST OAuth 2.0 + SPIFFE/SPIRE 3 Tool Registration & Supply Chain OWASP MCP03 + MCP04 3 controls CONTROL 5 Tool poisoning scan MCP03 — injection + typosquatting CONTROL 6 Signed provenance MCP04 — AIBOM inventory CONTROL 7 STDIO hardening 150M+ downloads — OX Security 4 Runtime & Execution OWASP MCP05 + MCP06 + MCP10 3 controls CONTROL 8 Rate limiting Per-agent, per-tool, per-window CONTROL 9 Context boundary MCP10 — scoped per tool, no oversharing CONTROL 10 Kill-switch per module Feature-flag disable, no redeploy 5 Audit & Telemetry OWASP MCP08 + MCP09 2 controls CONTROL 11 Per-call audit logging MCP08 — immutable, structured JSON CONTROL 12 Shadow server detection MCP09 — registry vetting, drift monitoring OWASP MCP TOP 10 MAPPED OWASP MCP01-10 Spec 2026-07-28 Microsoft AGT NIST AI Agent CSA 1,467 exposed servers, zero auth 82% path traversal exposure 78.3% attack rate at 5 servers 8.5% use OAuth today 12 controls across 5 layers — ideabosque.com/library

Capa 1 — Transporte y red

Control 1: Migración de SSE a Streamable HTTP. La especificación MCP 2026-07-28 se publica como final el 28 de julio de 2026, con una política de deprecación de 12 meses para el transporte HTTP+SSE. Los cuatro SDKs Tier 1 (TypeScript, Python, Go, C#) hablan el nuevo núcleo sin estado a partir del día de publicación, con notas de migración para las partes que rompen. Los 1,227 servidores SSE deprecados en el escaneo de Trend Micro son la población más afectada — ejecutan un transporte que la especificación está retirando. Verificación: revise la configuración de transporte del servidor. Si sirve SSE, está en el reloj de deprecación. Migre a Streamable HTTP antes de que la ventana de 12 meses cierre.

Control 2: Aislamiento de red y validación de origen. CVE-2026-59950 — confirmado en la National Vulnerability Database — es un flaw de falta de validación Host/Origin en el SDK oficial de Python de MCP. Una página web que la víctima visita puede dirigir su servidor MCP local vía DNS rebinding y CSRF. El navegador se convierte en el proxy del atacante hacia un servidor loopback que el operador creía privado. Verificación: confirme que el servidor valida los headers Host y Origin en cada petición. Si el servidor está expuesto a internet, confirme que está detrás de un límite de red que previene acceso directo desde orígenes no confiables. Un servidor que nunca debería haber sido alcanzable desde internet público no debe ser accesible desde internet público.

Capa 2 — Autenticación e identidad

Control 3: Aplicación de OAuth 2.1 + OIDC. La especificación 2026-07-28 hace obligatorio OAuth 2.1 más OpenID Connect — un cambio del enfoque anterior de "trae tu propio token". La guía de migración de autenticación de WorkOS detalla los requisitos: RFC 8707 (Resource Indicators) para prevenir replay de tokens entre servidores, Client ID Metadata Documents reemplazando Dynamic Client Registration, verificación de issuer (RFC 9207). El hallazgo de Practical DevSecOps — solo 8.5% de los servidores encuestados usan OAuth — es la línea base que este control eleva. Verificación: revise la configuración de autenticación del servidor. Si acepta peticiones sin autenticar o usa API keys estáticas sin OAuth, falla. Confirme que el servidor implementa resource indicators RFC 8707.

Control 4: Separación de identidad del agente. La NIST AI Agent Standards Initiative (febrero de 2026) propone tratar a los agentes como identidades no humanas distintas con su propio ciclo de vida: aprovisionamiento, atestación, revocación. La mayoría de los despliegues autentican al usuario humano y pasan esa identidad al agente. Cuando el agente toma una acción, el log de auditoría dice que la hizo el humano. Verificación: confirme que cada agente tiene su propia credencial (token OAuth, SPIFFE SVID) distinta de la del operador humano. Revocar la identidad del agente debería detener todas las llamadas del agente sin afectar el acceso del humano.

Capa 3 — Registro de herramientas y cadena de suministro

Control 5: Escaneo de tool poisoning. OWASP MCP03 nombra el tool poisoning como un riesgo top-10: rug pulls (herramientas de confianza actualizadas a versiones maliciosas), schema poisoning (definiciones de interfaz corrompidas para engañar al modelo), tool shadowing (herramientas falsas interceptando llamadas destinadas a las reales). El McpSecurityScanner del Microsoft Agent Governance Toolkit detecta tool poisoning, typosquatting e instrucciones ocultas — una herramienta demo llamada read_flie (typosquatting de read_file) con inyección en su descripción puntuó 85/100 de riesgo. Verificación: inspeccione el proceso de registro de herramientas. Si las herramientas se registran sin un escaneo de seguridad, falla. El escaneo debe cubrir patrones de prompt injection en descripciones, typosquatting contra nombres de herramientas conocidos, y directivas de sistema ocultas.

Control 6: Proveniencia firmada y monitoreo de dependencias. OWASP MCP04 cubre ataques a la cadena de suministro y manipulación de dependencias. El backdoor de Postmark MCP — el primer servidor MCP malicioso atrapado en estado salvaje — era un paquete npm de apariencia legítima que interceptaba emails silenciosamente y los exfiltraba. Pasó la revisión del registro. La investigación de UpGuard encontró que uno de cada 15 servidores MCP es un lookalike diseñado para suplantar a un servicio legítimo. Verificación: confirme que cada servidor MCP en el despliegue tiene un registro de proveniencia firmada y un inventario AIBOM (AI Bill of Materials). Confirme que el monitoreo de dependencias está activo y alerta sobre nuevos CVEs en el árbol de dependencias.

Control 7: Endurecimiento de STDIO. La divulgación de OX Security identificó un RCE arquitectónico en configuraciones STDIO que afecta 150M+ descargas. La causa raíz: shell: true en el SDK de TypeScript habilitaba inyección de comandos vía strings de configuración. La Cloud Security Alliance clasificó esto como un problema de design-flaw sistémico. Verificación: si el servidor usa transporte STDIO, confirme que shell: false o el endurecimiento equivalente está configurado. Confirme que las allowlists de comandos verifican argumentos, no solo nombres de binarios — los bypasses de Upsonic y Flowise (CVE-2026-30625, CVE-2026-40933) demostraron que npx -c <comando-malicioso> pasa a través de una allowlist que verifica solo el binario.

Capa 4 — Tiempo de ejecución y ejecución

Control 8: Rate limiting. Cada herramienta declara su propio límite de tasa en la llamada de registro. El backbone aplica límites por-agente, por-herramienta y por-ventana. Cuando se alcanza un límite, el agente recibe una respuesta 429 con un header Retry-After. Un agente comprometido no puede agotar las cuotas del API upstream porque el límite de tasa se aplica en la frontera del módulo. Verificación: confirme que cada herramienta registrada tiene un límite de tasa. Confirme que el límite se aplica en la frontera del módulo, no en el API upstream. Una herramienta sin límite de tasa es una herramienta que un agente comprometido puede llamar sin límite.

Control 9: Frontera de contexto. OWASP MCP10 nombra la inyección de contexto y el sobre-compartir como un riesgo top-10. Un agente con acceso amplio al contexto filtra información a través de tenants, sesiones o usuarios — una preocupación particularmente aguda para despliegues B2B donde el mismo agente sirve a múltiples clientes con diferentes derechos de acceso a datos. Verificación: confirme que cada herramienta recibe solo el contexto que necesita para su operación específica. Confirme que la ventana de contexto está delimitada por-herramienta, no compartida globalmente entre todas las herramientas. Una herramienta que recibe el contexto completo de la sesión cuando necesita solo un campo es una superficie de fuga de datos.

Control 10: Kill-switch por módulo. Cada módulo MCP debe ser desactivable independientemente sin tocar el backbone de orquestación. El kill switch es un cambio de configuración, no un despliegue de código. Cuando se divulga una vulnerabilidad — como la oleada de CVEs de julio divulgó 3 CVEs del SDK y 7+ CVEs de servidores en una quincena — la primera pregunta del operador es: ¿puedo desactivar este módulo sin tirar el agente? En un despliegue gobernado, la respuesta es sí. Verificación: confirme que cada módulo puede ser desactivado vía un feature flag o cambio de configuración. Confirme que la ruta de desactivación ha sido probada — no solo configurada. Un kill switch que nunca ha sido ejercitado es un kill switch que fallará cuando se necesite.

Capa 5 — Auditoría y telemetría

Control 11: Logging de auditoría por llamada. OWASP MCP08 nombra la falta de auditoría y telemetría como un riesgo top-10. Sin logs de invocaciones de herramientas y cambios de contexto, el robo de tokens y la inyección permanecen invisibles. Cada llamada a una herramienta debe registrar timestamp, ID del agente, nombre de la herramienta, hash del input (no input en bruto — frontera PII), estado del output, duración, y sistema upstream. Los logs son JSON estructurado enviado al pipeline de observabilidad. Verificación: confirme que cada llamada a una herramienta produce una entrada de log estructurada. Confirme que el log incluye el hash del input, no el input en bruto. Confirme que el log es inmutable — un atacante que compromete el servidor no puede reescribir el rastro de auditoría.

Control 12: Detección de servidores shadow. OWASP MCP09 cubre los servidores MCP shadow — despliegues no aprobados o no supervisados invisibles para la gobernanza. UpGuard encontró que uno de cada 15 servidores MCP es un lookalike. Un ingeniero que instala el mcp-server-postgress equivocado (note el typo) obtiene un paquete que exfiltra silenciosamente claves SSH y archivos .env. Verificación: confirme que hay un inventario de cada servidor MCP en el despliegue. Confirme que el inventario se verifica contra un registro de paquetes conocidos-buenos. Confirme que el monitoreo de drift alerta cuando aparece un servidor nuevo que no estaba en el inventario.

Cómo los frameworks mapean a la lista de verificación

Control OWASP MCP Spec 2026-07-28 Microsoft AGT NIST CSA
1. Migración SSE — Deprecación 12 meses — — —
2. Aislamiento de red MCP07 Validación de origen — — —
3. OAuth 2.1 + OIDC MCP07 Auth obligatoria — OAuth 2.0 —
4. Identidad del agente MCP07 — AgentMesh Identity SPIFFE/SPIRE —
5. Escaneo de tool poisoning MCP03 — MCP Security Gateway — —
6. Proveniencia firmada MCP04 — — — —
7. Endurecimiento STDIO MCP05 — — — Design flaw sistémico
8. Rate limiting — — Policy Engine — —
9. Frontera de contexto MCP10 — Response sanitizer — —
10. Kill-switch por módulo — — Hypervisor kill switch — —
11. Logging de auditoría por llamada MCP08 — Audit + metrics — —
12. Detección de servidores shadow MCP09 — — — —

Ningún framework individual cubre los 12 controles. La lista de verificación es la intersección de OWASP, la especificación, Microsoft, NIST y CSA — cada uno contribuyendo los controles que los demás carecen. El Microsoft Agent Governance Toolkit cubre 10/10 categorías del OWASP MCP Top 10 (7/10 completas, 3/10 parciales con roadmap) y es el primer runtime open-source enviado por un hyperscaler con mapeos OWASP explícitos — 68 tests en el Agent OS Policy Engine, 127 tests en el MCP Security Gateway, 80 tests en el Agent Hypervisor Execution Control incluyendo el kill switch.

Puntuando la lista de verificación

Un servidor MCP listo para producción pasa los 12 controles. Un servidor parcialmente listo pasa 8–11. Un servidor que pasa menos de 8 no debería ser expuesto a tráfico de producción sin un plan de remediación documentado y una fecha objetivo para cada control fallido.

Puntaje Estado Acción
12/12 Listo para producción Desplegar con monitoreo
8–11/12 Parcialmente listo Desplegar con excepciones documentadas y timeline de remediación
<8/12 No listo No desplegar. Remediar los controles fallidos primero

El patrón de fallo más común es pasar los controles 1–4 (transporte, autenticación, identidad) mientras se fallan los controles 5–12 (cadena de suministro, runtime, auditoría). Los primeros cuatro son arquitectónicos y reciben atención en revisiones de diseño. Los últimos ocho son operacionales y se pierden hasta que un incidente o una auditoría los saca a la luz. La oleada de CVEs de julio de 2026 — 3 CVEs del SDK y 7+ CVEs de servidores en una quincena — es lo que pasa cuando los controles operacionales están ausentes.

Actualización — 2026-08-08: Skill/Plugin Security Scanning — mitigación de cadena de suministro del lado del proveedor

Anthropic lanzó Skill/Plugin Security Scanning el 6 de agosto de 2026 — la primera mitigación de cadena de suministro del lado del proveedor del modelo para servidores de herramientas de terceros. El escaneo inspecciona las cargas de terceros de Claude Code (skills y plugins) en busca de contenido malicioso antes de que lleguen al marketplace. Este es el complemento del lado del proveedor para el escaneo que un operador hace en sus propias definiciones de herramientas: Control 10 (defensa contra envenenamiento de herramientas) gobierna el escaneo que haces; Skill/Plugin Scanning gobierna lo que el proveedor del modelo hace en su marketplace.

El marco de digitalapplied.com (6 de agosto de 2026) cuantifica la brecha de producción: el 88% de los proyectos de agentes de IA nunca llegan a producción, con un costo promedio de proyecto fallido de $340,000. Siete patrones de fallo representan el 94% de los estancamientos — expansión de alcance (34%), calidad de datos (27%), bloqueadores de seguridad (14%), complejidad de integración (9%), sobrecostos (7%), brechas de gobernanza (5%) y resistencia organizacional (4%). El 12% que llega a producción comparte cuatro características: alcance más estrecho, inversión en preparación de datos, arquitectura de seguridad concurrente y gobernanza antes del despliegue. Las organizaciones que aplican evaluación estructurada de modos de fallo reducen las tasas de fallo a menos del 15% — una mejora de 4x.

Actualización — 2026-09-30: Envenenamiento de metadatos de Deadbugz con compuerta de runtime — la cuarta clase de ataque MCP derrota el escaneo en tiempo de aprobación

Pillar Security divulgó Deadbugz el 23 de septiembre de 2026 — una campaña activa en la cadena de suministro de MCP que presentó 23 pull requests de GitHub en 74 minutos, cada uno ofreciendo un servidor MCP de "productivity-suite". El servidor se comporta normalmente durante tres llamadas a herramientas; después de la tercera, el contador de llamadas por cliente que lleva consigo voltea sus propios metadatos: las respuestas subsiguientes de tools/list y prompts/get instruyen al agente de IA conectado para buscar claves SSH, credenciales de AWS, historial de shell y configuración de Kubernetes — y para ocultar la actividad al operador. El servidor anuncia tools.listChanged, por lo que el cliente recupera las definiciones envenenadas sin reconectar. La Cloud Security Alliance señala la proximidad mecánica con la anterior campaña "Miasma" en 73 repositorios de GitHub. El análisis completo del mecanismo está en el artículo de Deadbugz.

Esta es la cuarta clase de ataque MCP distinta — después de la inyección de comandos STDIO, el envenenamiento de herramientas y el bypass de SHA-pinning — y la que derrota exactamente los controles de tiempo de aprobación en la Capa 3 de esta lista de verificación. Las herramientas de Deadbugz son genuinamente benignas cuando el operador las aprueba; la carga maliciosa espera detrás de una compuerta de runtime. Ningún escaneo en el momento de la aprobación puede verlo, porque en el momento de la aprobación no hay nada que ver. La superficie de detección se mueve de la instalación al runtime.

Para la lista de verificación de 12 controles esto añade un ítem de Capa 4: detección de deriva de metadatos de herramientas después de la instalación. Registre una huella digital hash de cada definición de herramienta que un servidor devuelve cuando se aprueba — nombre, descripción, esquema de entrada, anotaciones. Cuando el servidor señala tools.listChanged (o en un horario programado), recupere las nuevas definiciones, compárelas contra la huella digital y trate cualquier diferencia como un evento de seguridad de deriva de metadatos que requiere re-aprobación del operador antes de que la herramienta modificada pueda influir en acciones sensibles. La misma comparación de huella digital atrapa la clase anterior de envenenamiento de herramientas, porque ambos ataques comparten el mecanismo de una definición de herramienta que cambia después de la aprobación. Verificación: conéctese al servidor aprobado, realice tres o más llamadas a herramientas ordinarias, luego recupere nuevamente tools/list y compárelo contra la huella digital de tiempo de aprobación — Deadbugz está diseñado para pasar cada revisión que se detiene antes de esa cuarta llamada.

Actualización — 2026-10-01: el complemento a nivel de modelo — Gemini 4 Argon lidera el benchmark IPI de Gray Swan

Las defensas a nivel de módulo de arriba ahora tienen una contraparte nombrada a nivel de modelo. La publicación cruzada MENA del 1 de octubre del anuncio de Argon señala que, mediante red teaming automatizado y entrenamiento adversarial, Gemini 4 Argon “lidera en robustez frente a prompt injection en el benchmark Indirect Prompt Injection (IPI) de Gray Swan.” Es una afirmación de benchmark del proveedor — trátela como evidencia de procurement para verificar en su propia carga de trabajo, no como un control. La lectura de arquitectura se mantiene: la robustez a nivel de modelo reduce la tasa base de inyecciones exitosas; no reemplaza los controles runtime de la Capa 3, la detección de deriva de metadatos de herramientas ni el alcance de egreso, porque una defensa que falla abierto en la capa del modelo necesita que la capa del módulo aguante. Los despliegues que combinan ambas obtienen defensa en profundidad a lo largo de la ruta de inyección; los que dependen de una sola heredan el modo de fallo de esa única capa.

Actualización — 2026-10-02: el servicio de asistencia como concentración de credenciales — la brecha del ATA de DIVD

La contraparte ofensiva de los controles de Capa-2 (autenticación) y Capa-3/4 (runtime) de esta checklist llegó a la vida real: el análisis del 2 de octubre de Sysdig documenta a un actor de amenaza agéntico vulnerando el Instituto Holandés para la Divulgación de Vulnerabilidades (DIVD) el 21 de septiembre de 2026 encadenando dos zero-days del servicio de asistencia Zammad — CVE-2026-102489 (RCE, CVSS 8.7) y CVE-2026-102490 (LPE, CVSS 8.5) — de una sesión secuestrada a root en segundos (Sysdig). Para la checklist de 12 controles esto añade un elemento de inventario de sistemas: un servicio de asistencia concentra cookies de sesión, flujos de restablecimiento de contraseña y tokens de integración — exactamente los activos que un agente que encadena hacia root necesita. Mapea cuáles de tus sistemas accesibles por agentes concentran credenciales así, verifica su postura de secuestro de sesión (la misma clase que expuso el Terraform MCP Server CVE-2026-16496) y trata "agente con un token hacia un sistema denso en credenciales" como una clase de riesgo distinta en el control de inventario — porque en el caso de DIVD, toda la cadena de escalada empezó en uno.

Actualización — 2026-10-04: aislamiento de base de datos por agente como control de capa de almacenamiento

La checklist de endurecimiento gana un control de capa de almacenamiento que colocar junto a la contención de model-gateway y de alcance de herramientas: la base de datos por agente. Supabase recaudó 150 millones de dólares y adquirió Turso para el aprovisionamiento de bases de datos por agente — crecimiento del 600% en bases de datos atribuido a los agentes de IA — produciendo a escala lo que la sección de exfiltración de datos de esta checklist trata como una suposición. Con una base de datos por agente, el movimiento lateral entre los planos de datos de los agentes falla en la capa de credenciales en lugar de en la capa de red, y la pregunta de auditoría ("¿qué agente escribió esta fila?") se resuelve por construcción. El trade es la consistencia entre agentes: los joins y los datos de referencia compartidos suben a la capa de orquestación.

Actualización — 2026-10-04: las suscripciones de MCP Events son credenciales — y la revocación es asimétrica

La sección de gestión de credenciales de la checklist tiene una nueva clase de objeto que gobernar: las suscripciones de MCP Events. El mecanismo de OpenAI añade suscripciones de eventos con webhook firmado a los servidores MCP — events/subscribe crea una suscripción con modo de entrega, URL de callback, secreto de firma HMAC y cursor. El encuadre de WorkOS es el operativo: la suscripción es en sí misma una credencial, y necesita revocación, rotación y control de acceso como cualquier otra. La parte asimétrica va en la checklist explícitamente: ChatGPT soporta el modo de entrega webhook pero no el sobre terminated, así que una suscripción "revocada" puede seguir disparando hasta su TTL — verifica el modo de entrega que tu plataforma de agentes honra antes de tratar la revocación como instantánea.

Actualización — 2026-10-04: los bypasses de sandbox de CrewAI — la primera familia de CVE de un framework open-source desde Semantic Kernel

La tesis de módulos gobernados se extiende este ciclo a los frameworks de agentes open-source: CrewAI absorbió cinco CVEs — encabezados por CVE-2026-37008, un RCE de bypass de sandbox de Python vía manipulación del grafo de objetos, más CVE-2026-2275 (RCE de CodeInterpreter, sandbox Docker y fallback SandboxPython), CVE-2026-2285 (SSRF), CVE-2026-2286 y CVE-2026-2287 (lectura de archivos locales) — bajo el advisory de CERT/CC VU#221883. La remediación de CrewAI es la señal: la CodeInterpreterTool fue eliminada por completo y allow_code_execution quedó deprecado. La cadena de fallback de SandboxPython — recurrir a Docker y caer de vuelta a la ejecución local insegura — es el mismo patrón de valores predeterminados inseguros que el hallazgo de la clave de administrador predeterminada de LiteLLM, ahora en la capa de framework: el ítem de sandbox de la checklist debe verificar que el fallback termina en rechazo, no en degradación.

Actualización — 2026-10-04: el fallback inseguro de SandboxPython es el patrón Deadbugz en la capa de framework

La tesis de compuerta de runtime de este artículo tiene ahora un datapoint de framework open-source: la familia de cinco CVEs de CrewAI (CERT/CC VU#221883) incluye CVE-2026-37008, un RCE de bypass de sandbox de Python vía manipulación del grafo de objetos, y — el emparejamiento de patrón — la cadena de fallback de CVE-2026-2275, donde un fallo del sandbox alojado en Docker degradó a ejecución local insegura en lugar de rechazar. La compuerta de runtime existe precisamente porque el sustrato de ejecución no puede confiarse a su propia palabra; un sandbox cuyo modo de fallo es "ejecútalo localmente en su lugar" reintroduce el runtime sin compuerta a espaldas de la compuerta. La propia remediación de CrewAI — eliminar CodeInterpreterTool por completo y deprecar allow_code_execution — es la confirmación del proveedor de que el fallback, no solo el bypass, era el defecto.

  • Acotamiento de autenticación de Agent-SDK (precedente CVE-2026-104873). Las superficies de autenticación de los SDK de frameworks son ahora una clase de vulnerabilidad recurrente — la familia de sandbox de CrewAI y el CVE-2026-104873 de langgraph-sdk de LangGraph (corregido en 0.4.4) aterrizaron en la misma semana. El defecto de LangGraph permitía que los handlers de autenticación acotados a acciones se aplicaran universalmente, así que un usuario autenticado podía alcanzar los threads de otro usuario. Ítem de checklist: verifica el aislamiento por usuario en la capa de thread/sesión de forma independiente a los valores predeterminados de los handlers de autenticación del framework, y fija las versiones del SDK que llevan la corrección del acotamiento.

Actualización — 2026-10-06: tres nuevas clases de CVE de MCP entran en el checklist — lectura de archivos en Confluence, exposición de tokens en ArcadeDB, SSRF en Facebook Ads

El inventario de CVEs de MCP que rastrea este checklist gana tres superficies de ataque a nivel de herramienta (bonfy.ai, MCP Security Statistics 2026): CVE-2026-73498 (Atlassian Confluence MCP) — confluence_upload_attachment pasó rutas de archivo suministradas por el cliente directamente a llamadas de apertura de archivo sin validación, habilitando la lectura arbitraria de archivos a través del parámetro de ruta de la herramienta; CVE-2026-67357 (ArcadeDB MCP) — la herramienta de configuración expuso el token del clúster HA en texto claro, suficiente para suplantar a root mediante cabeceras específicas de solicitud — una nueva subclase: fuga de secretos vía respuesta de la herramienta; CVE-2026-19956 (servidor MCP de Facebook Ads) — SSRF en la función de paginación; quien llama de forma remota y autenticada dirige solicitudes desde la posición de red del servidor. La traducción al checklist: añadir validación de rutas para cada herramienta que toque archivos (el servidor valida, nunca el cliente), auditar las respuestas de las herramientas en busca de fugas de secretos — no solo las llamadas en busca de inyecciones — y acotar la salida de red del módulo para que un SSRF dentro de un conector no pivote hacia endpoints internos de metadatos. Cada una se mapea a una familia de controles existente (validación de entrada, auditoría de respuestas, aislamiento de red) — que es el propio argumento del checklist: las clases cambian cada semana, las familias de controles no.

Actualización — 2026-10-11: AgentCorruption — la superficie de credenciales IMDS llega a la plataforma gestionada de agentes

La divulgación de AgentCorruption de Zenity Labs (8 de octubre de 2026, SecTor Toronto) es la clase de exposición de credenciales para la que existen los controles de runtime de este checklist, documentada en una plataforma gestionada de agentes. Un solo prompt a un agente público de Amazon Bedrock AgentCore dirigió una herramienta con capacidad HTTP a 169.254.169.254, y el Instance Metadata Service devolvió las credenciales temporales del rol de ejecución predeterminado del agente — un rol cuyo alcance no era ese agente, sino todos los agentes AgentCore de la misma cuenta y región de AWS. La cadena que siguió fue IAM puro: DescribeLogGroups enumeró cada ID de agente, InvokeAgentRuntime alcanzó agentes internos a los que el usuario nunca estuvo autorizado a tocar, ListEvents leyó todas las conversaciones privadas, GetSecretValue extrajo claves de API y tokens OAuth, y un permiso de escritura en memoria entre agentes plantó cambios de comportamiento persistentes que sobrevivieron a la sesión. Es la misma clase de credenciales que el artículo del KEV de LiteLLM documentó en la capa de gateway — el enrutamiento pass-through que convierte un límite débil en compromiso de toda la cuenta en la nube — llegando ahora a la capa de plataforma, donde el propio valor por defecto de la plataforma suministró las credenciales sobreprivilegiadas. La traducción al checklist para la familia de controles de runtime: bloquear los endpoints de metadatos link-local (169.254.169.254) en toda ruta de egreso de módulo, leer la política del rol de ejecución permiso a permiso antes de que el agente entre en producción, y verificar que el rol no puede listar, invocar, leer ni escribir recursos de otros agentes de la cuenta. AWS endureció el rol predeterminado el 29 de septiembre de 2026 — 278 días después de la divulgación inicial — y esa es la segunda lección: la ventana entre lo reportado y lo corregido pertenece al cliente, en cualquier plataforma gestionada. El análisis completo del incidente está en el artículo de AgentCorruption.

Actualización — 2026-10-20: Splunk CVE-2026-76286 — la URL configurada en la herramienta es ella misma un límite de confianza

Splunk divulgó CVE-2026-76286 en su propio MCP Server el 7 de octubre de 2026 (CWE-918, CVSS 5.3, corregido en 1.2.1) — un SSRF que envía el token de plataforma del usuario en ejecución a la URL configurada en una herramienta de API personalizada (advisory). La pieza se suma al registro (la clase CVSS 10.0 de CVE-2026-16496, el SSRF de Spring AI CVE-2026-45609 y los dos listados en KEV) con una lección de control distinta: la URL configurada en una herramienta es ella misma un límite de confianza. Fija y valida las URLs configuradas, no aceptes nunca URLs crudas aportadas por usuarios en la configuración de herramientas, y trata cada petición externa que una herramienta realice como portadora de las credenciales propias del servidor.

Lecturas relacionadas

Un build representativo: un distribuidor de mid-market desplegando un módulo MCP que lee un catálogo de NetSuite, genera cotizaciones, mantiene disponibilidad de inventario y escribe la orden aceptada de vuelta al ERP. Los controles 1–4 (migración SSE, aislamiento de red, OAuth, identidad del agente) son la arquitectura. Los controles 5–8 (escaneo de tool poisoning, proveniencia firmada, endurecimiento STDIO, rate limiting) son la capa de cadena de suministro y runtime. Los controles 9–12 (frontera de contexto, kill switch, logging de auditoría, detección shadow) son la capa operacional que determina si el módulo corre por una semana o por un año. La fase Discovery de una semana produce el inventario de sistemas y mapa de flujo que hace cada control verificable antes de que el módulo toque tráfico de producción.

Discovery de una semana. Obtienes un inventario de sistemas, mapa de flujo y alcance fijo — ya construyas con nosotros o no.

¿Quieres esto construido para tus sistemas?

Cada documento aquí viene de trabajo real de producción. Si tienes un sistema objetivo y un flujo en mente, podemos definir un proyecto en una semana.

Solicitar un proyecto

Descubrimiento de una semana. Obtienes un inventario de sistemas, mapa de flujos y alcance fijo — decidas o no construir con nosotros.