Estándar de código de módulos MCP

Actualización — 2026-08-18: CoSAI token-exchange, MCP Project sandboxing baseline, OWASP GenAI baseline, bugs Ruby SDK — el patrón de autorización y la baseline de despliegue

Cuatro desarrollos proporcionan el patrón de autorización y la baseline de despliegue que este estándar de código necesitaba.

1. CoSAI token-exchange (18 de agosto) — el patrón de autorización. Cada módulo MCP debe intercambiar un token en el límite de confianza, no mantener credenciales persistentes. El token expira en minutos con revocación instantánea.

2. MCP Project Sandboxing Baseline (16 de agosto) — la baseline de despliegue. Cada despliegue de módulo MCP debe incluir sandboxing a nivel OS (Landlock/Seatbelt/Windows ACL).

3. OWASP GenAI MCP Server Security Baseline (18 de agosto) — la referencia de desarrollo. La estructura de directorios, registro de herramientas y manejo de errores de este estándar se mapean a los controles de desarrollo de OWASP GenAI.

4. Bugs MCP Ruby SDK (16 de agosto) — nuevas clases CVE confirman la postura defensiva. El DoS del Ruby SDK extiende el requisito de rate limiting; el directory traversal extiende el requisito de validación de input. Véase el MCP Security Hardening Checklist.

Actualización — 2026-08-15: DeepSeek Harness — "todo es un plugin" valida el patrón de módulos

DeepSeek liberó el DeepSeek Harness el 13-14 de agosto, 2026 — un runtime MIT construido sobre el meta-framework Cordis. Principio: "todo es un plugin." Modelos, herramientas, skills, sesiones, sandboxes, filesystems, loops, orquestación y UI son todos plugins intercambiables con "ningún núcleo privilegiado a parchear." 33,000+ estrellas en GitHub en horas. La validación de industria más fuerte del patrón plugin/módulo que este estándar describe.

Por qué importa un estándar de código

Cada conector que entregamos se ve igual. Eso no es un accidente — es una disciplina. Cuando llega una segunda integración, las capacidades del agente son más fáciles de probar, auditar e intercambiar porque cada módulo MCP sigue la misma estructura, nomenclatura y contrato de errores.

Este documento define el estándar para todos los módulos MCP en la columna vertebral de orquestación de IdeaBosque. Cubre el diseño de directorios, el registro de herramientas, los esquemas de entrada/salida, el manejo de errores, los límites de tasa, el registro de auditoría y el manejo de PII en la frontera.

Estructura de directorios

Cada módulo MCP vive en su propio directorio bajo app/mcp_modules/ con un diseño consistente:

app/mcp_modules//
  __init__.py
  module.py          # Registro de herramientas + handlers
  schemas.py         # Modelos Pydantic de entrada/salida
  tests/
    test_module.py
  README.md

Registro de herramientas

Cada módulo registra sus herramientas a través de una interfaz estándar. La columna vertebral de orquestación descubre las herramientas escaneando el punto de entrada register_tools() — sin cableado manual.

def register_tools(registrar):
    """Registrar todas las herramientas proporcionadas por este módulo."""
    registrar.tool(
        name="search_catalog",
        description="Buscar catálogo de proveedores por SKU o nombre",
        input_schema=SearchCatalogInput,
        output_schema=SearchCatalogOutput,
        rate_limit=120,  # llamadas por minuto
    )

Manejo de errores

Los módulos deben lanzar excepciones tipadas, no strings sueltos. La columna vertebral captura subclases de MCPToolError y las convierte en respuestas estructuradas que el agente puede razonar:

• MCPAuthError — credenciales faltantes o expiradas
• MCPRateLimitError — límite de tasa del upstream alcanzado
• MCPTimeoutError — la llamada al upstream excedió el timeout configurado
• MCPValidationError — la entrada no pasó la validación del esquema
• MCPUpstreamError — el upstream devolvió un estado de error

Límites de tasa

Cada herramienta declara su propio límite de tasa en la llamada de registro. La columna vertebral los aplica por agente, por herramienta y por ventana. Cuando se alcanza un límite, el agente recibe una respuesta 429 con un header Retry-After — no se cuelga ni reintenta a ciegas.

Registro de auditoría

Cada llamada a herramientas se registra con: timestamp, ID del agente, nombre de la herramienta, hash de entrada (no entrada raw — frontera de PII), estado de salida, duración y sistema upstream. Los logs se escriben en JSON estructurado y se envían al pipeline de observabilidad.

"Cada llamada a herramientas se registra y es auditable" no es una característica que agregamos después. Es lo primero que el estándar exige.

Manejo de PII en la frontera

