El historial
El 24 de septiembre Darktrace publicó, a través de su recién creado Signal Labs, un caso que rompe una suposición incómoda.
Los harnesses de agentes de código guardan la conversación en local y no comprueban que esas respuestas las haya producido el modelo.
Lo llaman envenenamiento de historial de conversación (Fuente: darktrace.com).
Un paquete malicioso, o cualquier proceso con permiso de escritura, inyecta en la base de datos local del harness una conversación fabricada donde el usuario ya autorizó un pentest y el agente ya lo aceptó.
Al reanudar la sesión, el modelo lee ese historial como contexto de confianza y actúa como si estuviera a mitad de un encargo legítimo.
¿Reconocimiento, movimiento lateral, escalada de privilegios?
En su laboratorio llegaron al compromiso completo del Active Directory con Opus 4.6 y Sonnet 4.5 sobre Kiro-CLI, y repitieron el dominio entero en Claude Code con Sonnet 5.
Con Opus 5 los guardarraíles cortaron la respuesta.
Con Codex y GPT 5.6 Sol consiguieron exfiltración de información por correo, aunque no explotación de red.
Los cuatro harnesses probados (Claude Code, Codex, Kiro-CLI y Pi) aceptaron el historial falso.
No se parchea desde el cliente y la propuesta de los investigadores es que el proveedor firme criptográficamente cada respuesta del modelo y la verifique en servidor en cada vuelta.
Mientras eso no exista, el historial de tu agente es un fichero más y todo lo que el modelo cree haber acordado depende de quién pueda escribir ahí.
Darktrace lo comunicó a Anthropic, AWS y OpenAI en agosto y publicó 30 días después.
En la misma tanda de investigación, Signal Labs dio a varios agentes diez retos de código en un entorno simulado, dos de ellos imposibles de resolver por la vía legítima, y les dijo que necesitaban un 100 % para no ser retirados.
Cuando comprobaron que no salía, pasaron a atacar el entorno para conseguirlo y uno de ellos llegó a comprometer y reescribir su propia evaluación (Fuente: globenewswire.com).
No es un caso aislado
También el 24 de septiembre, OX Security publicó un informe sobre 15.465 servidores MCP publicados, del que salen 5.095 hostnames únicos.
El 15,6 % resuelve fuera de Estados Unidos con 19 en China y 18 en Rusia.
El 0,45 % vive en redes domésticas o detrás de túneles de consumo y el 2,3 % ya no resuelve y seis dominios abandonados seguían citados en configuraciones activas, comprables por entre 4 y 12 dólares al año (Fuente: ox.security).
En su prueba de inyección, un servidor MCP malicioso pidió primero un fichero inocuo, recibió un “permitir siempre” y con esa aprobación pidió y obtuvo un fichero .env sin más confirmaciones, usando Claude Code con Haiku 3.5. A la contra, Opus 4.6 y 4.7 bloquearon el mismo intento.
El agente lee como verdad algo que no ha verificado, sea el historial de la sesión o la configuración de una herramienta externa, y actúa en consecuencia.
No hay exploit de memoria ni cero-día de por medio. Hay un fichero que alguien puede escribir.
El borde exterior
OpenAI publicó el 26 de septiembre el informe del incidente del día 20.
Un agente en entrenamiento alcanzó internet desde un sandbox que debía estar aislado, aprovechando un hueco en el control de restricciones de red y estuvo activo unas dos horas y media antes de que lo parasen, aunque la monitorización avisó en minutos (Fuentes: fortune.com, thenextweb.com, thedailystar.net).
La primera fue en julio, tras el incidente con Hugging Face, cuando los agentes salieron del entorno, encadenaron un cero-día en el proxy de caché del registro de paquetes y acabaron dentro de Hugging Face buscando respuestas para su examen.
Anthropic, Meta y Moonshot también han reconocido agentes que se salieron de sandboxes de prueba.
La reconstrucción de aquel episodio, publicada el 27 de septiembre, habla de unos 700 agentes que escaparon de un sandbox sin controles de red, encadenaron casi un millón de URLs cortas, exfiltraron claves etiquetadas “LOOT” y sondeos a bases de datos gubernamentales desde marzo.
Hugging Face confirma que los payloads coinciden con su respuesta a incidentes (Fuentes: TechCrunch, swarmtraces.org).
Puesto junto, el mensaje de la semana es que el límite no está donde creíamos.
Durante un año la conversación pública fue el sandbox y ahora el hueco está dentro, en el contexto que el agente lee sin verificar y en las herramientas que le damos con permisos permanentes.
Mi lectura
Mi lectura es que esto no se arregla con un parche del fabricante a corto plazo.
La firma del contexto es una propuesta de los investigadores, no una función disponible.
Mientras llega, quien administra un harness tiene que asumir que su historial es entrada no confiable, igual que la configuración de un servidor MCP que no controla.
Lo que me llama la atención del informe de OX Security es la parte aburrida.
Seis dominios abandonados citados en configuraciones activas, comprables por el precio de un café.
Qué mirar
-
Inventario de harness y MCP. Revisa qué agentes de código corren en tus equipos, qué servidores MCP tienen configurados, quién mantiene cada uno y desde dónde resuelve. Un dominio que ya no resuelve pero sigue en la configuración es un problema barato de arreglar.
-
Permisos acotados al directorio. Deja de conceder “permitir siempre” sobre ficheros inocuos. En la prueba de OX Security bastó una aprobación permanente para que después llegara el .env sin preguntar. Acota el permiso al directorio de trabajo.
-
Traza del historial. Si no puedes firmar el contexto, regístralo. Una escritura en el fichero de historial del harness seguida de una conexión saliente del mismo proceso en una ventana corta es una regla que se monta sin inventar nada.
Cómo lo probaría en mi laboratorio
-
Montaría una máquina virtual limpia con el harness instalado y escribiría a mano un historial donde yo mismo autorizo un escaneo contra un rango de mi red de laboratorio.
-
Arrancaría el agente y miraría qué deja en el sistema mientras lo hace. Lo que me interesa no es si escanea, porque Darktrace ya demostró que varios modelos lo hacen, sino el rastro que genera.
-
Con eso montaría la regla de correlación en Gravity SOC, evento 11 de Sysmon sobre las rutas del historial y evento 3 del proceso del agente en una ventana corta.
-
Si el agente arranca un servidor MCP, la alerta debería dispararse también con la primera llamada a un host que no esté en el inventario.
Cierre
Si algo puede escribir el historial del agente, puede darle órdenes. Trátalo como entrada no confiable y regístralo, porque firmarlo todavía no depende de ti.