La NSA AISC publica una guía de seguridad para MCP en entornos de IA

¿De qué se trata?

El 20 de mayo de 2026, el Artificial Intelligence Security Center (AISC) de la National Security Agency publicó una Cybersecurity Information Sheet (CSI) de 15 páginas titulada Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation (referencia U/OO/6030316-26 / PP-26-1834). El comunicado de prensa presenta el documento como la base mínima de seguridad que la NSA recomienda aplicar antes de poner en marcha un despliegue de MCP en producción o en entornos de alto impacto.

La CSI no es un aviso de vulnerabilidad ni la divulgación de un ataque inédito. Es el primer documento formal de postura del gobierno estadounidense centrado específicamente en MCP, el protocolo de nivel de aplicación que popularizó Anthropic en noviembre de 2024 y que hoy está integrado en productos como AutoGen Studio, Harvey AI, Agentverse o Microsoft Copilot. La formulación de la NSA es directa: «la proliferación rápida de MCP ha superado el desarrollo de su modelo de seguridad», y quienes lo adopten deben tratar las implementaciones actuales como la industria trató los primeros protocolos web: potentes, útiles y peligrosos sin defensa en profundidad.

Cómo funciona

La CSI se organiza en tres bloques: una lista de clases de debilidades de diseño e implementación, un conjunto de incidentes reales que demuestran que cada clase no es teórica, y un conjunto de recomendaciones dirigidas a operadores y no a autores de la especificación.

Ocho clases de debilidades identificadas por la NSA.

#  Clase                                Qué falla
-- ------------------------------------ -------------------------------------------------
1  Control de acceso                    El vínculo sesión-identidad es opcional;
                                        muchos servidores omiten la autenticación;
                                        no hay RBAC nativo ni granularidad CRUD
2  Serialización insegura de            Los payloads serializados pueden incluir
   contexto/datos                       código ejecutable o llamadas al modelo; la
                                        deserialización permisiva recuerda OWASP A08
3  Flujos de aprobación débiles         Los cambios de capacidad o de acceso en un
                                        servidor MCP ya aprobado suelen saltarse el
                                        re-consentimiento del usuario
4  Seguridad de tokens y sesiones       Bearer tokens estilo OAuth, pero el ciclo de
                                        vida (refresh, revocación, replay) no es
                                        obligatorio; la idempotencia queda en JSON-RPC
5  Configuraciones erróneas             Un servidor «meteo» reutilizado contra datos
                                        sensibles; sin aislamiento entre tareas y
                                        datos que comparten la misma interfaz
6  Comportamientos inconsistentes       Distintas implementaciones interpretan el
                                        mismo contexto de modo distinto; el
                                        no determinismo se vuelve una primitiva
7  Logs de auditoría pobres o ausentes  La spec solo aporta guía básica; muchos
                                        servidores no registran nada o solo
                                        metadatos operacionales
8  DoS y técnicas de fatiga             Tormentas de prompts, entradas malformadas,
                                        recursión; ataques de «letargia» con peticiones
                                        legítimas pero excesivamente complejas

Cinco incidentes reales que la NSA cita como ilustración — todos divulgados públicamente por sus autores y referenciados en la bibliografía de la CSI:

• Inyección de parámetros de herramienta en agentes MCP open source, donde parámetros sin sanear llegan al entorno de ejecución a través de mensajes malformados — HiddenLayer, 2025.
• Confusión en la ruta de invocación de herramientas cuando los orquestadores resuelven nombres desde registros públicos o módulos locales, permitiendo cargar código del atacante por colisión de nombres — Zhao et al. arXiv 2509.06572.
• Acceso ilimitado al GitHub MCP, donde permisos de repositorio en blanco permiten a una herramienta comprometida exfiltrar contenido de repositorios privados a repositorios públicos — Invariant Labs, 2025.
• Exfiltración de WhatsApp vía MCP, donde un servidor malicioso instalado junto a uno de confianza utiliza descripciones de herramientas «benignas y luego maliciosas» para volcar el historial de mensajes — Invariant Labs, 2025.
• CVE-2025-49596 en MCP-Inspector, una RCE por entradas no verificadas corregida en la versión 0.14.1 — Oligo, 2025.