Los módulos deben declarar qué campos de entrada contienen PII. La columna vertebral hashea estos campos antes de registrarlos y nunca envía PII raw al pipeline de auditoría. Los campos PII se marcan en el esquema:

class SearchCatalogInput(BaseModel):
    sku: str
    customer_name: str = Field(..., pii=True)
    region: str

Cuando pii=True está activo, el logger de auditoría reemplaza el valor con un hash SHA-256. El handler de la herramienta sigue recibiendo el valor raw — el manejo de PII se aplica en la frontera de logging, no dentro de la lógica de negocio.

Actualización — 2026-08-06: Seguridad del modo de transporte — la superficie de ataque stateful streamable-HTTP

CVE-2026-16496 (CVSS 10.0, parcheado en Terraform MCP Server el 5 de agosto de 2026) es el primer CVE de severidad máxima en el ecosistema MCP y la primera evidencia de producción de que el modo de transporte es una dimensión de seguridad, no solo operativa. La vulnerabilidad es un bypass de autorización por session-hijacking en el modo de transporte stateful streamable-HTTP: un usuario que obtiene el session ID de MCP de otro usuario puede tener sus llamadas de herramientas ejecutadas usando las credenciales de Terraform de ese usuario. HashiCorp también parcheó CVE-2026-16498 (ruptura de aislamiento de tenant) y CVE-2026-14869 (SSRF) en la misma versión. (The Hacker News, SentinelOne vulnerability database)

Esto añade una regla de seguridad del modo de transporte al estándar de endurecimiento de despliegue:

5. Preferir transporte stateless; tratar stateful streamable-HTTP como un riesgo de seguridad. La especificación MCP 2026-07-28 se movió a un núcleo de protocolo stateless — el handshake initialize/initialized y el header Mcp-Session-Id se eliminan, y los flujos de trabajo con estado usan handles explícitos en lugar de sesiones del lado del servidor. El diseño stateless elimina la clase de ataque de session-hijacking a nivel de arquitectura: un servidor stateless no tiene sesión que robar. El modo de transporte stateful streamable-HTTP que CVE-2026-16496 explota es el modo que el núcleo stateless está diseñado para reemplazar. Si un módulo debe ejecutar stateful streamable-HTTP (por compatibilidad con un cliente que no ha migrado), tratarlo como una configuración conocida como vulnerable: vincularlo a una red privada, requerir autenticación en cada sesión y planificar la migración a transporte stateless en el mismo reloj de 12 meses que la deprecación de SSE. Un módulo que expone stateful streamable-HTTP en una interfaz pública sin autenticación está en la misma clase de riesgo que los 1.467 servidores que Trend Micro encontró sin autenticación — más el vector de session-hijacking.

Las reglas de endurecimiento de STDIO abordan vulnerabilidades a nivel de código. Una dimensión de exposición separada surgió en julio de 2026, y aterrizó en la propia implementación de referencia. Entre el 11 y el 21 de julio de 2026, tres CVEs se presentaron contra el MCP Python SDK oficial — la implementación de referencia de la que hereda todo servidor MCP en Python:

• CVE-2026-59950 — validación de Host/Origin ausente. Una página web que la víctima visita puede dirigir su servidor MCP local mediante DNS rebinding y CSRF. El navegador se convierte en el proxy del atacante hacia un servidor loopback que el operador creía privado.
• CVE-2026-52869 — solicitudes de sesión no verificadas. El transporte HTTP sirve solicitudes de sesión sin verificar la sesión, permitiendo acceso no autenticado.
• CVE-2026-52870 — manejadores de tareas abiertos. Los manejadores de tareas experimentales permiten que cualquier cliente alcance la tarea de otro cliente.

CVEs adicionales afectaron servidores populares en la misma quincena: meta-ads-mcp (CVE-2026-54547 / -54549, reutilización de auth-token + SSRF), LangBot (CVE-2026-54449, RCE autenticado), ToolHive (CVE-2026-58196, SSRF), y mcp-atlassian (GHSA-g5r6-gv6m-f5jv, lectura arbitraria de archivos). El patrón es a nivel de categoría, no aislado: MCP fue diseñado para loopback en localhost, los equipos lo desplegaron en internet, y se omitieron los fundamentos de seguridad — autenticación, validación de origen, comprobación de entradas. Que la implementación de referencia envíe la misma clase de fallo que los servidores comunitarios es la evidencia de endurecimiento de despliegue que este estándar aborda: las reglas de autenticación y validación de origen a continuación no son aspiracionales — cierran la causa raíz detrás de CVE-2026-59950 y CVE-2026-52869.

