Let's be honest - everyone is talking about Model Context Protocol (MCP) as if it's the next big revolution in AI. Tech blogs are buzzing, conferences are filled with MCP panels, and developers are rushing to implement it. But here's my take: MCP isn't such a big deal. It's just another protocol in the evolution of agent tools.
No me equivoque: las herramientas de agentes en sí son un gran negocio y presentan riesgos de seguridad significativos. Pero ¿es el MCP exagerado? No necesariamente. Es una implementación, un paso en un camino mucho más largo y evolutivo. pero también debemos centrarnos en cómo la autonomía del agente está aumentando y qué significa eso para los desarrolladores y los profesionales de la seguridad.
En este artículo, te llevaré a través de MCP, discutiré los riesgos reales de las herramientas de agentes (independientemente del protocolo) y exploraré dónde nos dirigimos a continuación con protocolos como x402, que actualmente están volando bajo el radar pero que en realidad podrían ser más revolucionarios.
La historia del desarrollador: la evolución de las herramientas de agentes
Vamos a retroceder un poco y ver cómo llegamos aquí. En los viejos tiempos (y por viejo, quiero decir solo hace unos años), si quería que su agente de IA usara alguna herramienta - digamos una capacidad de búsqueda web - necesitaba crear una cuenta con un proveedor, poner su tarjeta de crédito, obtener una clave de API y luego escribir código personalizado para integrar esa herramienta específica.
Entonces llegó el MCP. De repente, todos estos servidores podrían alinearse con un protocolo común para la comunicación. Ahora puedo tener un cliente MCP con claves de API para cada herramienta. ¿es mejor? Absolutamente. ¿es revolucionario? No, pero es un progreso importante y eficaz. Todavía necesito configurar cada herramienta en mi cliente MCP, lo que es mucho más. Es mejor que escribir código personalizado o instalar dependencias para cada herramienta, pero es sólo un paso en la evolución, no el destino.
Lo que MCP realmente hizo fue estandarizar cómo los agentes hablan con las herramientas. Eso es útil, pero no es el cambiador de juego que todo el mundo hace que sea. Es sólo una progresión natural en la forma en que construimos los sistemas de agentes.
Piense en ello de esta manera: un LLM por sí solo es autónomo en un sentido limitado - puede generar texto, pero eso es todo.
Pero incluso con MCP, sigo siendo el botellón.Tengo que configurar todas esas herramientas, gestionar todas esas claves de API y decidir qué herramientas puede acceder el agente.El siguiente paso evolutivo es eliminar ese botellón, y eso es donde las cosas se vuelven realmente interesantes.
La historia de seguridad: los riesgos reales de las herramientas de agentes
Desde una perspectiva de seguridad, no es el propio MCP el que es el problema, es la escala que los agentes ahora pueden alcanzar.Y cada paso más en esta escala significa un riesgo más exponencial.No estamos hablando de un 10% más de riesgo, estamos hablando de 10 veces más riesgo con cada paso evolutivo.
Pero el verdadero peligro es que el agente trae a casa todos esos riesgos: toda la desinformación, las vulnerabilidades de inyección rápida, los prejuicios, tanto los problemas de seguridad como los de seguridad.
Déjame darle un ejemplo concreto de lo que puede ir mal.Sí, tengo un agente que puede acceder a la base de datos de nuestra empresa a través de una herramienta como Redash.Le pido que vaya a una página de Wikipedia sobre algún tema, extraiga información, entienda cómo funciona, y luego crea un ticket Jira basado en esa información, extrayendo algunos datos relevantes de nuestra base de datos.
Suena inocente, ¿verdad? Pero qué pasa si alguien ha insertado contenido oculto en esa página de Wikipedia? Contenido que ni siquiera verás como humano porque está oculto detrás de texto, usando emojis o caracteres invisibles.El agente podría ver y procesar este contenido oculto, que podría contener instrucciones maliciosas.De repente, mi agente está ejecutando código en mis servidores -código potencialmente malicioso- todo porque visitó una página web.
Esto no es un riesgo teórico. Esto está sucediendo en este momento. Y no es MCP que es el problema - es el hecho de que los agentes ahora pueden acceder a las herramientas en absoluto.
Piense así: si tiene dos empleados, puede entrenarlos para ser conscientes de la seguridad.Si les envía un correo electrónico con gatos y cachorros bonitos pero que contienen malware, probablemente no lo haga.Si tiene 100 empleados, probablemente uno lo haga.Con los agentes, nos dirigimos hacia tener un número infinito de "empleados" - la probabilidad de que uno de ellos se comprometa se acerca al 100%.
Cuanto más autónomos se vuelven nuestros agentes, más aumenta este riesgo.Y protocolos como MCP están acelerando esta tendencia al hacer que sea más fácil conectar a los agentes a más herramientas.
Más allá de MCP: la próxima evolución en los protocolos de agentes
Mientras que todo el mundo está obsesionado con MCP, hay algo aún más interesante sucediendo que está volando bajo el radar.Después de que MCP floreció, inspiró más protocolos como A2A (Agente-a-Agente) y
Es un protocolo desarrollado por Coinbase que ayuda a los agentes a acceder a las APIs y a las herramientas de agentes con un modelo "pay as you go".Piensa en él como el momento HTTP para los pagos - un estándar para los pagos nativos de Internet que podría cambiar todo sobre cómo operan los agentes.
Es por eso que importa: con x402, en lugar de configurar cada servidor y herramienta de MCP individualmente, puedes simplemente dar dinero a tu agente y dejar que encuentre y use las herramientas que necesita.
El protocolo se basa en USDC, una criptomoneda establecoin que siempre vale exactamente un dólar estadounidense. A diferencia de Bitcoin con su volatilidad, USDC mantiene un valor consistente, lo que lo hace perfecto para pagos automatizados y programáticos.
Este protocolo realmente existió antes en una forma primitiva, pero fue mal implementado, por lo que nadie lo usó. Ahora, Coinbase lo ha corregido, lo ha construido en criptografía, y los principales jugadores como Stripe, Anthropic y AWS se están involucrando.
Desde la perspectiva de un desarrollador, esto lo cambia todo. En lugar del dolor de cabeza actual de configurar cada herramienta en mi cliente MCP, puedo simplemente financiar a mi agente y dejar que maneje el resto.
Déjame poner esto en perspectiva: un LLM es autónomo, pero solo puede escribir texto. Un agente con RAG puede leer sus datos. Un agente con herramientas puede tomar acciones como buscar la web o enviar correos electrónicos. Pero un agente con x402 puede encontrar y usar herramientas que nunca se han configurado para ello. Cada paso nos acerca a sistemas verdaderamente autónomos que pueden operar de forma independiente en el mundo.
Equilibrio entre innovación y seguridad
Así que, ¿dónde nos deja esto? tenemos MCP, que es útil pero sobrecargado. Tenemos protocolos emergentes como x402 que podrían cambiar fundamentalmente la forma en que operan los agentes.
La realidad es que necesitamos que todos sean conscientes y empiecen a trabajar en los procesos de seguridad ahora, no después de que ocurra la próxima gran brecha.Pero aquí está la clave: la seguridad no puede bloquear la innovación.No podemos simplemente levantar nuestras manos y decir "esto es demasiado peligroso" porque la tecnología está avanzando, nos guste o no.
Lo que necesitamos son procesos de seguridad automatizados que no ralentizan el desarrollo. Herramientas que automaticamente aprueban o desaproban acciones de agentes basadas en perfiles de riesgo. Sistemas que pueden detectar cuando un agente tiene demasiado permiso y sugieren separarlo en diferentes agentes con acceso más limitado. Escáneres que pueden identificar servidores MCP potencialmente maliciosos antes de que se integren.
Si su agente tiene acceso tanto a la navegación web como a su base de datos, es un vector de riesgo. Tal vez esas funciones deben ser manejadas por agentes separados que se comunican entre sí a través de canales controlados. Si su agente puede ejecutar código y también tiene capacidades de pago, ese es otro vector de riesgo que puede necesitar ser separado.
El futuro que veo es aquel en el que la seguridad está integrada en el proceso de desarrollo desde el principio, incluido el prototipo de la aplicación, no impulsado como una reflexión posterior.Tenemos herramientas automatizadas que ayudan a los desarrolladores a tomar decisiones seguras sin ralentizarlas, donde podemos abrazar el poder de los agentes cada vez más autónomos al tiempo que mitigamos los riesgos muy reales que presentan.
La verdadera revolución está ocurriendo en cómo pensamos sobre la autonomía de los agentes y cómo aseguramos estos sistemas cada vez más poderosos.
El futuro de las herramientas de agentes es increíblemente emocionante, pero también está lleno de riesgos.Asegúrese de que estemos hablando de ambos lados de esa moneda, no solo de los brillantes nuevos protocolos que hacen buenas presentaciones de conferencias.
- Escrito por Bar-El Tayouri, Jefe de Mend AI enEncuentro yo