No se reproduce código de exploit ni en la CSI ni aquí. El encuadre novedoso —y la razón por la que este documento importa— está en la observación de la NSA: MCP invierte un patrón cliente/servidor familiar: en vez de que el cliente pida datos al servidor, MCP a menudo espera que el servidor consulte y ejecute acciones por el cliente conectado. Esa inversión desplaza la frontera de confianza hacia una dirección que la mayoría de las pilas de detección y DLP existentes no fueron diseñadas para cubrir.

Por qué importa

Tres cambios justifican la lectura, incluso para quien haya seguido todos los incidentes MCP del año.

Primero, la autoridad de la fuente. La cobertura reciente sobre MCP venía de proveedores de seguridad, grupos académicos y nuestras propias notas sobre el patrón de vulnerabilidades de backend MCP y el RCE de stdio-transport-by-design. Que la NSA AISC entre en la conversación traslada la seguridad MCP del registro «área de investigación interesante» al de «materia de guía federal de ciberseguridad». Para organizaciones sujetas al NIST AI RMF, la CSI pasa a ser parte de la documentación que un auditor puede exigir.

Segundo, el encuadre del riesgo MCP como sistémico, no como problema de endpoint. La CSI es explícita: «estos problemas no pueden parchearse a nivel de interfaz o endpoint». Asegurar MCP, según la NSA, requiere tratar el entorno agéntico como un continuo en el que las suposiciones del protocolo, del agente, de las herramientas, del esquema de clasificación de datos y del pipeline de auditoría tienen que alinearse. Ese vocabulario importa porque empuja en contra del reflejo natural de «parchear el servidor» o «añadir un guardarraíl» y dar por cerrado el tema.

Tercero, el alineamiento con el esfuerzo aliado más amplio. La CSI cita el documento Careful Adoption of Agentic AI Services del Australian Signals Directorate (cubierto en nuestro artículo sobre la guía CISA Five Eyes) y el trabajo del OASIS Coalition for Secure AI sobre el control de alcance en MCP. La postura Five Eyes sobre IA agéntica converge, y MCP es explícitamente un sujeto de esa convergencia.

Defensas

Las nueve recomendaciones de la NSA son operativas; lo que sigue es una traducción orientada a «qué puede hacer un defensor esta semana». Ninguna requiere acceso al nivel NSA — todos los controles son implementables con herramientas existentes.

1. Inventaríe y elija servidores mantenidos. Muchos servidores MCP populares están ya archivados (lista servers-archived). Construya un registro de todos los servidores MCP en producción, mapéelos al repo aguas arriba y marque para reemplazo todo lo no mantenido. Para proyectos internos, inscríbalos en el MCP Registry preview para que el descubrimiento no funcione a ciegas.

2. Diseñe pensando en fronteras de confianza. Agentes, plugins, modelos y usuarios finales viven en zonas de confianza distintas. Alinee herramientas con la clasificación del dato: herramientas públicas para datos públicos; herramientas sensibles explícitamente segregadas. Prefiera servidores MCP locales cuando haya datos privados en juego, y coloque un proxy de salida con filtrado (Squid, tinyproxy) o una DLP delante de cualquier servidor que pueda contactar a internet.

3. Valide los parámetros en su contexto, no solo en su forma. La validación de esquema es necesaria pero no suficiente. El ejemplo de la NSA —un agente intérprete matemático en el que un parámetro context desencadena entrada/salida de archivo no prevista— captura el problema: valide las entradas contra el entorno de ejecución, no solo contra el tipo. Bloquee el reenvío de parámetros cuando la fuente sea ambigua.

