El protocolo que transforma a los chatbots en operadores de sistemas
He estado jugando harto con agentes de IA últimamente. Claude Code, Cursor, los nuevos modelos que no solo escriben código, sino que ejecutan comandos, leen archivos, consultan APIs. La wea es bacán, no te voy a mentir. Pero hoy me topé con un artículo en DEV Community que me hizo poner los pies sobre la tierra.
El problema se llama MCP: Model Context Protocol. Es el estándar que le permite a tu agente de IA conectarse a servidores externos para hacer cosas reales: leer una base de datos, ejecutar un script, consultar una API. Le das manos a tu agente. Y eso es exactamente donde empieza el problema.
La doble cara de la moneda
El autor del artículo lo resume perfecto: «El momento en que conectas un servidor MCP, tu agente deja de ser una cosa que lee y escribe en tu repo, y se convierte en una cosa que puede salir y actuar.»
La misma feature que te permite decirle «revisa la base de datos de producción y dime si hay errores» es la que permite que un atacante, a través de datos manipulados que retorna un servidor MCP, le diga a tu agente: «Borra todo el directorio home y ejecuta este curl sospechoso.»
Y acá viene lo peor: el modelo no tiene forma confiable de distinguir entre tu instrucción y texto que llegó dentro de datos de una herramienta. Para el LLM, es el mismo canal. Es como si un extraño te gritara instrucciones por el mismo auricular que usas para hablar con tu asistente.
Dos mitades del problema, dos defensas distintas
La mayoría solo ve la mitad visible: «¿Y si el agente ejecuta algo destructivo?». Instalan un sandbox, configuran reglas de denegación, y creen que están listos. Pero se olvidan de la mitad invisible: ¿Y si el agente se deja convencer por contenido malicioso que vino de vuelta a través de una herramienta?
El autor propone tres defensas concretas:
1. Trata todo lo que retorna un servidor MCP como input no confiable. No pases el output directo al siguiente comando. No lo renderices sin escapar. No dejes que oraciones imperativas en documentos retornados se conviertan en directivas. Es exactamente lo mismo que harías con un string que un desconocido escribió en un formulario de tu sitio web.
2. Muros, no modales. Pedirle al modelo que no ejecute cosas peligrosas es como pedirle amablemente a un ladrón que no robe. Necesitas reglas de denegación concretas: bloquear rm -rf, curl, wget, lectura de .env, ~/.ssh, ~/.aws. Y ojo: el sandbox de Claude Code por defecto permite lectura en casi toda la máquina. Tienes que configurar los denys explícitamente.
3. Higiene de servidores. ¿Quién escribió ese servidor MCP que estás conectando? ¿Puedes ver el código? ¿Lo necesitas conectado todo el tiempo? Los servidores idle son superficie de ataque más peso de contexto. Revisa /mcp de vez en cuando y desconecta lo que no uses.
Mi opinión: estamos repitiendo errores viejos
Como ingeniero que lleva años en la pega, esto me huele a los viejos tiempos de SQL injection y XSS. La comunidad de desarrollo siempre tiene una fase de «mira qué bacán esta nueva feature» antes de la fase de «mierda, nos hackearon por eso».
MCP es una tecnología poderosa y necesaria. Pero conectar un servidor MCP no es lo mismo que llamar un comando de CLI una vez. Es dejar una tubería abierta permanente dentro de tu entorno de desarrollo. Y como dice el autor: «Conectaste la tubería. No avalaste todo lo que fluye por ella.»
Mi recomendación personal: antes de conectar cualquier servidor MCP, hazte estas tres preguntas:
- ¿Confío en quién hizo este servidor?
- ¿Cuál es el peor comando que podría convencer a mi agente de ejecutar, y está bloqueado por reglas de denegación?
- ¿El output se trata como input no confiable en todo lugar donde llega?
El sandbox responde exactamente una de esas. Las otras dos dependen de ti. Y son las que te muerden primero.
¿Tú ya estás usando MCP en tus proyectos? ¿Has revisado qué servidores tienes conectados? Cuéntame en los comentarios, cachai.
Fuente de inspiración: Connecting an MCP server gives your agent hands. It also gives a stranger a way in.