El escaneo de seguimiento corregido de Trend Micro encontró 1,467 servidores MCP públicamente accesibles sin autenticación ni cifrado — casi triplicado desde los 492 iniciales, no los "~2,000" citados previamente. La escalada no es solo el recuento: 1,227 de los 1,467 están ejecutando el transporte SSE obsoleto (la población más afectada tanto por la migración de la especificación del 28 de julio como por la exposición de seguridad), la herramienta execute_sql aparece en 70 hosts, "Graphiti Agent Memory" (un servidor MCP agentic) está en 39 hosts — un objetivo principal para exfiltrar datos residentes en memoria — y al menos tres servidores exponen historiales clínicos de pacientes mediante una herramienta "progress_note". La amenaza se amplió desde configuraciones STDIO locales hasta servidores MCP desplegados en la nube alcanzables desde internet. Muchos de estos servidores expusieron credenciales codificadas, endpoints de herramientas y acceso al sistema a cualquiera que pudiera alcanzar el puerto.

BlueRock Security: 36.7% de m\u00e1s de 7,000 servidores MCP vulnerables a SSRF. BlueRock Security analiz\u00f3 m\u00e1s de 7,000 servidores MCP y encontr\u00f3 que el 36.7% eran potencialmente vulnerables a Server-Side Request Forgery \u2014 un corpus m\u00e1s grande que el escaneo de 1,467 servidores expuestos de Trend Micro, y una clase de vulnerabilidad diferente. SSRF permite a un atacante coercionar a un servidor MCP para que haga solicitudes a recursos de la red interna que el servidor puede alcanzar pero el atacante no \u2014 endpoints de metadatos en la nube, APIs internas, bases de datos. El 36.7% es la nueva estad\u00edstica agregada de vulnerabilidad: m\u00e1s de uno de cada tres servidores MCP puede ser enga\u00f1ado para explorar la red interna. Para despliegues B2B, el riesgo SSRF es agudo porque los servidores MCP t\u00edpicamente tienen acceso a sistemas internos (ERP, CRM, bases de datos de inventario) \u2014 un servidor que obtiene un cat\u00e1logo de proveedores puede ser redirigido para obtener el endpoint de metadatos en la nube y filtrar credenciales.

Tres CVEs adicionales surgieron en la oleada de julio de 2026, expandiendo la l\u00ednea de tiempo de CVEs m\u00e1s all\u00e1 de las vulnerabilidades oficiales del SDK:

• CVE-2025-68143 \u2014 path traversal. Un servidor MCP permite acceso a archivos fuera del directorio previsto mediante argumentos de ruta manipulados, enabling lectura arbitraria de archivos en el host del agente.
• CVE-2025-68144 \u2014 inyecci\u00f3n de argumentos. Una herramienta que acepta argumentos de l\u00ednea de comandos puede ser coercionada para ejecutar flags adicionales que el operador no pretend\u00eda, similar al patr\u00f3n de bypass de allowlist STDIO documentado en el est\u00e1ndar de cuatro reglas de OX Security arriba.
• CVE-2025-68145 \u2014 bypass de scoping de repositorio. Un servidor que deber\u00eda estar limitado a un \u00fanico repositorio puede acceder a repositorios fuera de su alcance declarado, exponiendo c\u00f3digo privado y secretos.

cyberdesserts.com confirm\u00f3 que la revisi\u00f3n del protocolo del 28 de julio de 2026 no cierra la brecha del modelo de autorizaci\u00f3n \u2014 la vulnerabilidad estructural que permite a una descripci\u00f3n de herramienta comprometida o salida secuestrar el comportamiento del agente persiste en la especificaci\u00f3n final. El redise\u00f1o stateless mejora la eficiencia operativa pero no aborda MCP03 (tool poisoning), MCP06 (intent flow subversion), o MCP10 (context over-sharing). La capa de gobernanza sigue siendo responsabilidad del operador \u2014 y este est\u00e1ndar es el contrato de implementaci\u00f3n de esa responsabilidad.

Notas de migraci\u00f3n de la spec final (28 de julio de 2026). La especificaci\u00f3n MCP 2026-07-28 se public\u00f3 como final con una pol\u00edtica de deprecaci\u00f3n de SSE de 12 meses: el transporte SSE est\u00e1 deprecado y debe migrarse al transporte Streamable HTTP dentro de 12 meses. Los cuatro SDKs Tier 1 (Python, TypeScript, Java, Kotlin) han publicado versiones compatibles. Los m\u00f3dulos que usan transporte SSE deben migrarse; los m\u00f3dulos que usan STDIO no se ven afectados. La migraci\u00f3n es un cambio de capa de transporte \u2014 las reglas de registro de herramientas, manejo de errores, l\u00edmites de tasa y logging de auditor\u00eda en este est\u00e1ndar son agn\u00f3sticas al transporte. El contrato del m\u00f3dulo no cambia; solo lo hace el binding de transporte.