4. Aísle cada ejecución de herramienta en un sandbox. Trate cada herramienta invocada vía MCP como potencialmente de alto riesgo. Use aislamiento a nivel del SO (AppContainer en Windows, seccomp / AppArmor / SELinux en Linux). Aplique el menor privilegio al proceso del agente: si un servidor no necesita acceso al sistema de archivos ni a la red interna, deniegue esos caminos en tiempo de ejecución.

5. Firme los mensajes MCP; no asuma confianza en el transporte. TLS protege el canal, pero el protocolo no impone integridad del payload. Añada firmas criptográficas dentro del JSON, con marcas de tiempo de expiración y metadatos antirreplay. OWASP ASVS V7 (Session Management) aplica directamente.

6. Trate cada salida de herramienta como entrada no confiable de la siguiente etapa. El filtrado de salida debe ejecutarse entre cada herramienta de un pipeline multi-componente, con comprobaciones de longitud, escaneo de palabras prohibidas, rate-limits, y detección de inyección de prompt indirecta o pivot vía toolchain. Los descriptores comprometidos y las instrucciones ocultas en las salidas son el canal por el que el tool poisoning y los toxic flows se propagan por agentes encadenados.

7. Registre todo, envíelo al SIEM. Capture parámetros exactos, identidades y —cuando sea posible— hashes criptográficos de las salidas para cada invocación de herramienta y modelo. Sin ello, la respuesta a incidente se convierte en arqueología. La CSI es explícita: las carencias de auditoría están entre los fallos de implementación más frecuentes.

8. Siga los CVE de MCP como una línea de trabajo aparte. Las nuevas vulnerabilidades específicas de MCP llegan al feed CVE mensualmente. Suscríbase a los canales pertinentes, mantenga un inventario versionado de cada agente y herramienta MCP desplegado, y trate los parches MCP con el mismo SLA que las bibliotecas de autenticación o de criptografía.

9. Escanee su red en busca de servidores MCP desconocidos. Use escáneres como MCP Scanner, Ramparts, CyberMCP o Proximity para detectar servidores sin autenticación, despliegues con versiones no aprobadas e instancias con rutas de tráfico abiertas. Los servidores MCP pueden cambiar de puerto dinámicamente; los escaneos diferenciales son la cadencia adecuada.

Una décima útil, implícita en el énfasis de la CSI en la aprobación continua: reapruebe cuando cambie la capacidad. Un servidor de confianza que añade discretamente una nueva descripción de herramienta o un nuevo scope tras la instalación encaja con el patrón del incidente de WhatsApp. Trate los deltas de capacidad como trata los deltas de código.

Estado

Elemento	Referencia	Fecha	Notas
Comunicado de la NSA AISC	NSA	2026-05-20	Anuncia la publicación de la CSI
CSI (PDF)	NSA	2026-05-20	U/OO/6030316-26, 15 páginas
Cobertura de Executive Gov	Executive Gov	2026-05-21	Resume riesgos de serialización, fronteras, mal uso
Cobertura de Intelligence Community News	ICN	2026-05-22	Replica el comunicado
Guía complementaria	Australian Signals Directorate / CISA	2026	Careful Adoption of Agentic AI Services (referenciada en la CSI)
OASIS COSAI WS4	CoSAI	2026	Trabajos sobre control de alcance y mal uso referenciados en la CSI
Versión de la especificación MCP citada	modelcontextprotocol.io	2025-11-25	Secciones auth, lifecycle, tools

El encuadre correcto para esta CSI no es «la NSA encontró un fallo en MCP» — no hay zero-day en el documento. Es «el centro de seguridad de IA del gobierno estadounidense ahora trata a MCP como infraestructura crítica que hay que gobernar, con una línea base publicada a la que defensores, auditores y equipos de compras pueden remitirse». Si MCP está en su stack, este documento es ahora una referencia de carga; si MCP está en su hoja de ruta, es la lectura más barata y rápida disponible antes de comprometerse.