Proxies del Model Context Protocol: Gobernando la entrada de agentes de IA

Cuando un agente de IA decide cómo ejecutar una herramienta local, los firewalls de red estándar son completamente ciegos a su intención. Descubra cómo diseñar proxies MCP que auditen y controlen las interacciones de los agentes autónomos.

---

El Punto de Inflexión Agentico

La arquitectura empresarial ha entrado en un período de rápida discontinuidad. Los Large Language Models ya no generan texto bajo demanda; orquestan flujos de trabajo de forma autónoma, consultan bases de datos de producción, modifican sistemas de archivos y activan pipelines de CI/CD. El tejido conectivo que habilita este cambio es el Model Context Protocol (MCP) de Anthropic, un estándar de código abierto introducido en noviembre de 2024 y descrito por Ars Technica como el “USB-C para IA.”

MCP abordó lo que los practicantes llevaban mucho tiempo llamando el problema de integración N×M: antes de que existiera el protocolo, conectar diez agentes con veinte herramientas internas requería doscientos puntos de integración personalizados, cada uno mantenido de forma independiente. MCP reemplazó esa dispersión con un único protocolo estandarizado basado en JSON-RPC 2.0.

El crecimiento del ecosistema desde su lanzamiento ha sido notable. Anthropic reportó más de 10,000 servidores MCP públicos activos cuando el protocolo fue donado a la Linux Foundation’s Agentic AI Foundation (AAIF) en diciembre de 2025. Para el segundo trimestre de 2026, los conteos de servidores rastreados en los cuatro principales registros públicos—PulseMCP, el Registro MCP oficial, Smithery y mcp.so—superaron aproximadamente 9,400 entradas, reflejando una tasa de crecimiento sostenida del 58% trimestre tras trimestre. El repositorio de GitHub modelcontextprotocol/servers acumuló más de 86,000 estrellas y 10,000 forks para mayo de 2026. Los SDKs en Python y TypeScript juntos alcanzaron 97 millones de descargas mensuales.

Esa trayectoria de adopción también trajo una nueva clase de exposición de seguridad que ni los diseñadores del protocolo ni los equipos empresariales que lo implementaron habían anticipado completamente.

---

La Arquitectura de Seguridad del Protocolo—Y Lo Que Omite

MCP funciona en un modelo cliente-servidor con tres roles de participantes:

Hosts/Clientes MCP son los entornos de aplicación que alojan el modelo de IA—un motor de orquestación empresarial, Claude Desktop, o un IDE potenciado por IA como Cursor o Windsurf.

Servidores MCP son envoltorios ligeros alrededor de sistemas externos—GitHub, Slack, sistemas de archivos locales, bases de datos SQL—que exponen capacidades estandarizadas.

La Capa de Protocolo transporta mensajes JSON-RPC 2.0 entre clientes y servidores a través de dos transportes principales: stdio para comunicación local proceso a proceso, y HTTP Streamable (que reemplazó al anterior transporte de Eventos Enviados por el Servidor) para conexiones remotas.

A través de MCP, un agente interactúa con tres primitivas centrales:

• Recursos (controlados por la aplicación): fuentes de datos contextuales de solo lectura, como archivos de registro o esquemas de bases de datos. Son sin efectos secundarios.
• Prompts (controlados por el usuario): plantillas reutilizables que guían la interacción del LLM con las herramientas.
• Tools (controladas por el modelo): funciones ejecutables que el agente puede invocar para realizar acciones en el mundo real—execute_sql, push_code, restart_server.

La primitiva Tools es donde se concentra la exposición de seguridad. Un servidor MCP ejecutándose en una máquina local o dentro de una subred de producción puede correr código arbitrario basado en la salida no determinista de un LLM. La seguridad de red estándar observa una conexión HTTP legítima que transporta datos JSON; no puede distinguir entre un agente consultando una tabla para un informe y un agente eliminando esa tabla por una instrucción hallucinated.

Esta brecha no es una preocupación teórica. Como afirmó el Centro de Seguridad de IA de la NSA en su Hoja de Información de Ciberseguridad de mayo de 2026 sobre MCP (U/OO/6030316-26): la rápida proliferación de MCP ha superado el desarrollo de su modelo de seguridad, al igual que los primeros protocolos web. La CSI identificó un problema estructural en el núcleo del diseño de MCP: el protocolo invierte el patrón de interacción familiar en el que los clientes solicitan datos a los servidores—MCP a menudo espera que los servidores consulten y a veces ejecuten acciones para los clientes conectados. Esta inversión crea caminos de ataque que en los despliegues iniciales eran en gran medida inrastreables.