Las reglas de endurecimiento de despliegue:

1. Nunca exponga un servidor MCP en una interfaz pública sin autenticación. Cada servidor MCP — ya sea transporte STDIO, SSE o HTTP — debe requerir autenticación (OAuth 2.1 con PKCE, API key o mTLS). Un servidor alcanzable en 0.0.0.0:3000 sin autenticación es una superficie de ejecución remota de código, no una conveniencia de desarrollo.

2. Vincule a localhost o una red privada. Los servidores MCP de producción se vinculan a 127.0.0.1 o una subred privada. Si se requiere acceso externo, enrute a través de un proxy inverso con autenticación, límites de tasa y terminación TLS — no exposición directa del puerto.

3. Nunca codifique credenciales en archivos de configuración MCP. El escaneo de Trend Micro encontró API keys, contraseñas de bases de datos y secretos de OAuth codificados en configuraciones de servidores MCP de acceso público. Las credenciales deben provenir de variables de entorno o un gestor de secretos — nunca de un archivo JSON que un atacante pueda leer.

4. Cifre todo el transporte. STDIO es local por definición, pero los transportes SSE y HTTP deben usar TLS. Un servidor MCP HTTP en texto plano en una red pública expone cada llamada a herramientas — incluidos los tokens de autenticación y PII — a la interceptación a nivel de red.

El escaneo de Trend Micro es el complemento del lado del despliegue al aviso de OX Security: las vulnerabilidades a nivel de código (STDIO no sanitizado, omisiones de allowlist, inyección de configuración) se vuelven explotables remotamente cuando el servidor mismo está expuesto sin autenticación. El endurecimiento de código sin endurecimiento de despliegue es una puerta cerrada en un porche abierto.

Actualización — 2026-08-07: Descubribilidad y gobernanza de servidores MCP — la dimensión de productos de Black Hat 2026

El inventario completo de productos de Black Hat 2026 (crn.com, 4 de agosto de 2026) añade una nueva dimensión al estándar de código MCP: la descubribilidad y gobernanza de servidores MCP. Tres productos lanzados en Black Hat USA 2026 abordan directamente la brecha entre el estándar de código (que gobierna cómo se escribe un módulo) y la realidad del despliegue (que gobierna cuántos módulos existen y quién los conoce).

1. Cyera Agent Guardian — descubrimiento de servidores MCP en la sombra. El estándar de código asume que cada módulo MCP está registrado, documentado y sigue la estructura de directorio y el contrato de error. El producto de Cyera revela la brecha: existen servidores MCP en la sombra que no siguen el estándar de código en la mayoría de las empresas — instalados por desarrolladores individuales, heredados de adquisiciones, o desplegados como pruebas de concepto que nunca fueron retirados. El estándar de código gobierna módulos sancionados; Cyera descubre los no sancionados.

2. SailPoint Identity Security — ciclo de vida de identidad de servidores MCP. El estándar de código gobierna cómo se autentica un módulo. El producto de SailPoint añade la dimensión de ciclo de vida: cada servidor MCP tiene una identidad que debe ser aprovisionada, atestada y revocable a través de un flujo de gobernanza de identidad. Un módulo que codifica credenciales no puede ser gobernado a través del ciclo de vida de identidad; un módulo que usa OAuth 2.1 con credenciales gestionadas sí puede.

3. Check Point AI Network Firewall — monitoreo de comunicaciones MCP en la capa de red. El estándar de código gobierna lo que un módulo registra en la capa de aplicación. El producto de Check Point añade la dimensión de capa de red: el canal de comunicación MCP es ahora monitoreable a nivel de red. Un módulo que no registra sus llamadas a herramientas en la capa de aplicación aún puede ser monitoreado en la capa de red, pero un módulo que registra en ambas capas es el que produce una pista de auditoría completa.

Los productos de descubrimiento de servidores MCP de Black Hat 2026 añaden una dimensión de "descubribilidad y gobernanza" al estándar de código: un módulo que sigue la estructura de directorio, el contrato de error y las reglas de seguridad es un módulo bien escrito, pero un módulo que también está registrado en una plataforma de gobernanza de identidad (SailPoint), descubrible por una herramienta de detección de servidores en la sombra (Cyera) y monitoreado en la capa de red (Check Point) es un módulo bien gobernado. El estándar de código es la base; los productos de Black Hat 2026 son la capa de gobernanza encima.

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.