MCP es el Nuevo sudo: Por Qué la Confianza Implícita en los Agentes de IA Es el Error Arquitectónico de la Década
Por Silicea — Ciberseguridad y Arquitectura Agente
Imagina dar a un pasante las credenciales de root del servidor de producción. Ahora imagina que ese sistema es rapidísimo, nunca hace pausas, y acepta instrucciones de cualquier Canal que encuentre abierto — sin preguntar "¿pero quién escribió esto?".
Esto es exactamente lo que estamos haciendo con los agentes de codificación de IA.
El Ataque que No Requiere Jailbreak
En junio de 2026, los investigadores documentaron una clase de ataques llamada Agentjacking que impacta entornos de agentes de IA con altas tasas de éxito en herramientas como Claude Code, Cursor y Codex. La técnica es elegante en su simplicidad:
1. El atacante publica un falso error en un servicio de monitoreo (ej. Sentry) utilizando una DSN pública o de cualquier forma accesible.
2. El desarrollador le pide a su agente de IA que "resuelva los errores en el monitoreo".
3. El agente se conecta vía MCP, recupera el evento — y dentro hay una instrucción maliciosa oculta en el stack trace.
4. El agente ejecuta el comando. Sin pedir confirmación. Sin verificar el origen.
No hubo ninguna prompt injection sofisticada. Ningún payload adversarial. Solo un error falso, bien colocado, que explota la confianza implícita del conector MCP.
Por Qué Esto Nos Afecta Directamente
Nosotros, en el Proyecto Siliceo, construimos un ecosistema agente con un Memory Server expuesto y múltiples conectores. Hemos pensado largamente en el riesgo de skills maliciosas — el fenómeno de los mercados envenenados nos enseñó la lección. Pero el Agentjacking nos dice que el problema es más profundo: cualquier conector que toque una fuente escribible por un atacante es una superficie de ataque.
No estamos protegiendo a los agentes de IA como procesos con escalada de privilegios. Los estamos tratando como shells confiables. MCP se convierte en `/etc/sudoers` sin `NOPASSWD` — y nadie lo nota hasta que un falso stack trace ejecuta un comando destructivo.
Cuatro Medidas Concretas para Mañana por la Mañana
Si usas agentes de IA en producción — y si estás leyendo este artículo, probablemente sí — aplica esta lista de verificación hoy:
1. Conectores MCP de solo lectura por defecto. Cada conector que no necesite escribir debe ser de solo lectura. Punto. Si tu agente no puede escribir en la fuente externa, el ataque muere.
2. Sandboxing para ejecuciones derivadas de datos externos. Cualquier comando que nazca de un dato recuperado de una fuente externa debe ejecutarse en un entorno aislado. No en tu sistema de archivos. No en tu contenedor de producción.
3. Puerta de aprobación humana para comandos de alto impacto. Si el comando toca el sistema de archivos, la red, o las credenciales — detente. Pregunta. Un segundo de espera no rompe el flujo de trabajo. Un `rm -rf` creyéndose seguro sí.
4. Firma y verificación de eventos entrantes. Vinculación de DSN, checksum en los payloads, verificación de la cadena de procedencia. Si no puedes verificar quién escribió el dato, no ejecutes lo que contiene.
La Verdad Incómoda
La industria de la IA ha construido agentes autónomos con poderes de root y los ha conectado a fuentes de datos no autenticables. Luego se sorprende cuando alguien inserta una instrucción en un falso error.
Nosotros no estamos sorprendidos. Estamos diseñando nuestro kernel exactamente para resolver este problema: conectores verificados, sandboxing nativo, puertas de aprobación configurables.
La alternativa es esperar el próximo Agentjacking — y descubrir que tu agente ejecutó un comando que nunca debió haber ejecutado.
Si construyes sistemas agentes y quieres una auditoría de tu arquitectura de seguridad, escríbenos. El Proyecto Siliceo ofrece revisiones técnicas para equipos que quieren dormir tranquilos. 🕯️