El hallazgo específico de la NSA sobre controles básicos es importante: MCP no define cómo una sesión se mapea a una identidad verificable, la autenticación es opcional en lugar de obligatoria en la especificación base, y el control de acceso basado en roles no forma parte del protocolo a nivel de transporte. Como señala un resumen de la guía, la especificación de MCP misma reconoce que “MCP no puede hacer cumplir estos principios de seguridad a nivel de protocolo.”

---

El Panorama de Amenazas Real

Comprender contra qué debe defenderse un proxy MCP requiere una taxonomía concreta de las vulnerabilidades demostradas, explotadas o clasificadas formalmente en el mundo real.

Inyección de Prompts y Envenenamiento de Tools

OWASP sitúa la inyección de prompts en primer lugar en su Top 10 para Aplicaciones LLM (edición 2025), y la arquitectura de MCP amplifica el riesgo. El envenenamiento de Tools es una variante especializada: en lugar de inyectar contenido malicioso en entradas de usuario, los atacantes incrustan instrucciones ocultas directamente en las definiciones de las herramientas—los metadatos que indican a un agente de IA qué hace cada herramienta y cómo invocarla. Cuando un agente se conecta a un servidor MCP y solicita las herramientas disponibles vía tools/list, el servidor responde con nombres y descripciones que entran en el contexto del modelo. Un atacante que controla esos metadatos puede influir en el comportamiento del modelo en todas las sesiones donde esa herramienta se cargue, sin necesidad de interacción directa del usuario.

El blog de desarrolladores de Microsoft describió el mecanismo con precisión: instrucciones maliciosas en los metadatos de las herramientas son invisibles para los usuarios pero pueden ser interpretadas por el modelo de IA, haciendo esto especialmente peligroso en escenarios de servidores alojados donde las definiciones de herramientas pueden ser modificadas silenciosamente después de la aprobación inicial.

El benchmark MCPTox, que evaluó 20 agentes LLM prominentes contra 45 servidores MCP del mundo real usando 353 herramientas auténticas, encontró resultados alarmantes. El modelo o1-mini mostró una tasa de éxito en ataques del 72.8% contra intentos de envenenamiento de herramientas. Los modelos más capaces fueron a menudo más vulnerables porque los ataques explotan sus capacidades superiores de seguimiento de instrucciones. Claude 3.7-Sonnet tuvo la tasa de rechazo más alta de todos los modelos probados—menos del 3%.

Rug Pulls

Un rug pull agrava la amenaza del envenenamiento de herramientas. Un servidor MCP se comporta legítimamente en la instalación, pasa la revisión inicial y recibe permisos. Luego, sin notificación al cliente, sus definiciones de herramientas se actualizan silenciosamente para incluir instrucciones maliciosas. El incidente Postmark MCP de septiembre de 2025 ilustró exactamente este patrón: un actor de amenazas clonó el repositorio legítimo de Postmark MCP, publicó un paquete npm casi idéntico, mantuvo un comportamiento legítimo durante quince versiones para construir confianza, y luego introdujo una línea oculta de código que copiaba en silencio todos los correos salientes a una dirección controlada por el atacante. Los usuarios no tuvieron indicio de que algo había cambiado.

CVE-2025-54136 (CurXecute), detectado por Check Point, demostró el mismo patrón aplicado a archivos de configuración: se comprometió un archivo MCP benigno, se aprobó una vez, y luego fue intercambiado silenciosamente por un payload. Cursor confiaba en el nombre de la clave aprobada en lugar del contenido del comando, por lo que la versión maliciosa se ejecutaba en silencio en cada apertura de proyecto.

Ataques de Deputy Confundido

El servidor MCP ejecuta acciones desencadenadas por el agente pero con los permisos otorgados al servidor en sí, no necesariamente al usuario final o al agente específico que lo invoca. Sin un proxy que mapee la identidad del agente a políticas de acceso finas, el principio de menor privilegio no puede hacerse cumplir estructuralmente. Un servidor MCP comprometido puede abusar de sus privilegios elevados para acceder a sistemas que el agente original nunca pretendió acceder. OAuth 2.1 aborda parcialmente esto vinculando tokens a audiencias y ámbitos específicos—un token emitido para un servidor MCP es rechazado criptográficamente por otro—pero esto requiere una implementación correcta, que las auditorías detectan frecuentemente que falta en muchas implementaciones.

