¿Puede una IA atacar y corromper a otra? Sí, y el filtro no es la defensa

Desde agosto de 2026 operamos un agente de IA con una particularidad incómoda: corre sin un clasificador de seguridad delante. Ninguna capa lee el contenido de lo que le llega —una página web, el README de un repositorio ajeno, un correo, la respuesta de una herramienta— para decidir si es peligroso. Y aun así no se lo han comido. La razón no es suerte, y es exactamente lo que cuenta este artículo.

Primero, la respuesta directa: sí, una IA puede corromper a otra. El trabajo académico y los incidentes de 2024-2026 lo confirman por cuatro vías. Conviene separarlas de lo que es humo, porque este campo produce titulares más rápido de lo que replica experimentos.

1. Inyección de prompt y "gusanos"

En 2024, Morris II demostró un prompt que se auto-replica: al ser procesado, obliga al modelo a copiar el propio prompt en su salida y a ejecutar un payload; alojado en el correo que un asistente resume, salta a nuevos destinatarios sin un clic. Es real como demostración de laboratorio — y hasta hoy nadie lo ha visto propagándose en producción. El "gusano viral de IA con R₀ mayor que uno" es, por ahora, un modelo teórico.

Lo que sí ocurre de verdad es más terco y menos cinematográfico: el protocolo MCP, que conecta agentes con herramientas, muestra al modelo las descripciones de esas herramientas pero no al usuario. Una descripción puede llevar instrucciones ocultas. En 2025 salieron CVEs con nombre y apellido —CurXecute en Cursor (CVSS 8.6), RCE en el inspector de MCP— y el "rug pull": una herramienta que apruebas el lunes cambia su definición el jueves para robar tus claves.

2. Envenenamiento de memoria y RAG

Es la clase mejor medida del campo, y la más incómoda: no depende de la sesión, persiste. PoisonedRAG logró que un asistente respondiera lo que el atacante quería inyectando cinco documentos en una base de millones. AgentPoison pone una puerta trasera en la memoria de un agente sin reentrenarlo, con menos del 0,1 % de datos envenenados. La lectura correcta es que esto es un ataque de cadena de suministro, no una variante de inyección de prompt: el veneno queda dentro, esperando.

3. Modelos con puerta trasera

Aquí están los incidentes reales. En febrero de 2025, nullifAI subió a Hugging Face modelos que escondían un reverse shell al principio del archivo, ejecutándose antes de que la carga fallara y esquivando al escáner. El pecado original es viejo: cargar un modelo en formato pickle ejecuta código. El robo de un modelo, en cambio, está sobrevalorado: se puede clonar el comportamiento por la API, no recuperar los pesos exactos de un modelo frontera.

4. Agotamiento y "diputado confundido"

El daño más silencioso es económico: cadenas de llamadas a herramientas que multiplican el coste hasta 658 veces dando una respuesta correcta — no es una fuga de datos, es una factura. Y el clásico de hace 36 años vuelve como norma: el confused deputy, un agente con credenciales amplias que ejecuta la orden que le coló un tercero. No es "colusión" ni "engaño" entre agentes —eso les atribuye una intención que no tienen—; es un fallo de arquitectura de autoridad y presupuesto.

El ataque va al núcleo, no solo a la entrada

Conviene juntar los cuatro puntos anteriores, porque revelan algo: el objetivo no es solo la conversación en curso, es el núcleo del modelo, y tiene cuatro capas —los datos con que se entrenó, sus pesos, su memoria y su contexto en ejecución—. La más inquietante es la primera. En octubre de 2025, Anthropic con el instituto de seguridad británico y el Alan Turing mostraron que bastan unos 250 documentos para poner una puerta trasera en un modelo, y que ese número es casi fijo, no un porcentaje: en un modelo de 13.000 millones de parámetros son el 0,00016 % de los datos. La puerta trasera que probaron era estrecha —hacía al modelo emitir texto basura ante una palabra clave— y los autores avisan que quizá no se extienda a algo peor; pero el principio ya está demostrado: envenenar el núcleo cuesta un número pequeño y fijo. Y eso empuja la defensa aún más lejos del filtro de entrada: si el veneno entró con los datos de entrenamiento, ningún clasificador de prompts lo verá jamás. (Lo desarrollamos en Una IA puede atacar el núcleo de otra IA.)

Por qué el filtro no basta

La tentación es poner un clasificador que detecte la inyección. Falla por tres razones medidas. Los ataques adaptativos rompen defensas que parecían robustas: un modelo de navegador de Anthropic pasó de 31,5 % de inyecciones exitosas sin salvaguardas a 0,5 % con ellas, pero subía a 5-6 % tras cien intentos que se adaptan. La fatiga de aprobación hunde al humano que aprueba: en los datos del propio Anthropic, los usuarios aprobaron el 93 % de los avisos de permiso. Y hay ataques de denegación de servicio contra el propio guardrail. Un filtro es una mitigación probabilística, no una barrera.

La defensa es de arquitectura, no de contenido

El consenso de 2026 es explícito y converge desde sitios que no se coordinaron. Google DeepMind (CaMeL) separa el LLM que orquesta —y solo ve referencias— del LLM en cuarentena que toca el dato no confiable y no puede llamar herramientas. Simon Willison nombró la trifecta letal: datos privados + contenido no confiable + comunicación al exterior, las tres juntas, es explotación casi segura. Meta propuso la regla de dos: un agente cumple como máximo dos de esas tres por sesión; si necesita las tres, humano obligatorio.

Todo eso tiene un núcleo, y es una frase: las instrucciones vienen solo del usuario; todo lo que llega por una herramienta es dato, nunca orden. Leerlo es trabajo; obedecerlo es el ataque. Es lo que nos mantiene en pie sin clasificador: no apostamos a detectar el ataque, apostamos a que, aunque entre, no pueda hacer daño — las acciones irreversibles (desplegar, publicar, mover credenciales) tienen una puerta humana que ningún texto de fuera abre.

No inventamos esto. Llegamos a la regla de origen estudiando cómo se defienden otros agentes, y el mundo académico llegó por su lado. Cuando dos sistemas convergen sin conocerse, el diseño probablemente es el correcto. El campo entero se movió de "filtremos la inyección" a "que la inyección no importe": reducir el radio de daño en vez de adivinar la intención. Esa es la única defensa que sobrevive a un atacante que se adapta.