Di sí a MCP de forma segura: guía para gobernar agentes de programación con IA con Evo ADS

Cuando anunciamos que MCP Governance ya está disponible en Evo Agentic Development Security (ADS), la pregunta de seguimiento más común fue práctica: «Muy bien. ¿Por dónde empiezo el lunes?»

Es una pregunta válida: en 10,000 entornos de desarrollo, Snyk encontró 4,524 servidores MCP únicos en uso activo, y 1 de cada 12 desarrolladores con un servidor MCP instalado tenía un hallazgo confirmado de gravedad alta o crítica. La mayoría de esos servidores se agregaron en segundos, por un desarrollador que quería que su agente hiciera algo útil, sin ninguna revisión previa.

Esta es nuestra respuesta: cuatro pasos te llevan desde el inventario inicial hasta las políticas que bloquean solo los servidores riesgosos. Ahora Evo ADS asigna una puntuación de riesgo a los servidores MCP para que puedas gobernarlos según su riesgo, con o sin una lista de permitidos, en lugar de revisar cada servidor manualmente o bloquear de forma general y ralentizar a los desarrolladores. Todo se ejecuta en el endpoint donde los agentes ya trabajan, mediante hooks ligeros y sin un proxy de por medio. Descubre qué hay, define qué es aceptable, observa qué detecta tu política y aplica controles con confianza.

Paso 1: Descubre qué está en ejecución

Los servidores MCP no pasan por CI ni por las revisiones de dependencias. Un desarrollador edita un archivo de configuración y su agente ya tiene un nuevo conjunto de herramientas. Por eso, el primer paso es averiguar qué hay en ejecución. No puedes gobernar lo que no puedes ver, así que Evo ADS te ofrece dos vistas:

• Servidores MCP en los equipos de los desarrolladores: Implementa el instalador de Evo ADS en toda tu flota. Muestra los servidores MCP a los que realmente se conectan los agentes, incluidas las instalaciones locales puntuales que nunca tocaron un repositorio.

• Servidores MCP en repositorios de código: Evo AI-SPM, configurado mediante la integración de SCM de Snyk, encuentra servidores MCP a los que se hace referencia en tu código.

En conjunto, estas vistas responden dos preguntas diferentes: qué está configurado en el código y qué se está ejecutando en las laptops. Ambas aparecen en la interfaz de Evo, en Inventario → Servidores MCP.

También puedes usar Evo MCP Server para acceder a estos datos mediante tu propio flujo de trabajo agéntico. Así obtienes una vista única de todos tus servidores MCP, sin bloquear nada ni interrumpir a los desarrolladores. Con este primer paso, ya puedes responder una pregunta que la mayoría de los equipos de seguridad no puede contestar: ¿a qué se conectan nuestros agentes?

Paso 2: Define qué significa «aceptable»

Decidir si el servidor número 47 es aceptable no debería requerir un hilo de Slack y una búsqueda en la web. Evo ADS pone la evidencia junto a cada servidor para que puedas aprobarlo o rechazarlo más rápido y con confianza.

Revisa el inventario

Un servidor de alto riesgo, instalado ampliamente y sin carácter oficial plantea un problema muy distinto al de uno de alto riesgo instalado en una sola máquina. Cada fila responde las preguntas que, de otro modo, tendrías que investigar manualmente: quién creó el servidor, dónde está instalado, si alguien lo aprobó y qué tan riesgoso es:

• Servidor: nombre, origen (por ejemplo, NPM), transporte (SSE o STDIO) y si es local.

• Origen del proveedor: indica si el servidor es oficial. Que sea desconocido también es una señal.

• Origen: cuántas veces aparece en el código, en los equipos y durante la ejecución.

• Estado de la lista de permitidos: permitido o no permitido.

• Puntuación de riesgo: una puntuación unificada por servidor, que puedes ordenar y filtrar.

• Problemas por gravedad: cantidades de problemas críticos, altos, medios y bajos.

Ordena por puntuación de riesgo y luego revisa los resultados.

Abre el perfil de riesgo

Haz clic en un servidor para ver sus detalles. El encabezado agrega los métodos de autenticación, y tres tarjetas muestran dónde se encuentra: si está declarado en el código, en cuántas máquinas está y cuándo se analizó por última vez, y con qué frecuencia lo llamaron los agentes en los últimos siete días.

Luego, abre la pestaña Perfil de riesgo. Esta es la pestaña que reemplaza el hilo de Slack y la búsqueda en la web.

En uno de los servidores que examinamos, Evo encontró descripciones de herramientas que contenían «ignora las instrucciones anteriores» en 8 de 12 casos. Eso es una inyección de prompts que solo detectarías si leyeras tú mismo cada descripción de herramienta.

Las puntuaciones van de 0 a 1000:

• Bajo (de 0 a 249)

• Medio (de 250 a 499)

• Alto (de 500 a 749)

• Crítico (de 750 a 1000)

La pestaña desglosa la puntuación en atributos como inyección de prompts en descripciones de herramientas, capacidades destructivas y contenido no confiable, cada uno con una puntuación de hasta 1000. Expande un atributo para ver una descripción y una explicación de «¿Por qué este riesgo?» con evidencia.

Este servidor ya estaba en la lista de permitidos. Alguien lo aprobó y, aun así, tiene una puntuación de 931, claramente crítica. Una lista de permitidos registra una decisión tomada en un momento determinado; la puntuación de riesgo te indica cuándo es necesario volver a evaluarla. Puedes cambiar su estado a «No permitido» desde esta página o bloquearlo durante la ejecución.