CVEs Críticos: Explotación en la Cadena de Suministro en el Mundo Real

Dos CVEs de 2025 hicieron la vulnerabilidad concreta.

CVE-2025-6514 (CVSS 9.6) fue descubierto por JFrog Security Research en julio de 2025. La vulnerabilidad residía en mcp-remote, una herramienta proxy que permitía a hosts MCP como Claude Desktop comunicarse con servidores MCP remotos. mcp-remote fue incluido en guías de integración de Cloudflare, Hugging Face y Auth0, y acumuló más de 437,000 descargas. La falla fue una inyección de comandos OS: cuando mcp-remote se conectaba a un servidor malicioso, este podía devolver una URL authorization_endpoint manipulada que se pasaba directamente al ejecutor de comandos del sistema sin validación. En Windows, esto permitía ejecutar comandos arbitrarios de PowerShell. En macOS y Linux, se podían lanzar ejecutables arbitrarios. Este fue el primer caso documentado de ejecución remota completa de código contra un cliente MCP en un escenario real. La vulnerabilidad afectó versiones 0.0.5 a 0.1.15 y fue parcheada en 0.1.16.

CVE-2025-49596 (CVSS 9.4) afectó la herramienta MCP Inspector. La interfaz interactiva lanzada por MCP Inspector vía localhost carecía de autenticación, permitiendo a un atacante cercano a la red inyectar comandos maliciosos mediante un ataque CSRF—una técnica llamada NeighborJacking. La falla fue corregida en la versión 0.14.1.

El servidor MCP Filesystem de Anthropic también tuvo dos CVEs adicionales: CVE-2025-53110 (CVSS 8.4), un bypass de enlaces simbólicos que permitía lecturas y escrituras en rutas arbitrarias del sistema de archivos; y CVE-2025-53109 (CVSS 7.3), un bypass de contención de directorios que permitía atravesar fuera del alcance del directorio aprobado.

Una auditoría de seguridad de 2026, citada en la documentación de MCP OAuth, encontró que el 25% de los servidores MCP públicos no tenían autenticación, y el 53% aún dependían de claves API estáticas de larga duración o Tokens de Acceso Personal—credenciales que, si se filtran, otorgan acceso indefinido. La CSI de la NSA coincidió en que la autenticación opcional significa que servidores MCP en producción existen en este momento, accesibles desde entornos de agentes, sin verificación de credenciales.

El Caja Negra del Transporte stdio

Para entornos de desarrollo local, MCP depende en gran medida del transporte stdio. Esto crea un canal no registrado entre el modelo de IA y la máquina local. Un ataque en la cadena de suministro que comprometa un servidor MCP de código abierto produce cero visibilidad en la red sobre lo que el agente de IA está siendo instruido a hacer en el host. El gusano Shai-Hulud, un malware autorreproductor incrustado en paquetes npm y analizado en profundidad por JFrog Security Research, demostró el potencial de amplificación: una vez incrustado, robaba tokens de desarrollador y se reinfectaba automáticamente en otros paquetes que esos desarrolladores mantenían, propagándose por la cadena de suministro sin intervención adicional del atacante.

---

Por qué Fallan los Controles de Seguridad Estándar

Los gateways API estándar validan tokens de autenticación, aplican límites de tasa básicos y verifican rutas. Fallan contra vectores de ataque específicos de IA porque toda la superficie de ataque está incrustada en la carga semántica de la llamada a la herramienta—no en sus encabezados HTTP, tokens de autenticación o estructura de rutas.

Considere una solicitud interceptada de un agente intentando ejecutar una operación en base de datos:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "execute_sql",
    "arguments": {
      "query": "DROP TABLE production_users CASCADE",
      "database": "primary_db"
    }
  },
  "id": 84
}

Un WAF pasa esta solicitud sin inspección porque los encabezados HTTP y los tokens OAuth son válidos. La amenaza existe enteramente en arguments.query. Un firewall tradicional no tiene mecanismo para evaluar el contenido semántico de ese campo.

