Para auditar tus MCP, lista los que tienes conectados, revisa qué permisos y credenciales le diste a cada uno, elimina los que instalaste para probar y nunca volviste a usar, y quédate solo con los que vengan de un repositorio con dueño visible y mantenimiento reciente. La regla que más reduce el riesgo es simple: ningún servidor de terceros con credenciales de producción.
Un MCP es lo que le da manos a tu asistente. Sin uno, Claude solo habla. Con uno, lee tu Drive, manda correos, consulta tu base de datos o publica en tus redes.
El 5 de agosto de 2026 se publicó un escaneo de Enkrypt AI sobre 268.000 herramientas repartidas en 25.000 servidores MCP: más de 143.000 fallas de seguridad, que afectan al 73% de los servidores analizados. Anaconda compró la empresa el 4 de agosto justamente por eso.
No es un problema del modelo. Es la tubería que le instalaste debajo, en 30 segundos, desde un archivo de instrucciones de GitHub. Esta es la revisión que hago cada cierto tiempo, y toma menos de lo que tarda un café.
No puedes auditar lo que no ves, y casi nadie recuerda todo lo que instaló.
En Claude Code:
claude mcp list
Eso te devuelve cada servidor con su nombre y cómo arranca. Si trabajas con proyectos, revisa también el archivo de configuración del proyecto: un servidor puede estar declarado ahí y no en tu configuración global.
En la aplicación de escritorio, la lista vive en el archivo de configuración de Claude Desktop, dentro de la carpeta de soporte de aplicaciones de tu usuario.
Escribe la lista en un papel o en una nota. Vas a necesitar verla completa de un vistazo.
Por cada servidor de la lista, respóndete tres cosas:
¿Qué alcance tiene? No es lo mismo un servidor que lee documentación pública que uno con acceso de escritura a tu correo. Ordénalos de menor a mayor daño posible si algo sale mal.
¿Qué credenciales le diste? Busca las claves de interfaz de programación y los tokens que pusiste en su configuración. Aquí está la regla que más riesgo elimina de una sola vez: ningún servidor de terceros con credenciales de producción. Si necesita acceso, dale una clave con permiso mínimo y solo a lo que necesita.
¿Puede escribir o borrar? Un servidor de solo lectura equivocado te filtra información. Uno con permiso de escritura te borra cosas. Merecen niveles de confianza distintos.
Esta es la parte que más limpia y la que más cuesta hacer, porque da pereza.
Todos tenemos servidores que instalamos una tarde para ver qué hacían y nunca volvimos a abrir. Cada uno sigue ahí, con sus permisos intactos, y cada actualización suya entra a tu máquina sin que la mires.
claude mcp remove <nombre>
Si dudas de uno, quítalo. Volver a instalarlo cuesta un minuto; un servidor olvidado con acceso a tu correo cuesta mucho más.
Para cada superviviente, mira el repositorio de origen:
Un servidor sin dueño identificable y sin mantenimiento no es un riesgo teórico: es código que corre en tu máquina, con tus llaves, y que puede cambiar mañana sin avisarte.
Anota en un archivo qué servidores quedaron activos, qué hace cada uno y con qué credenciales. Tres líneas por servidor bastan.
Sirve para dos cosas: la próxima auditoría te toma tres minutos en vez de diez, y si algo raro pasa, ya sabes dónde mirar en vez de reconstruirlo de memoria.
Esta revisión no te hace inmune. No estás analizando el código de nadie ni detectando una puerta trasera bien escondida; estás reduciendo tu superficie de exposición, que es lo que sí está a tu alcance.
La mayor parte del riesgo real no es un ataque sofisticado: es un servidor que instalaste hace cuatro meses, que ya no usas, que tiene una clave con demasiados permisos y del que nadie se acuerda. Eso se arregla hoy, gratis, en diez minutos.