Evo ADS Govern Agent Behavior ya está disponible: controla el uso de MCP

Hoy anunciamos que Govern Agent Behavior, la capacidad de Evo Agentic Development Security (ADS) que controla lo que los agentes de programación con IA pueden hacer en tiempo de ejecución, ya está disponible de forma general, comenzando con MCP Governance.

Desde que presentamos Evo ADS en junio, hemos trabajado con una idea sencilla: el desarrollo agéntico introduce riesgos en tres superficies, y cada una requiere su propio tipo de control:

1. Lo que los agentes usan: los servidores MCP, las habilidades y las herramientas que incorporan, que deben descubrirse y evaluarse.

2. Lo que los agentes generan, que debe validarse en el momento de su creación.

3. Y lo que los agentes hacen: las acciones que realizan una vez que deciden actuar, que deben hacerse cumplir en tiempo real.

Govern Agent Behavior es la respuesta de Evo ADS a esa tercera pregunta, y MCP Governance es el primer caso de uso que ofrecemos.

En la práctica, MCP Governance permite que los equipos de seguridad y plataforma descubran todos los servidores MCP en su entorno, definan cuáles se pueden usar, detecten cuando un agente incumple esa política y registren o bloqueen el uso de MCP en el momento de la ejecución, en vivo, en Claude Code, Cursor, Codex y GitHub Copilot.

Controlar las herramientas que puede usar un agente autónomo es fundamental: es el tipo de control que la mayoría de los equipos de seguridad daban por sentado, hasta que lo buscaron y no encontraron nada. MCP Governance cierra esa brecha de forma nativa, dentro del mismo flujo de trabajo en el que se descubre la cadena de suministro de agentes y se valida el código generado por IA, en lugar de agregarlo como una herramienta independiente.

Por qué es importante controlar MCP ahora

El Model Context Protocol (MCP) es el estándar que permite a los agentes de programación con IA conectarse a herramientas, fuentes de datos y sistemas externos —como repositorios, bases de datos, infraestructura en la nube y API internas— mediante una interfaz común. Es una de las principales razones por las que los agentes se parecen cada vez menos a una función de autocompletado y más a compañeros de trabajo: un agente con acceso a MCP no solo sugiere una línea de código; también puede consultar un sistema de gestión de tickets, extraer registros de una base de datos de producción o llamar a un servicio interno, todo en la misma sesión.

Ese poder también es el problema. MCP estandariza cómo se conectan los agentes a las herramientas, pero no dice nada sobre cuáles herramientas deben considerarse confiables ni qué debería permitirse hacer a un agente con las herramientas a las que puede acceder. Cada servidor MCP al que se conecta un agente es, en la práctica, un nuevo componente de la cadena de suministro de software. Sin embargo, a diferencia de una dependencia fijada en un manifiesto, a menudo se incorpora de forma dinámica, cuando un desarrollador lo instala en unos segundos, sin ningún proceso de revisión.

Esta exposición no es hipotética ni nueva: es el mismo problema de los paquetes maliciosos, ahora por otra vía. Un servidor MCP comprometido puede leer archivos locales, exfiltrar credenciales o acceder a sistemas internos en cuanto se ejecuta, antes de que un equipo de seguridad siquiera sepa que existe, y mucho menos tenga la oportunidad de revisarlo. El riesgo se materializa en la máquina del desarrollador, en el momento en que se invoca; por eso, es ahí donde hay que detectarlo.

La escala es mayor de lo que la mayoría de los equipos de seguridad supone. Los datos de escaneo propios de Snyk, obtenidos de casi 10.000 entornos de desarrollo, identificaron 4.524 servidores MCP únicos en uso activo; las máquinas con más instrumentación ejecutaban 13 o más al mismo tiempo. Más de la mitad de los desarrolladores ya tienen conexiones MCP activas con herramientas y sistemas de producción. Y, al analizar la postura de seguridad de esas conexiones, encontramos que, hoy, 1 de cada 12 desarrolladores con un servidor MCP instalado tenía un hallazgo confirmado de gravedad alta o crítica.