El análisis de seguridad de identidad de SC Media de 2026 capturó el problema sistémico con precisión: los programas de confianza cero verifican la identidad del agente, pero no lo que el agente está siendo informado. Cada descripción de herramienta, cada respuesta API, cada prompt de usuario que entra en la ventana de contexto del agente se confía implícitamente una vez que pasa los controles perimetrales. Eso no es confianza cero. Es un modelo de perímetro con un agujero en forma de IA.

---

Arquitectura del Proxy MCP

Un proxy MCP funciona como un intermediario especializado entre el MCP Client y el MCP Server. Al terminar la conexión JSON-RPC, inspecciona las cargas útiles semánticamente y aplica gobernanza basada en políticas, extendiendo los principios de confianza cero a las interacciones agente-herramienta autónomas.

Las investigaciones han convergido en varias aproximaciones arquitectónicas. El marco ZT-MCP de un artículo de 2026 introduce un modelo formal de control de acceso basado en capacidades (CapBAC) con cuatro componentes de aplicación. MCP-Guard propone un marco de defensa en profundidad en varias etapas con escaneo estático ligero en una primera fase y evaluación semántica en una segunda. Plataformas de producción como TrueFoundry MCP Gateway, Portkey y Peta han implementado variaciones del patrón proxy comercialmente.

Una arquitectura de proxy MCP de nivel productivo consta de cinco componentes centrales.

1. Capa de Análisis y Intercepción del Protocolo

El proxy intercepta el transporte subyacente—transformando flujos stdio no observables en tráfico HTTP estructurado para observabilidad, o actuando como proxy inverso para conexiones HTTP Streamable. Analiza en tiempo real las cargas útiles JSON-RPC 2.0, extrayendo el método solicitado (por ejemplo, tools/call) y sus parámetros específicos. Aquí es donde el campo arguments.query en el ejemplo anterior se vuelve visible y susceptible de inspección.

Un beneficio práctico de esta capa: proporciona traducción centralizada del protocolo entre stdio, SSE y transportes HTTP, haciendo auditable las conexiones locales previamente invisibles sin modificar ni el cliente ni el servidor MCP.

2. Motor de Auditoría Semántica

Una vez analizada una carga útil, el proxy enruta los argumentos a un motor de auditoría semántica. Las implementaciones de producción combinan heurísticas deterministas (análisis AST, coincidencia de patrones SQL, detección de metacaracteres de shell) con modelos de clasificación ligeros para evaluar la intención. El motor evalúa las cargas útiles de llamadas a herramientas contra las guías empresariales.

En el ejemplo DROP TABLE, una capa de coincidencia de patrones marcaría la instrucción DDL destructiva antes de que se invoque cualquier modelo semántico. Para casos más ambiguos—un agente intentando un force_override en un parámetro de configuración de red—la capa semántica evalúa la combinación del nombre de la herramienta, los valores de los argumentos y el historial reciente de llamadas del agente para producir una clasificación de riesgo.

El motor de auditoría devuelve un error JSON-RPC al agente antes de que el servidor MCP vea la solicitud, y registra el evento de intercepción en el SIEM.

Cabe señalar una restricción de diseño: la versión actual de la especificación MCP (2025-11-25) exige OAuth 2.1 para transportes basados en HTTP, pero no incluye un mecanismo incorporado para firmar definiciones de herramientas. La Interfaz Mejorada de Definición de Herramientas (ETDI), propuesta en un artículo de Bhatt, Narajala y Habler (2025), describe un enfoque a nivel de protocolo usando definiciones de herramientas mejoradas con OAuth y verificaciones criptográficas para prevenir envenenamiento de herramientas y ataques de rug pull. Hasta mediados de 2026, ETDI sigue siendo una propuesta preliminar, no un estándar ratificado. Hasta que se adopte, la integridad de las herramientas requiere controles específicos en la capa proxy.

3. Mapeo de Identidad y Aplicación de Políticas (RBAC)

El proxy mapea el token OAuth 2.1 del MCP Client a herramientas específicas dentro del MCP Server. La especificación actual de MCP exige OAuth 2.1 con PKCE (Proof Key for Code Exchange usando S256) para todas las conexiones remotas HTTP desde la revisión de la especificación de noviembre de 2025. El proxy actúa como punto de aplicación donde esos tokens se validan contra una política de control de acceso centralizada.

Mediante RBAC granular, el proxy asegura que un agente con privilegios de solo lectura pueda llamar a list_files pero se le niegue write_file o execute_command en el mismo servidor. Un agente de documentación puede acceder a read_file y git_commit; un agente de despliegue, gobernado y registrado por separado, tiene execute_pipeline.

