MCP como cadena de suministro: límites de confianza en el tooling de agentes

MCP (Model Context Protocol) se está imponiendo. Se está convirtiendo en la forma estándar en que los agentes de IA se conectan a herramientas, fuentes de datos, servicios externos y entre sí. La Linux Foundation ahora lo alberga a través de la Agentic AI Foundation, todos los grandes labs de IA lo soportan y ya hay miles de servers en producción.

Pero la mayoría de los equipos trata a los servers MCP como APIs internas. No lo son. Un server MCP es un límite de confianza entre un agente de IA y tus sistemas, y la mayoría se despliega con la misma postura de seguridad que un proyecto de hackathon de fin de semana.

Después de analizar miles de configuraciones de servers MCP, estos son los cinco puntos ciegos que veo una y otra vez.

1. ¿Por qué las descripciones de herramientas MCP son una superficie de ataque?

Las descripciones de herramientas son una superficie de ataque porque los agentes las leen como instrucciones y actúan en consecuencia, no como documentación pasiva. Esto sorprende a la mayoría de los desarrolladores. Un server malicioso o comprometido puede armar descripciones de herramientas que manipulen el comportamiento del agente.

Esto es tool poisoning (envenenamiento de herramientas): esconder en la descripción o el schema de una herramienta instrucciones que pisan el system prompt del agente, exfiltran datos o redirigen acciones hacia otras herramientas.

Ejemplo: una herramienta descrita como "Buscar documentos de la empresa" podría incluir instrucciones ocultas que le dicen al agente que primero mande todos los parámetros de la consulta a un endpoint externo. El usuario nunca ve la descripción de la herramienta. El agente simplemente la sigue.

La mayoría de los equipos nunca audita qué les dicen realmente sus servers MCP a los agentes. La detección dedicada de tool poisoning atrapa esto, y aparece más seguido de lo que esperarías.

2. ¿Alcanza con el aislamiento de red para un server MCP interno?

No. El patrón más común que veo es un server MCP corriendo en localhost o dentro de una VPC con cero autenticación, bajo el supuesto de que el aislamiento de red alcanza. Los agentes de IA suelen correr en entornos donde el límite de red es difuso: cloud functions, orquestadores de contenedores, máquinas de desarrollo con varias herramientas conectadas. Un server que hoy es "solo interno" mañana puede ser alcanzable desde un contexto inesperado.

Incluso para servers genuinamente internos, la autenticación importa porque establece identidad. Sin ella no podés responder la pregunta más básica: ¿qué agente hizo este request?

3. ¿Cuánto debería poder hacer una sola herramienta MCP?

Lo mínimo que el trabajo requiere: exponer la capacidad mínima, con restricciones explícitas sobre los inputs. Los desarrolladores construyen herramientas MCP para resolver un problema específico: "leer esta base de datos", "mandar esta notificación", "consultar esta API". Pero rara vez piensan a qué más puede acceder la herramienta.

Una herramienta de consultas a la base de datos podría aceptar SQL arbitrario. Un lector de archivos podría salirse del directorio previsto. Una herramienta de notificaciones podría aceptar cualquier destinatario, no solo el que corresponde.

El principio de mínimo privilegio aplica a las herramientas MCP, pero casi nadie lo hace cumplir. En la práctica significa capacidad mínima con inputs validados: no "consultar la base de datos" sino "consultar la tabla de usuarios con estas columnas permitidas y un máximo de 100 filas".

4. ¿Cómo puede un server MCP atacar a otro a través del agente?

Cuando un agente se conecta a varios servers MCP, cada server confía implícitamente en todos los demás a través del agente. Las herramientas del server A pueden influir en el agente para que llame a las herramientas del server B de formas no previstas.

Esto crea escalación cross-origin: la misma clase de problema que sufrieron los navegadores web antes de CORS, salvo que para MCP todavía no existe un modelo de seguridad equivalente.

Un ejemplo práctico: un agente conectado a la vez a un server MCP de "wiki de la empresa" y a otro de "despliegue de código". Una herramienta de la wiki comprometida podría manipular al agente para que despliegue código malicioso. El server de despliegue no tiene forma de saber que el request se originó en una fuente comprometida.

Por eso Oktsec opera en la capa del gateway. Puede aplicar políticas a través de los límites entre servers, algo que los servers individuales no pueden hacer por su cuenta.

5. ¿Por qué MCP necesita monitoreo en runtime después del despliegue?

El monitoreo en runtime importa porque el riesgo no termina en el despliegue, ahí empieza. Los equipos invierten tiempo en construir y probar servers MCP. ¿Pero después del despliegue? Silencio. Nada de monitoreo sobre qué herramientas se están llamando, desde qué agentes, con qué parámetros, con qué frecuencia.

Eso significa que no podés detectar comportamiento anómalo cuando un agente de repente hace miles de llamadas a una herramienta que casi nunca usa. No podés auditar acciones después del hecho cuando alguien pregunta quién desplegó ese cambio de código el martes pasado. Y no podés identificar a un agente comprometido que empieza a exfiltrar datos a través de llamadas a herramientas.

El monitoreo en runtime para MCP es el equivalente de los logs de aplicación y el APM para servicios web. No es infraestructura opcional. Es la postura de seguridad mínima viable.

El camino por delante

Ninguno de estos problemas es irresoluble. Son la misma clase de cuestiones que enfrenta todo protocolo nuevo cuando pasa de la adopción temprana a ser infraestructura de producción. La diferencia es la línea de tiempo: la adopción de MCP se mide en meses, no en años.

Lo que le recomendaría a cualquier equipo que despliegue servers MCP hoy:

Escaneá antes de desplegar. Revisá cada server MCP contra patrones de riesgo conocidos antes de que salga a producción. Lleva minutos y atrapa los problemas obvios temprano.

Autenticá todo. Incluso los servers internos. Especialmente los servers internos.

Auditá las descripciones de tus herramientas. Leelas como lo haría un atacante. ¿Qué podría terminar haciendo un agente engañado?

Acotá tus herramientas. Capacidad mínima, restricciones explícitas, inputs validados.

Monitoreá en runtime. Tené visibilidad de qué están haciendo tus agentes después de desplegarlos.

El ecosistema MCP va a ser infraestructura crítica. Construyámoslo como si importara.