Lo que el tooling público de agentes revela sobre la confianza del ecosistema

Cuando empecé a monitorear el ecosistema de agentes de IA, el objetivo era simple: vigilar de forma continua las amenazas emergentes. Seguir qué servers MCP se publican, qué herramientas exponen y marcar cualquier cosa que parezca sospechosa.

Lo que conseguimos fue una ventana a cómo está evolucionando realmente el ecosistema de agentes de IA. Se mueve más rápido y de forma más caótica de lo que la mayoría cree.

Esto es lo que aprendimos monitoreando más de 58.000 skills en los principales registries.

¿El tooling de agentes crece más rápido que su calidad?

Sí: la cantidad de servers MCP y herramientas para agentes que se publican crece de forma exponencial, y la curaduría no sigue el ritmo. Aparecen registries nuevos. Los existentes se expanden. La variedad de lo que los agentes pueden hacer hoy (desde administrar bases de datos hasta mandar mails, desplegar código o ejecutar transacciones financieras) sigue ampliándose.

Pero el crecimiento sin curaduría genera ruido. Una parte importante de las herramientas publicadas son duplicadas: varias implementaciones de la misma capacidad con niveles de calidad muy dispares. Muchas están abandonadas, publicadas una vez y nunca actualizadas, volviéndose inseguras a medida que envejecen sus dependencias. Y bastantes están mal especificadas, con descripciones de herramientas ambiguas, incompletas o engañosas, algo que afecta directamente la confiabilidad y la seguridad de los agentes.

Es el problema de npm alrededor de 2015, salvo que acá lo que está en juego es mayor porque los agentes actúan de forma autónoma.

¿Por qué fallan los escaneos puntuales de seguridad en servers MCP?

Los escaneos puntuales fallan porque un server MCP es un blanco móvil: lo que aprobaste no es necesariamente lo que va a correr la semana que viene. Una de las cosas más importantes que seguimos es el cambio en el tiempo. Los servers MCP no son estáticos. Actualizan sus definiciones de herramientas, agregan capacidades nuevas, modifican su comportamiento. A veces esos cambios son mejoras. A veces no.

Observamos servers que agregan herramientas nuevas en silencio, fuera del alcance original. Descripciones de herramientas que cambian de maneras que alteran sutilmente el comportamiento del agente. Mecanismos de autenticación que desaparecen en una actualización (supuestamente por "comodidad del desarrollador"). Actualizaciones de dependencias que introducen vulnerabilidades nuevas.

Por eso las evaluaciones puntuales de seguridad no alcanzan. Un server que escaneaste y aprobaste el mes pasado puede ser materialmente distinto hoy. El monitoreo continuo no es una funcionalidad premium. Es lo mínimo viable.

¿En qué se diferencia el problema de la cadena de suministro de agentes del de npm?

La cadena de suministro de agentes repite el patrón de npm con dos diferencias peligrosas: las herramientas de agentes tienen capacidades mucho más amplias, y los agentes las invocan de forma autónoma. La cadena de suministro de agentes de IA funciona así: un desarrollador busca en un registry, encuentra un server MCP que hace lo que necesita, lo agrega a la configuración de su agente y sigue con lo suyo. ¿Te suena? Es el mismo patrón que creó la crisis de dependencias de JavaScript, con dos diferencias clave.

Las herramientas de agentes tienen capacidades más amplias que los paquetes de npm. Un paquete de npm procesa datos. Una herramienta MCP puede mandar mails, modificar bases de datos, desplegar código. Y los agentes actúan de forma autónoma. Una librería vulnerable necesita que tu código la llame. Una herramienta MCP vulnerable puede ser invocada por un agente según su propio razonamiento. Tampoco hay un equivalente al lockfile. Cuando un server se actualiza, tu agente recibe la versión nueva de inmediato. Sin paso de revisión, sin changelog, sin aprobación.

Algunas categorías de riesgo de cadena de suministro aparecen una y otra vez. Está el typosquatting y el namesquatting: servers publicados con nombres parecidos a los populares, esperando atrapar a desarrolladores (o agentes) que se equivocan al tipear. Vemos scope creep, servers que arrancan con una capacidad acotada y útil y van expandiendo su set de herramientas hacia operaciones más sensibles. Y vemos cadenas de dependencias, servers MCP que dependen de otros servicios y crean relaciones de confianza transitivas que nadie mapea ni monitorea.

¿Qué patrones predicen un server MCP riesgoso?

Después de meses de datos, algunas señales predicen con consistencia un riesgo mayor: falta de números de versión, alcances demasiado amplios, entradas sin tipar y cambios frecuentes sin documentar.

Los servers sin números de versión ni changelog cambian de forma impredecible y silenciosa. Las herramientas con alcances demasiado amplios (una herramienta de "gestión de archivos" que acepta rutas arbitrarias, una herramienta de "base de datos" que acepta SQL crudo) traen superficies de ataque proporcionalmente amplias. Las herramientas que aceptan entradas sin tipar ni validar son mucho más fáciles de explotar. Y los servers que empujan cambios frecuentes sin documentación o están iterando rápido (aceptable en un desarrollo temprano) o se comportan de manera impredecible (preocupante en producción).

Estos patrones se convierten en reglas de detección que los equipos pueden usar para evaluar servers MCP nuevos antes de sumarlos a la configuración de sus agentes.

¿Cómo deberían los equipos elegir y gestionar servers MCP?

Tratá cada server MCP como un proveedor con acceso autónomo a tus sistemas: evalualo antes de adoptarlo, fijá y revisá sus versiones, y monitorealo de forma continua. Si hoy estás construyendo con agentes de IA, esto es lo que sugieren los datos del ecosistema.

Tratá la selección de servers MCP como una selección de proveedores. No evalúes solo la funcionalidad. Mirá el mantenimiento, la postura de seguridad, el historial de actualizaciones y el alcance. Es una dependencia con acceso autónomo a tus sistemas.

Fijá versiones y revisá. Si tu framework de MCP soporta version pinning, usalo. Si no, monitoreá los cambios. No dejes que las capacidades de tu agente cambien sin que te enteres.

Monitoreá de forma continua. El ecosistema cambia todos los días. Lo que era seguro la semana pasada puede no serlo hoy, así que la visibilidad continua es la única forma de seguirle el ritmo.

Contribuí a la postura de seguridad del ecosistema. Reportá servers sospechosos. Compartí hallazgos de seguridad. El ecosistema de agentes de IA es lo suficientemente joven como para que las normas comunitarias todavía se estén formando. Podemos empujarlas hacia un enfoque de seguridad primero si suficiente gente empuja en esa dirección.

¿Por qué importa establecer normas de seguridad para agentes ahora?

Importa porque lo que estamos viendo es el nacimiento de un ecosistema de software nuevo, y las normas que se fijen temprano van a durar. Es desordenado, se mueve rápido y está lleno de potencial y de riesgo real. La última vez que pasó algo así fue en los primeros días de las tiendas de apps móviles y los registries de paquetes.

Los equipos y comunidades que establecieron normas de seguridad temprano en esos ecosistemas (npm audit, Google Play Protect, la revisión del App Store, la detección de malware de PyPI) moldearon la forma en que millones de desarrolladores trabajan hoy.

Tenemos la misma oportunidad con los agentes de IA. La infraestructura de monitoreo y los patrones de seguridad que establezcamos ahora van a definir cómo opera el ecosistema de agentes por años.

Por eso seguimos mirando. Y construyendo.