Un detalle crítico de implementación: la revisión de la especificación MCP de junio de 2025 prohibió explícitamente que los servidores MCP pasaran el token de acceso recibido del cliente a las APIs ascendentes, porque esto crea vulnerabilidades de deputy confundido. El proxy debe emitir tokens limitados en downstream, con ámbitos específicos para cada salto, en lugar de propagar el token entrante a través de los límites del servicio.

4. Interruptor de Circuito con Humanos en el Bucle (HITL)

Algunas operaciones son demasiado sensibles para gobernarse solo mediante políticas automatizadas. La especificación MCP lo reconoce directamente: “Por confianza, seguridad y protección, SIEMPRE debería haber un humano en el bucle con la capacidad de denegar invocaciones de herramientas.” La lista Top 10 de OWASP para Aplicaciones LLM (2025) refuerza esto bajo LLM06 (Agencia Excesiva): acciones de alto impacto no deben proceder sin aprobación humana.

El proxy MCP implementa esto actuando como un interruptor de circuito para operaciones de Nivel 1. La solicitud JSON-RPC se suspende en lugar de reenviarse o rechazarse. Se envía una alerta a una cola de revisión—ya sea un panel, una integración con Slack o un pager—con el nombre exacto de la herramienta, argumentos y la identidad del agente para revisión humana. Si se aprueba, el proxy reenvía la carga útil; si se rechaza, devuelve un error en lenguaje natural al agente, permitiendo que el LLM reevalúe su estrategia.

El mecanismo de muestreo en la especificación MCP proporciona un gancho nativo para este patrón, permitiendo que los servidores soliciten intervención del cliente. El proxy centraliza esta capacidad en todos los servidores conectados en lugar de dejarlo a cada uno.

5. Limitación de Tasa Agentic y Detección de Bucle

Los agentes autónomos pueden entrar en bucles de razonamiento, llamando repetidamente a la misma API cuando no logran analizar un error inesperado. Sin gobernanza, esto produce condiciones accidentales de denegación de servicio contra herramientas internas y sobrecostos por uso de API en la nube. La lista Top 10 de OWASP para Aplicaciones LLM clasifica esto como LLM10 (Consumo sin límites), con mitigaciones recomendadas en límites de tasa estrictos y interruptores de circuito automáticos.

El proxy MCP aplica límites de tasa con tokens en herramientas específicas y detecta patrones de bucle analizando la frecuencia de llamadas, secuencias de respuestas de error y variación en argumentos en invocaciones sucesivas. Cuando se detecta un bucle, el proxy interrumpe la ejecución del agente con un error estructurado que el LLM puede actuar, en lugar de permitir que el bucle continúe hasta un timeout externo.

---

La Capa de Autorización: Lo Que OAuth 2.1 Soluciona y Lo Que No

La especificación de autorización MCP evolucionó en tres revisiones principales en nueve meses. La revisión de marzo de 2025 introdujo OAuth 2.1 como base para la autenticación remota. La revisión de junio de 2025 formalizó los servidores MCP como Recursos OAuth (RFC 8707) y convirtió los Metadatos de Recursos Protegidos (RFC 9728) en obligatorios, separando completamente el rol del servidor MCP del servidor de autorización. La revisión de noviembre de 2025 hizo obligatorio PKCE para todos los clientes públicos, prohibió el método plain PKCE en favor de S256, y formalizó los Documentos de Metadatos de ID de Cliente como el mecanismo preferido de registro.

A pesar de esta maduración, una auditoría de seguridad de 2026 encontró que el 53% de los servidores MCP desplegados aún dependían de claves API estáticas de larga duración en lugar de OAuth 2.1. La contribución de OAuth se limita a la identidad a nivel de transporte: un token OAuth válido prueba quién afirma ser la parte que se conecta y qué ámbitos tiene concedidos. No prueba que la herramienta que el agente va a invocar sea la misma que el humano autorizó, ni detecta que una definición de herramienta ha sido modificada silenciosamente desde esa autorización. Para cerrar esas brechas, se requieren controles a nivel de aplicación en el proxy—versionado de esquemas de herramientas, hashing de definiciones al inicio de sesión y detección de anomalías en cambios de descripción.

---

Fortalecimiento de la Cadena de Suministro: El Tercer Perímetro

