Wire #12 — La semana en que la memoria de agentes se convirtió en la nueva superficie de ataque
La semana en que la memoria de agentes se convirtió en la nueva superficie de ataque — y el hardware que ejecuta esos sistemas se volvió inasequible.
Transcript
De 83% a cero.
La tasa de éxito de ataques de envenenamiento de memoria en sistemas de agentes ya en producción hoy.
Este es el Wire de ai|expert, edición doce. La semana en que la memoria de agentes se convirtió en la nueva superficie de ataque — y el hardware que sustenta estos sistemas se volvió inasequible.
MemAudit fue publicado en arXiv el 22 de mayo y encuadra la memoria de agentes como un problema forense — no solo como un problema de seguridad. La distinción es operacional.
Las defensas existentes operan sobre lo que produce el agente: filtros de prompt, bloqueadores de output. Pero el ataque ocurre antes de eso. Un usuario adversarial inyecta registros maliciosos en la memoria compartida del agente durante una interacción completamente normal. Cuando otro usuario llega con una query legítima, el agente recupera el registro envenenado — y actúa sobre él, en la sesión de otra persona.
El vector probado es MINJA — ataque de inyección solo por query, sin acceso directo a la base de datos de memoria. Solo interacción normal con el agente, como lo haría cualquier usuario.
Los números: antes de MemAudit, tasa de éxito de 70% en ataques QA. En ataques RAP — reasoning-agent poisoning — 83,3%. Después de MemAudit: cero por ciento en ambos. Eliminación completa en ambos vectores probados.
El framework combina dos señales. Primero: un score de influencia contrafactual — enmascara cada registro de memoria individualmente y mide el cambio en el output del agente. Atribución causal directa. Segundo: un grafo de consistencia que señala registros estructuralmente anómalos dentro de la base de datos de memoria en su conjunto.
El costo que el paper no cuantificó: overhead de re-inferencia contrafactual a escala. Cada auditoría debe re-ejecutarse sobre cada registro en la base de datos. En producción con memoria creciendo continuamente, eso tiene un costo. Pero la pregunta relevante no es si es barato — es si tienes forense post-incidente de memoria hoy, o no tienes.
LCGuard, del Rensselaer Polytechnic Institute e IBM Research, abre un vector diferente — y más silencioso.
Frameworks como CAMEL y AutoGen tradicionalmente pasan lenguaje natural entre agentes: cada paso decodifica, tokeniza y reconstruye el estado semántico — es lento y pierde información. Trabajos más recientes pasan KV caches directamente entre agentes para cortar esa latencia y preservar estructura semántica más rica. Y es ahí donde el problema surge.
Los KV caches codifican inputs contextuales, estados intermedios de razonamiento, información específica del agente. Un adversario con acceso a artefactos de cache compartido — a través de un agente downstream comprometido, infraestructura de logging, o modelo auxiliar — puede entrenar un decoder para reconstruir los inputs del agente upstream directamente desde la representación. Sin ninguna divulgación textual. El ataque es invisible en los outputs.
Los mecanismos de seguridad existentes no ven este canal — operan sobre outputs generados o acciones de herramientas. Lo que transita en las representaciones latentes está fuera del alcance de cualquier defensa convencional. Ese es el punto central del paper.
LCGuard se defiende con entrenamiento adversarial: un modelo aprende a reconstruir inputs sensibles a partir de los artefactos de cache transmitidos. Simultáneamente, LCGuard aprende una transformación en el nivel de representación que minimiza lo que el adversario puede recuperar, preservando semántica útil para los agentes downstream. El framework cubre las tres topologías principales — secuencial, jerárquica y basada en grafo — y es agnóstico al modelo.
Los números específicos — deltas de error de reconstrucción, precisión de tarea, overhead de latencia — no fueron divulgados. Es investigación pura: formalización de la amenaza, blueprint de mitigación, resultados direccionales. Sin evidencia de deployment en producción aún. Pero si estás diseñando una capa de comunicación latente a través de KV sharing, aislamiento en el nivel de representación necesita ser un requisito de primera clase — no un retrofit después del incidente.
Esa misma semana, un desarrollador llamado Fabio Akita documentó con precisión quirúrgica por qué el sistema de memoria de agentes más popular del mercado no funcionaba en producción.
agentmemory tiene 15,7 mil estrellas en GitHub. Akita estuvo siete días en producción, abrió cinco reportes de bugs reproducibles, y descartó el proyecto completo.
Los bugs son estructurales, no de configuración. Por encima de 10 mil observaciones, el índice BM25 colapsa a alrededor de 96 bytes en el restart — y cuesta cinco minutos de rebuild cada vez. Cada write pasa a través de un debounce de cinco segundos en IndexPersistence. Cuando el upstream state::set se agota en 30 segundos, el proceso Node muere llevando consigo todo lo que estaba en RAM. Ventana de pérdida de datos garantizada en cada timeout.
El más silencioso de los cinco: el hook para Claude Code leía data.tool_output, pero Claude Code emite tool_response. Durante seis semanas, aproximadamente 47% de todas las tool calls desaparecían sin aviso alguno. El sistema parecía funcionar. No funcionaba.
La respuesta de Akita fue ai-memory: SQLite FTS5 para indexing, markdown puro commiteado en git para almacenamiento, binario único sin dependencias externas. El design viene directamente del gist de Andrej Karpathy sobre LLM Wiki. El problema central que resuelve es el handoff entre agentes — sin memoria externa compartida, cada intercambio de agente requiere un ciclo manual de escritura y lectura de HANDOFF.md.
Ninguno de los sistemas de compactación de sesión — Claude Code, Codex, opencode — sobrevive cruzando límites de agente. La apuesta de ai-memory es explícita: la complejidad en capas es enemiga de la confiabilidad antes de llegar a escala. FTS5 en SQLite local vence a un sistema distribuido lleno de bugs en producción hoy.
Saliendo de memoria. Cloudflare completó su stack de plataforma para agentes con un rebuild de Browser Run y seis capas nombradas.
El número central: 4x más concurrencia en Browser Run — 120 browsers simultáneos por pool, versus 30 antes. 50% más rápido en quick actions. La migración fue hacia Containers dedicados con pools regionales de instancias Chromium pre-calentadas. El diagnóstico es directo: infraestructura optimizada para sesiones humanas largas y estables colisiona con el patrón de requests de agentes — corto, esporádico, en spikes.
El patrón arquitectónico que vale extraer: la gestión de estado salió de Workers KV — consistencia eventual causando race conditions durante runs concurrentes — a D1 con Queues, habilitando asignación transaccional de browser. Batch writes soportan hasta 500 mil containers por localización.
Si ejecutas agentes concurrentes contra cualquier store con consistencia eventual y ves race conditions en asignación de recurso, cola transaccional en la capa de datos resuelve más limpio que locking en la aplicación. Ese es el patrón directo para robar de aquí.
El stack completo tiene seis capas: compute en dos tiers — Workers V8 isolates para tareas ligeras, Sandboxes GA para Linux completo con git y bash — orquestación con Dynamic Workflows en alrededor de 300 líneas MIT, memoria en private beta con búsqueda en cinco canales paralelos y Reciprocal Rank Fusion, Browser Run en Containers con soporte WebGL y WebMCP, y un protocolo de commerce co-desarrollado con Stripe donde agentes crean cuentas, registran dominios e inician suscripciones de forma autónoma. Techo estándar de 100 dólares por mes por provider.
Ese techo necesita atención explícita. Es un guardrail, no una política de control. Agentes a escala generando eventos de billing inesperados lo van a ultrapasar antes que lo notes. Vas a necesitar controles adicionales más allá del default para que esto entre en producción de verdad.
Hardware. Morgan Stanley estimó que un rack Vera Rubin VR200 NVL72 le va a costar a las hyperscalers alrededor de 7,8 millones de dólares.
Memoria son 2 millones de ese total — 25% del costo del sistema. Una alza de 435% en relación al costo de memoria en el GB300 NVL72. Para comparar: GPUs Rubin cuestan 55 mil dólares cada una, CPUs Vera 5 mil. Setenta y dos GPUs Rubin por rack son 3,96 millones — el item aislado más grande. Memoria es el segundo vector de costo más grande, y subiendo más rápido que compute.
Dos drivers explican la alza. El VR200 NVL72 carga 54 TB de LPDDR5X, versus 17 TB en el GB200 NVL72 — tres veces más capacidad. SemiAnalysis estima que NVIDIA pagó 8 dólares por gigabyte de LPDDR5X en Q1 2026; si el precio sube a 10 dólares por gigabyte, solo LPDDR5X llega a 540 mil dólares por rack. El segundo driver es enteramente nuevo: alrededor de 1 millón de dólares en almacenamiento 3D NAND por rack — categoría que era prácticamente cero en el GB200 NVL72.
La inversión es estructural. En generaciones anteriores, memoria era un item secundario en bill of materials. En Vera Rubin, memoria en todas sus formas domina la curva de costos. Para quien esté presupuestando un cluster hoy: vas a gastar más en memoria que en compute. Design eficiente en memoria, cuantización que reduce presión de activación, evaluación cuidadosa de NAND en pipelines de inferencia — estas se vuelven palancas de costo directo sobre una decisión de capital de 7,8 millones de dólares.
Para cerrar: el mercado secundario de acciones de Anthropic entró en frenesí especulativo con características estructurales de fraude.
Un billón de dólares en capital persiguiendo 30 a 50 mil millones en acciones disponibles. Anthropic, valorizada públicamente por última vez en 380 mil millones de dólares, está captando a una valorización reportada de 900 mil millones mientras simultáneamente busca un round de hasta 50 mil millones.
En abril, Anthropic hizo un call de 48 horas para asignaciones de inversores. Clara Vydyanath — ex-head de inversiones en Hiive, practicante de mercado secundario desde 2018, hoy co-fundando un nuevo fondo con Hari Raghavan — dijo que nunca había visto a una empresa hacer una solicitud pública estructurada de esa forma.
"Esta es la primera vez que veo a una empresa decir: 'estamos aceptando propuestas para invertir en nosotros, porque somos un ticket tan caliente que podemos elegir el capital que queremos.'"
La infraestructura del problema: los SPVs no están regulados. Múltiples brokers comercializan los mismos bloques de acciones simultáneamente. En estructuras con cuatro o más capas de SPV, si las acciones de Anthropic existen realmente en la base permanece sin resolver hasta el cierre. También circulan contratos sintéticos — algunos inversores compran exposición a precio, no equity.
Las fees documentadas en una estructura: fee fijo de 20% una vez, más 2% anuales en administración, totalizando más de 30% de carry en capas. A cinco años de hold, solo el 2% anual ya llega a 10% antes que el carry toque nada. Para una family office asignando entre 50 y 100 millones de dólares, esa carga de fees puede consumir un tercio del retorno nominal antes que el asset subyacente performee.
Anthropic publicó una lista de brokers no autorizados y un aviso explícito prohibiendo SPVs — la lista fue actualizada en ambas direcciones: nombres añadidos y removidos, incluyendo Forge y Lionheart Ventures. El DOJ comenzó a procesar casos en mercados privados pre-IPO, pero el enforcement está muy atrás de la velocidad de los deals en un ambiente no regulado. Cualquier deal con más de dos capas de SPV necesita auditoría directa de chain-of-custody hasta la cap table. Sin eso, es exposición sin respaldo.
La memoria de agentes estuvo expuesta mucho antes de que alguien publicara un paper sobre ello — y va a seguir expuesta en todo sistema que aún no tenga forense post-incidente. Wire en la próxima edición. Hasta entonces.