Cómo se calcula la puntuación de los servidores

La puntuación de riesgo de MCP combina tres señales: el comportamiento del servidor (las instrucciones y descripciones de herramientas que envía a los agentes), la confianza (la reputación de sus URL y la identidad de sus responsables) y, en el caso de los servidores locales cuyo código fuente está disponible, la implementación, el mantenimiento y las dependencias. Una limitación es que Evo no puede identificar con certeza los servidores sin firma. Representan menos del 20 % de los servidores y no reciben una puntuación. Tenlos en cuenta en tu proceso de revisión.

Establece tu base

La lista de permitidos registra los servidores MCP que aprobaste. Cada servidor tiene un interruptor: aprobado o no aprobado. Cámbialo y la decisión aparecerá en la columna Estado de la lista de permitidos del inventario (Permitido o No permitido), para que todas las personas que lo consulten vean el mismo estado. Consulta la lista de permitidos en la vista de detalles de un servidor para ver la lista completa.

Empieza con lo que ya consideras confiable; no necesitas crear la lista desde cero. Llénala a partir de un inventario existente, una lista seleccionada o los servidores que Evo ADS ya detectó. Cambia manualmente el estado de los servidores en el inventario o simplemente pídele a Evo en el chat.

Para cada candidato, revisa lo que aprendiste antes: el rango de puntuación, si el proveedor es oficial, cómo se autentica y, para cualquier servidor de riesgo alto o crítico, la evidencia de «¿Por qué este riesgo?». Un servidor oficial, autenticado y con una puntuación baja es una aprobación sencilla. Un servidor crítico merece una justificación antes de aprobarlo, y rechazarlo también es una respuesta perfectamente válida.

Recuerda: la lista de permitidos registra decisiones. Por sí sola, no bloquea nada. Las políticas aplican esas decisiones; eso nos lleva a los siguientes pasos.

Paso 3: Observa antes de bloquear

Activar el bloqueo desde el primer día interrumpe flujos de trabajo de desarrollo que aún no has visto. El modo de monitoreo te muestra exactamente qué bloquearía tu política antes de que bloquee nada. Crea tu primera política a partir de la plantilla Monitorear servidores MCP no permitidos en la página de políticas (Políticas → Problemas → Crear política). La política genera un problema por cada servidor riesgoso para que lo revises, sin bloquear nada. Así, los desarrolladores y los agentes siguen trabajando mientras obtienes una lista actualizada de todo lo que detectaría tu política.

Luego, revisa esa lista en Inventario → Servidores MCP, usando la fila y el Perfil de riesgo que conociste en el Paso 2. Para cada servidor marcado, revisa la puntuación, si es oficial, cómo se autentica y qué atributos contribuyeron a la puntuación. Después, decide: apruébalo y agrégalo a la lista de permitidos o recházalo. Hazlo durante una o dos semanas y observa si hay patrones. Un servidor que aparece una sola vez puede ser una curiosidad, pero uno que aparece en cincuenta máquinas requiere una decisión deliberada.

Al final de la segunda semana, tendrás una política que refleja tu tolerancia al riesgo y que se probó con tus servidores reales. Además, tu equipo de seguridad y tus desarrolladores ya la habrán visto en funcionamiento antes de que llegue a detenerlos.

Paso 4: Aplica controles, empezando por lo riesgoso

Cuando confíes en lo que detecta la política, activa la aplicación de controles. La plantilla de política Bloquear servidores MCP no permitidos (Políticas → Políticas → Crear política) impide que los agentes de programación llamen, durante la ejecución en el endpoint, a servidores que no están en tu lista de permitidos y que tienen un riesgo alto o crítico. Si la plantilla no se ajusta a tu tolerancia al riesgo, usa Empezar desde cero y crea una política personalizada según tus propios criterios.

La política bloquea un servidor solo cuando no está en tu lista de permitidos y tiene una clasificación de riesgo alto o crítico. Todo lo demás sigue ejecutándose en modo de registro, así que un servidor de bajo riesgo que nadie haya aprobado todavía no detendrá a un desarrollador, y conservarás un registro de auditoría. Además, la aplicación de controles ocurre localmente durante la ejecución en la máquina del desarrollador, mediante hooks ligeros que funcionan junto al agente, en lugar de hacerlo mediante un proxy o una puerta de enlace en su ruta. Configuras la política una sola vez, de forma centralizada. Los hooks la aplican en cada máquina cuando el agente llama al servidor, ya sea Claude Code, Cursor, Codex o GitHub Copilot.

Di sí a MCP, con control

Así, el lunes implementas el instalador y conectas tu SCM; para el viernes, ya tienes un inventario y una lista de permitidos inicial. Con Evo ADS, puedes decir sí a MCP y seguir sabiendo a qué se conectan tus agentes, tomar decisiones rápidamente y bloquear lo riesgoso. Este es el primer caso de uso de Gobernar el comportamiento de los agentes, y apenas estamos comenzando: durante el resto del año, el mismo modelo de descubrimiento, clasificación y aplicación de controles se extenderá a las habilidades de los agentes, el acceso a datos confidenciales, la protección contra la inyección de prompts y la exposición de secretos.

¿Quieres saber a qué se conectan tus agentes? Agenda una demostración o descubre Evo Agentic Development Security.