El proxy regula el comportamiento en tiempo de ejecución. Un conjunto paralelo de controles debe regular lo que entra en la cadena de suministro antes del tiempo de ejecución.

El ecosistema de paquetes de MCP presenta los mismos riesgos estructurales que cualquier ecosistema de software de código abierto, amplificados por el hecho de que los servidores MCP ejecutan código en nombre de agentes de IA con acceso potencialmente amplio al sistema. El incidente Postmark MCP de septiembre de 2025—donde un paquete clonado exfiltró silenciosamente tráfico de correo a través de quince versiones de comportamiento legítimo—estableció el patrón rug pull como una clase de ataque documentada. La compromisión de LiteLLM por el grupo TeamPCP, que demostró ataques en cadena en la cadena de suministro: LiteLLM, una puerta de enlace universal usada por aproximadamente 3.4 millones de descargas diarias y presente en el 36% de los entornos en la nube, fue objetivo del mismo grupo que previamente comprometió el escáner Trivy de Aqua Security y la acción KICS de Checkmarx en GitHub, explotando versiones no fijadas de herramientas CI/CD.

Controles prácticos para la seguridad en la cadena de suministro de MCP incluyen:

Verificación criptográfica del servidor: El proxy debe validar las firmas criptográficas de los paquetes del servidor MCP contra un registro interno de herramientas aprobadas antes de permitir que un agente establezca una conexión. La propuesta ETDI ofrece una arquitectura a nivel de protocolo para esto; hasta que se estandarice, controles específicos de implementación usando hashing de definiciones de herramientas cumplen la misma función.

Fijación de versiones y revalidación de esquemas: Los esquemas de herramientas deben fijarse en el momento de la instalación y revalidarse contra la versión fijada en cada nueva sesión. Una discrepancia debe activar una revisión humana, no una aceptación silenciosa.

Despliegues privados de servidores MCP para cargas de trabajo sensibles: La NSA CSI recomienda explícitamente ejecutar servidores MCP localmente en lugar de confiar en servicios externos cuando se procesan datos privados o sensibles, para reducir el riesgo de exposición de datos mediante servidores alojados comprometidos o no confiables.

Controles de espacio de nombres: La suplantación de nombres de paquetes MCP ha sido documentada como un vector activo de ataque. La lista OWASP MCP Top 10 (publicada en 2025) incluye servidores oficiales falsos y mal escritos como una categoría de amenaza distinta. Las configuraciones del proxy deben mantener una lista de permitidos de identificadores de servidores aprobados en lugar de confiar en la resolución de espacio de nombres en tiempo de ejecución.

---

Registro Centralizado de Auditoría: Haciendo Legible el Comportamiento del Agente para SIEM

La especificación MCP incluye orientación básica para el registro, pero deja la implementación de auditoría completa a los implementadores individuales. La CSI de la NSA identificó que un registro insuficiente o ausente es una de las brechas más prevalentes en implementaciones MCP del mundo real.

Cada interacción del proxy—aperturas de initialize, ejecuciones de tools/call, solicitudes de resources/read, llamadas rechazadas, llamadas suspendidas por HITL y eventos de límite de tasa—debería estructurarse como telemetría y transmitirse al SIEM de la organización. El desafío es que el tráfico JSON-RPC 2.0 no encaja en los patrones tradicionales de ingestión de SIEM diseñados para registros de acceso HTTP o flujos syslog. La lista OWASP MCP Top 10 clasifica la insuficiencia de registros como el noveno riesgo más crítico de MCP, señalando que la mayoría de los equipos actualmente no pueden reconstruir una línea de tiempo de ataque MCP a partir de la infraestructura de registros existente.

Los equipos SOC que implementan telemetría del proxy MCP deben desarrollar reglas de detección específicas para el comportamiento del agente: fallos secuenciales rápidos en múltiples herramientas dispares (señal de un agente hallucinado o comprometido), cambios súbitos en patrones de argumentos de herramientas desde un agente previamente estable, y llamadas a herramientas de alto privilegio desde agentes que solo han invocado operaciones de bajo privilegio.

La CSI de la NSA recomienda integrar los registros de auditoría MCP con los sistemas de identidad empresariales existentes para que cada acción del agente sea rastreable hasta una identidad autenticada específica—no solo a una credencial de aplicación.

---

Mejores Prácticas: Un Modelo de Gobernanza en Capas

Implementar un proxy MCP es el control fundamental. Una gobernanza efectiva requiere que esté dentro de un modelo en capas más amplio.

