Secretos que se filtran de los servidores MCP: detectar una exposición inducida por el protocolo

¿Qué es esto?

El Model Context Protocol (MCP) se ha convertido en la forma estándar de conectar grandes modelos de lenguaje con herramientas y datos externos. Un artículo de arXiv de finales de junio de 2026, “What Happens Locally, Leaks Globally”: Detecting Privacy Leakage Risks in MCP Servers (2606.21338), sostiene que esa comodidad conlleva un riesgo concreto y poco examinado: los valores sensibles escapan del código de un servidor MCP no por una llamada de exfiltración evidente, sino por la mecánica ordinaria del propio protocolo.

La observación central es que aquí la filtración está inducida por el protocolo. En una aplicación convencional, un fallo de exfiltración suele implicar una solicitud saliente explícita: un POST HTTP, una escritura de socket, un registro enviado fuera de la máquina. En un servidor MCP, una credencial, una clave de API o un dato de identificación personal (PII) puede cruzar la frontera entre la máquina local y el LLM simplemente al ser devuelto por un manejador de herramienta, escrito en un registro o lanzado en un mensaje de excepción. No hay ningún send() que buscar en el código fuente. El valor abandona el contexto local de confianza en cuanto aterriza en algo que el modelo va a leer.

Para medir su frecuencia, los autores construyeron MCPPrivacyDetector, un marco de análisis estático, y lo ejecutaron sobre 10 655 servidores MCP reales. Reportan filtración en más del 10 % de ellos, con casos confirmados que incluyen tokens Bearer expuestos, claves de API propagadas y credenciales de autenticación en texto plano.

Cómo funciona

El problema de detección es más difícil que un análisis de contaminación (taint analysis) clásico, por dos razones que el artículo aborda directamente.

Primero, los servidores MCP se escriben en muchos lenguajes —Python, TypeScript, Go y otros—, de modo que un analizador de un solo lenguaje se pierde la mayor parte del ecosistema. MCPPrivacyDetector eleva estas bases de código heterogéneas a una representación de programa unificada, para que la misma lógica de análisis se aplique con independencia del lenguaje de origen.

Segundo, los «sumideros» (sinks) peligrosos no son los habituales. Una herramienta estándar busca sumideros de red o de escritura de archivo. Aquí los sumideros son específicos del protocolo e implícitos: el valor de retorno de un manejador de herramienta, una instrucción de registro, un objeto de error que se devuelve al llamante. El marco los codifica como sumideros, aplica un filtrado semántico sensible al contexto para separar los valores realmente sensibles (tokens, claves, PII) de las cadenas inocuas, y luego ejecuta un análisis de contaminación para enumerar los flujos posibles desde una fuente sensible hasta uno de esos sumideros implícitos.

Fuente sensible                Sumidero MCP implícito        Resultado
─────────────────              ──────────────────            ──────
variable de entorno / secreto  ──►  retorno del manejador ──►  el valor alcanza el contexto del LLM
credencial de config           ──►  instrucción de log    ──►  el valor escrito en registros compartidos
token de autenticación         ──►  excepción / mensaje   ──►  el valor devuelto al llamante

No se publica código de explotación; la contribución es un estudio de medición junto con un detector. Es el mismo patrón del «canal que los defensores inspeccionan menos» que se ve en la inyección mediante metadatos de archivos y en las fallas de servidores de tipo taint en el ecosistema MCP; la diferencia es que aquí la ruta de filtración parece, en el código fuente, un comportamiento de herramienta completamente normal.

Por qué importa

Los servidores MCP manejan de forma rutinaria secretos reales: todo el propósito de una herramienta es autenticarse ante una base de datos, una API SaaS o un servicio interno en nombre del modelo. Cuando esos secretos fluyen hacia las salidas de los manejadores, los registros o los errores, quedan legibles para el modelo y, a través de él, para todo aquello a lo que el modelo esté expuesto. Súmese un modelo que también ve contenido no confiable y puede actuar hacia el exterior, y se obtiene la clásica trifecta letal: un token filtrado en la respuesta de una herramienta está a una sola inyección indirecta de ser exfiltrado.

La escala es lo relevante. Una tasa de filtración superior al 10 % en más de diez mil servidores no es un puñado de despliegues mal configurados; es una propiedad estructural de cómo se están escribiendo hoy los servidores MCP, en consonancia con el panorama más amplio de los patrones de vulnerabilidad de los backends MCP y con incidentes anteriores en un solo servidor como la filtración de token del servidor MCP de Splunk. Como la filtración no tiene una llamada saliente explícita, también elude la revisión de código y muchas pasadas de detección de secretos que se fijan en los sumideros de red. Esta clase entra de lleno en OWASP LLM02, Divulgación de información sensible.

Defensas

El principio unificador es tratar todo lo que un manejador de herramienta devuelve, registra o lanza como datos que llegarán al modelo y, por tanto, como un canal saliente.

Separe los secretos de la salida de la herramienta. Un manejador debe devolver solo el resultado que el modelo necesita, nunca la credencial que usó para obtenerlo; mantenga tokens y claves en una capa que el modelo nunca vea. Redacte antes de devolver: filtre los valores de retorno, las líneas de registro y los mensajes de error en busca de cadenas de alta entropía y formatos de secretos conocidos, para que una excepción no pueda enviar un token Bearer al llamante. Acote las credenciales para que una filtrada tenga poco valor y sea efímera, y rótelas ante cualquier sospecha de exposición: la misma disciplina recomendada para la filtración de credenciales en las skills de agentes. Incorpore en la CI un análisis estático del tipo que demuestra este artículo, verificando específicamente los flujos hacia los sumideros del protocolo y no solo los sumideros de red clásicos. Por último, alinee el despliegue con las guías publicadas: las consideraciones de diseño de seguridad de MCP de la NSA (junio de 2026) y las mitigaciones mapeadas en los trabajos más amplios sobre privacidad de agentes insisten ambas en una validación estricta de las salidas y en fronteras de mínimo privilegio entre un agente y sus proveedores de contexto.

Estado

Elemento	Detalle
Divulgación	Preprint arXiv 2606.21338, finales de junio de 2026 (estudio de medición + detector)
Naturaleza	Filtración inducida por el protocolo de secretos/PII vía retornos, registros y mensajes de error de los manejadores de herramientas MCP
Detector	MCPPrivacyDetector — análisis estático multilenguaje + filtrado semántico contextual + análisis de contaminación hacia sumideros MCP implícitos
Escala	10 655 servidores MCP reales analizados; filtración hallada en >10 %; tokens Bearer, claves de API y credenciales en texto plano confirmados
Afectados	Implementaciones de servidores MCP que manejan secretos (independiente del lenguaje y del modelo)
Clase	OWASP LLM02 — Divulgación de información sensible

Los resultados reflejan el estudio citado. Un analizador estático señala flujos posibles, no exposiciones confirmadas en producción; valide las rutas señaladas en su propio despliegue antes de sacar conclusiones sobre un servidor concreto.