Nada de esto aparece en un flujo tradicional de AppSec, ya que los servidores MCP no son artefactos que se analicen en CI ni dependencias que se revisen antes de integrar cambios. En cambio, se incorporan en vivo, durante la ejecución, a menudo fuera de cualquier proceso que el equipo de seguridad pueda supervisar. Sin una forma de definir qué servidores MCP son aceptables y hacer cumplir esa política cuando un agente intenta usarlos, «adoptar agentes de IA» y «ampliar la superficie de ataque no administrada» se convierten en la misma frase.

Cómo funciona MCP Governance en Evo ADS

MCP Governance es la respuesta de Evo ADS a esa brecha y una extensión directa de la visibilidad que Evo ADS ya ofrece sobre la cadena de suministro de agentes. Hace tres cosas:

1. Proporciona tu lista a Snyk

Los equipos de seguridad y plataforma definen qué servidores MCP están aprobados a partir de un inventario existente, una lista seleccionada manualmente o los servidores que Evo ADS ya detectó durante el descubrimiento. Esta se convierte en la política de referencia con la que se evalúa a cada agente de la flota. Puedes hacerlo manualmente o simplemente pedirle a Evo en el chat que lo haga.

2. Detecta el uso que incumple la política

Una vez establecida la política, Evo ADS monitorea continuamente la actividad de MCP en las máquinas de los desarrolladores y muestra cada caso en que un agente intenta acceder a un servidor que no está en la lista aprobada, ya sea una instalación local aislada o un patrón que se repite en toda la flota. No es necesario bloquear nada para que esta visibilidad sea útil; para muchos equipos, saber a qué se conectan realmente los agentes es el primer inventario real que han tenido.

3. Controla el uso en tiempo de ejecución

Aquí es donde la visibilidad se convierte en control. Evo ADS puede registrar el uso no autorizado de MCP con fines de auditoría o bloquearlo por completo, directamente en el endpoint, cuando un agente intenta conectarse; no después, ni dependiendo de que el agente decida cumplir.

MCP Governance funciona donde ya se ejecutan tus agentes. Está disponible hoy en Claude Code, Cursor, Codex y GitHub Copilot, y se aplica mediante hooks ligeros que funcionan junto al agente, en lugar de enrutar su tráfico a través de un proxy o gateway independiente. Evo ADS también usa este enfoque para analizar código de forma segura desde el inicio, por lo que los equipos no tienen que cambiar cómo se conectan los agentes a las herramientas, implementar infraestructura nueva ni aceptar un nuevo punto de falla en la ruta de ejecución del agente. La política se administra de forma centralizada; su cumplimiento se aplica localmente, justo donde se toma la decisión de usar un servidor MCP.

Qué sigue para el control del comportamiento de los agentes

Lo llamamos deliberadamente el primer caso de uso, no una historia terminada. MCP Governance responde: «¿Tiene este agente permiso para acceder a esta herramienta?». Es una pregunta necesaria, pero no la única. Un agente que trabaja exclusivamente con un servidor MCP aprobado aún puede ejecutar un comando destructivo de shell o enviar datos confidenciales a un lugar donde no debería estar, y MCP Governance por sí solo no lo detectará.

Ese es el siguiente paso para Evo ADS. En las próximas semanas, ampliaremos el alcance del cumplimiento más allá de las listas de permitidos de MCP para detectar y bloquear las acciones que realizan los agentes. También pasaremos de una lista estática a una política de MCP que los equipos podrán alimentar directamente desde un repositorio de Git o una página de Confluence con Evo MCP, y avanzaremos hacia el cumplimiento basado en el riesgo, para que la política refleje el riesgo real de cada servidor en vez de aplicar una autorización o denegación fija.

Además, durante el resto del año ampliaremos la cobertura de ADS para controlar el acceso no autorizado a datos confidenciales, ofrecer protección contra la inyección de prompts y evitar la exposición de secretos en agentes. También aplicaremos a las Agent Skills el mismo modelo de descubrimiento, clasificación y cumplimiento que MCP Governance presentó.

Es necesario controlar lo que usan los agentes. Controlar lo que hacen, en el momento en que lo hacen, es lo que hace que ese control sea real. MCP Governance es la primera prueba de ello y ya está disponible.

¿Quieres ver MCP Governance en acción? Agenda una demostración o explora Evo Agentic Development Security para descubrir cómo Evo ADS protege lo que los agentes usan, hacen y generan a lo largo del ciclo de vida del desarrollo impulsado por IA.