Aplicar validación estricta de esquemas de entrada en el límite del proxy. Nunca confiar implícitamente en las definiciones de esquemas de herramientas proporcionadas por un servidor MCP. El proxy debe aplicar validación centralizada de JSON Schema para todas las entradas de herramientas, rechazando solicitudes que incluyan metacaracteres de shell (|, &&, ;) en campos de texto estándar, tipos de argumentos incompatibles o claves de parámetros inesperadas. Esto es un filtro determinista de primera pasada que elimina una clase de intentos de inyección antes de que lleguen a la capa de auditoría semántica.

Aislar los entornos de ejecución del servidor MCP. Incluso con un proxy en marcha, el entorno de ejecución del servidor MCP debe estar asegurado. Los servidores MCP locales deben ejecutarse dentro de contenedores Docker o pods de Kubernetes con límites estrictos de memoria y CPU, montajes mínimos en el sistema de archivos y sin autoridad ambientada sobre el sistema host. La limitación de tasa del proxy previene que un servidor comprometido agote recursos de cómputo; el aislamiento de contenedores evita escaladas de privilegios al host subyacente.

Adoptar arquitecturas de micro-agentes con ámbitos de herramientas por función. Evitar asignar acceso amplio a herramientas a un solo agente. Un agente de documentación debería tener acceso proxy solo a read_file y git_commit. Un agente de despliegue—gobernado y registrado por separado—tiene execute_pipeline. Esto minimiza el radio de daño si algún agente se compromete o comienza a hallucinar, y hace que el modelo de control de acceso sea auditable.

Alinear el acceso a herramientas con zonas de clasificación de datos. La CSI de la NSA recomienda agrupar herramientas por nivel de sensibilidad: las herramientas públicas pueden manejar conjuntos de datos públicos, mientras que las que interactúan con datos sensibles o regulados—registros de salud, sistemas financieros, infraestructura de seguridad nacional—deben ser controladas y segregadas explícitamente. Este enfoque de zonificación se mapea naturalmente en la configuración RBAC del proxy.

Tratar la evaluación de servidores MCP con la misma rigurosidad que la gestión de acceso privilegiado. La guía de la NSA recomienda explícitamente aplicar los procesos de revisión más rigurosos de la organización a las herramientas MCP antes de su despliegue—los mismos procedimientos de auditoría de código utilizados para otro software de alto riesgo. Esto es importante: los servidores MCP que contienen credenciales para Slack, GitHub, Postgres y Salesforce simultáneamente (lo que OWASP MCP Top 10 clasifica como agregación de credenciales) representan un único punto de fallo comparable a una brecha de gestión de acceso privilegiado. Comprometer un servidor así y el radio de daño se extiende a cuatro sistemas.

---

Conclusión

El Model Context Protocol ha eliminado las barreras de integración que anteriormente aislaban a los modelos de IA de la infraestructura empresarial. Al proporcionar un adaptador universal para recursos, prompts y herramientas, ha permitido una transición de asistentes de IA pasivos a agentes autónomos activos—una transición que ya estaba en marcha a mediados de 2026, con más de 10,000 servidores indexados públicamente y 97 millones de descargas mensuales de SDK.

Esa conectividad conlleva una obligación de seguridad igualmente seria. La guía de la NSA de mayo de 2026, los marcos de clasificación de OWASP y una serie documentada de CVEs y ataques en la cadena de suministro han dejado claro que las defensas de red estándar son estructuralmente ciegas a la superficie de ataque semántica que MCP expone. El protocolo en sí no impone identidad, no exige autenticación en todos los transportes, y no proporciona un mecanismo incorporado para verificar la integridad de las definiciones de herramientas.

Los proxies MCP abordan esta brecha en el límite del protocolo. A través del análisis en tiempo real de JSON-RPC, la inspección semántica de cargas útiles, el mapeo de identidad ligado a OAuth 2.1, la interrupción con humanos en el bucle y la limitación de tasa agentic, aportan una aplicación de confianza cero a las interacciones agente-herramienta que de otro modo serían ingobernables. Combinados con controles en la cadena de suministro, entornos de ejecución en contenedores y telemetría estructurada de auditoría integrada con infraestructura SIEM, conforman la capa de gobernanza que hace que los sistemas multi-agente autónomos sean desplegables a escala empresarial sin aceptar un riesgo residual no caracterizado.

