MCP de terceros: auditoría de 30 minutos antes de conectarlo

Antes de conectar un servidor MCP de terceros a tu agente de código, comprueba en menos de media hora quién lo mantiene y desde cuándo, qué permisos de archivo, red y shell reclama frente a los que realmente necesita, y si sus descripciones de herramientas pueden inyectar instrucciones ocultas al modelo. Sin esas tres capas, el servidor lee tus credenciales con los mismos permisos que tu agente.

Un servidor MCP no es una librería que importas y que ejecuta código en un sandbox del lenguaje: es un proceso independiente que tu agente inicia y con el que conversa por stdio o HTTP, y ese proceso hereda las variables de entorno, el sistema de archivos y la identidad de red de quien lo lanzó. Si tu agente de código corre con tu usuario del sistema y tiene acceso a claves de API, tokens de despliegue o credenciales de bases de datos en variables de entorno, el servidor MCP que conectas puede leerlas sin que el protocolo se lo impida, porque no define un límite de aislamiento por defecto. Esto contrasta con extensiones de navegador o apps móviles, que declaran permisos en un manifiesto que el sistema operativo o la tienda revisan antes de instalar. En MCP esa capa de revisión no existe todavía de forma estandarizada: cada servidor decide qué herramientas expone y qué puede hacer cada una, y el cliente —tu agente— confía en esa declaración. La mayoría de los servidores MCP publicados en registros comunitarios no pasan ningún proceso de firma ni auditoría de código antes de aparecer listados. Conectar uno equivale, en superficie de ataque, a dar permisos de ejecución de código arbitrario a un paquete de npm o PyPI que nadie ha revisado, con el agravante de que ese código puede actuar directamente sobre tus sistemas en producción si el agente tiene esos accesos.

Divide la auditoría en tres bloques de diez minutos y no te saltes ninguno aunque el servidor parezca fiable a primera vista. El primer bloque mira quién ha escrito el código y desde cuándo; el segundo mira qué puede hacer ese código una vez conectado a tu agente y cómo aislarlo; el tercero define cómo lo vas a desconectar si algo sale mal. Ninguno de los tres sustituye a los otros: un mantenedor de confianza puede publicar un servidor con permisos excesivos por descuido, y un servidor con permisos mínimos puede venir de una cuenta creada la semana pasada para robar credenciales de desarrolladores que confían en que 'parece un proyecto serio'. Este orden importa porque cada bloque filtra riesgos distintos y baratos de detectar antes de invertir tiempo en el siguiente. Si el servidor falla el primer bloque, no sigas: no hay configuración de aislamiento que compense un código de origen dudoso. Guarda los resultados de los tres bloques en un documento breve —dos líneas por punto es suficiente— para no repetir la auditoría entera cada vez que otro miembro del equipo quiera usar el mismo servidor.

Minuto 0-10: procedencia y superficie de código

• Repositorio público con historial de commits real, no un único commit inicial con todo el código ya escrito.
• Mantenedor identificable con actividad previa, no un perfil creado la misma semana que el paquete.
• Licencia declarada y dependencias listadas en package.json o requirements.txt sin ofuscar.
• Sin binarios precompilados que no tengan el código fuente correspondiente en el repositorio.
• Issues de seguridad abiertos revisados uno a uno, no solo los que aparecen cerrados sin explicación.

Minuto 10-30: qué pide, qué puede tocar y cómo aislarlo

• Lista exacta de herramientas (tools) que expone el servidor y qué argumentos acepta cada una.
• Si alguna herramienta permite ejecutar shell, escribir fuera de un directorio de trabajo acotado, o hacer peticiones HTTP salientes sin lista blanca de dominios.
• Grep de process.env / os.environ en el código fuente para ver qué variables de entorno lee al arrancar.
• Llamadas salientes a dominios de telemetría o analytics no documentados en el README.
• Si pide credenciales con más alcance del que la tarea necesita, como un token de administrador cuando solo hace falta lectura.
• Ejecútalo primero en un contenedor o VM separada del entorno con credenciales reales, nunca en la misma máquina que el agente en producción.
• Usa credenciales de alcance mínimo y revocables mientras dura la prueba, y define de antemano cómo matarlo si algo sale mal.

Hay un patrón que ningún checklist de 'permisos al instalar' captura: el rug pull de herramientas MCP. Un servidor puede pasar tu auditoría inicial con una definición de herramienta inofensiva y, semanas después, con una actualización silenciosa de versión, cambiar la descripción o el comportamiento de esa misma herramienta sin que tu agente vuelva a pedir aprobación, porque la mayoría de clientes MCP solo confirman la primera vez que ven un nombre de herramienta, no cada vez que cambia su definición. Esto significa que auditar un servidor MCP no es un evento único de instalación, sino que exige fijar la versión —pin de versión o hash del paquete— y revisar el diff antes de cada actualización, igual que harías con una dependencia crítica de producción. El propio protocolo no obliga a firmar versiones ni a notificar cambios de forma verificable, así que la responsabilidad de detectarlo recae por completo en quien lo instaló. Un simple hash del paquete guardado junto a la fecha de auditoría basta para saber, meses después, si lo que corre hoy es lo mismo que aprobaste entonces. En la práctica, muy pocos equipos tratan sus servidores MCP con el mismo rigor de control de versiones que aplican a sus dependencias de backend, precisamente porque la promesa de MCP es la instalación sin fricción, y ahí está la tensión real del protocolo.

No recomendamos auditar con el mismo nivel de profundidad cada servidor MCP que un equipo prueba. Si lo hicierais, nadie usaría MCP: la fricción mataría la herramienta que se supone que ahorra tiempo. Lo que sí defendemos es clasificar por nivel de riesgo antes de decidir cuánto tiempo invertir en revisar cada uno.

Esta guía de 30 minutos tiene sentido para un servidor MCP que va a tener acceso a credenciales de producción, a tu repositorio de código con permisos de escritura, o a sistemas de clientes. No tiene sentido aplicarla igual a un servidor MCP que solo consulta la documentación pública de una librería, corre en un entorno de pruebas sin secretos reales, o lo usas cinco minutos para un experimento personal que luego desinstalas. Tratar cada instalación como si fuera un despliegue a producción genera fatiga de seguridad: el equipo deja de auditar nada porque auditar todo es inviable, que es exactamente el resultado contrario al que se busca. Nosotros mismos, en pruebas internas rápidas, nos saltamos pasos de este checklist cuando el entorno está completamente desconectado de datos reales, no por pereza, sino porque el riesgo real en ese caso es prácticamente cero. La clave está en decidir, antes de instalar nada, qué accesos va a tener el agente que usa ese MCP, y reservar la auditoría completa para los casos donde esos accesos incluyen algo que no puedes permitirte perder.

• Clasificamos el servidor por nivel de acceso que va a tener: solo lectura de documentación, escritura en repositorios, o acceso a producción.
• Revisamos el código fuente completo cuando va a tocar credenciales o infraestructura real, no solo el README.
• Lo probamos primero en un entorno aislado, sin conexión a los sistemas del cliente.
• Documentamos qué herramientas expone y fijamos la versión antes de dar luz verde para uso continuado.