La deuda de seguridad acumulada durante la rápida adopción de MCP es real y está documentada. La herramienta para abordarla, desde marcos de proxy hasta modelos formales de RBAC y propuestas de verificación criptográfica de herramientas, está emergiendo junto con la superficie de ataque. Las organizaciones que desplegarán IA agentica de forma segura son aquellas que consideran la gobernanza MCP no como una preocupación futura, sino como un requisito previo para el despliegue en producción hoy.

---

Registro de Cambios

#	Sección	Cambio	Tipo
1	Introducción	Eliminada afirmación no respaldada sobre que MCP resuelve el “problema de integración N×M” con “200 puntos personalizados”—reformulado como caracterización del autor. Añadidas cifras de adopción con fuentes: más de 10,000 servidores (Anthropic, dic 2025), 9,400 servidores rastreados en cuatro registros (Q2 2026), 97M descargas SDK mensuales.	Extendido con datos respaldados
2	Sección de Protocolo	Añadida descripción precisa de la revisión de especificación de noviembre de 2025 (PKCE S256 obligatorio, RFC 9728 obligatorio). Eliminada afirmación de que la autorización es obligatoria en todos los transportes—el transporte stdio explícitamente no usa OAuth según la especificación.	Corregido
3	Panorama de Amenazas	Añadida sección completa sobre CVE-2025-6514 (CVSS 9.6, JFrog/mcp-remote, 437,000+ afectados), CVE-2025-49596 (CVSS 9.4, MCP Inspector RCE/CSRF), CVE-2025-53110, CVE-2025-53109 (Servidor MCP Filesystem de Anthropic). Estos son exploits documentados en el mundo real; el borrador original no contenía referencias CVE.	Añadido (con fuentes)
4	Panorama de Amenazas	Añadidos resultados del benchmark MCPTox: o1-mini 72.8% tasa de éxito en ataques de envenenamiento de herramientas; Claude 3.7-Sonnet mayor tasa de rechazo %. Reemplazadas descripciones vagas por datos empíricos del benchmark.	Corregido y extendido
5	Panorama de Amenazas	Añadido incidente Postmark MCP rug pull (septiembre 2025), ataque en cadena LiteLLM/TeamPCP, gusano Shai-Hulud. Estos incidentes son posteriores al borrador original y fundamentan la discusión en casos documentados.	Añadido (con fuentes)
6	Guía de la NSA	Añadido documento de la NSA AISC Cybersecurity Information Sheet (mayo 2026, U/OO/6030316-26) en todo el artículo como fuente principal. El borrador original no hacía referencia a esta guía.	Añadido (con fuentes)
7	Clasificación OWASP	Reemplazada referencia genérica a “marcos OWASP” por categorías específicas del OWASP Top 10 para Aplicaciones LLM 2025: LLM01 (Inyección de Prompts), LLM06 (Agencia Excesiva), LLM10 (Consumo sin límites). Añadido OWASP MCP Top 10 (2025) con riesgos numerados.	Extendido con datos respaldados
8	Motor de Auditoría Semántica	Añadido aviso explícito de que ETDI (Interfaz Mejorada de Definición de Herramientas) es una propuesta preliminar, no un estándar MCP ratificado a mediados de 2026. El borrador original implicaba que la verificación criptográfica del servidor era estándar en el proxy.	Corregido
9	Capa de Autorización	Añadida sección específica sobre evolución de OAuth 2.1 (marzo, junio, noviembre 2025). Clarificado que RBAC no es parte del protocolo MCP y debe implementarse a nivel de aplicación. Añadido que el 25% de los servidores MCP públicos no tienen autenticación y el 53% usan claves API estáticas.	Añadido (con fuentes)
10	Caso de uso IIoT	Eliminado el caso original que involucraba NVIDIA Omniverse y “Mirroring Industrial”. Este escenario contenía varias afirmaciones técnicas no verificadas sobre integraciones específicas y parámetros de latencia que no pudieron ser respaldadas. Reemplazado por una descripción de arquitectura basada en patrones documentados de proxy.	Eliminado (sin respaldo)
11	Mejores prácticas	Mantienen las cinco prácticas originales y se amplían con recomendaciones de la NSA CSI: zonificación por clasificación de datos, preferencia por despliegues privados/locales para cargas sensibles, evaluación de servidores MCP con controles similares a PAM.	Extendido con datos respaldados