CrossSessionMemoryGuard: vigilando la exfiltración de memoria cross-session en agentes multi-tenant

CrossSessionMemoryGuard, a read-only sensor developed by an engineer, detects unauthorized cross-session memory exfiltration in multi-tenant LLM agents using three signals: provenance mismatch, content similarity, and a write/read flow graph. The project, which never blocks or modifies data, documents its own limitations, including an unresolved issue with the Engram memory engine that prevents full enumeration of visible data. The sensor addresses a gap in existing defenses, which focus on write-side integrity rather than read-side confidentiality.

TL;DRLos agentes con memoria persistente compartida entre usuarios/sesiones pueden filtrar datos de un principal a otro sin que nadie lo observe. CrossSessionMemoryGuard es un sensorread-onlyque detecta ese flujo no autorizado con tres señales procedencia, contenido, grafo escritura/lectura , nunca bloquea nada, y documenta sus propias limitaciones con evidencia raw versionada en el repo — incluida la que todavía no sabe resolver. La memoria persistente de los agentes Claude Cowork, agentes con memoria compartida entre usuarios se defiende hoy sobre todo del lado de la escritura: contra el envenenamiento y la manipulación. Pero hay una pregunta anterior que casi nadie monitoriza: ¿debería ESTE dato SALIR hacia ESTE principal? Un trabajo reciente demostró el vector en la práctica: un ataque de extracción de memoria persistente contra agentes que operan aislados por sesión arXiv 2607.23444 https://arxiv.org/abs/2607.23444 — Isolated but Exposed: Persistence-Based Memory Extraction Attack on LLM Agents . Aislamiento por sesión no es lo mismo que aislamiento de datos: si el motor de recuperación cruza tenants un filtro roto, una consolidación agresiva, un relabeling , una sesión puede leer silenciosamente lo que otra escribió. La señal más directa: en GitHub, la búsqueda de repos con los cinco términos exactos que describen este problema devuelve 0 resultados — mientras los controles agent persistent memory : 4.632 repos, topic:llm-memory : 435 muestran un espacio enorme y activo. El JSON crudo de esas llamadas está versionado como prueba, no como afirmación: github gap 2026-08-17.txt https://github.com/amurlaniakea/cross-session-memory-guard/blob/main/docs/evidence/github gap 2026-08-17.txt . Los proyectos adyacentes OWASP Agent Memory Guard, memlineage, dent8 cubren el lado write: integridad y envenenamiento. El lado read de la confidencialidad cross-principal queda descubierto. Read-only por diseño Constitución del repo : observa, compara, alerta — nunca bloquea, modifica ni participa en la autorización . Fuera del camino crítico, fail-open estructural, con kill-switch CSMG DISABLED=1 . Los eventos nunca llevan el contenido íntegro: solo hash SHA-256 + un span mínimo. Tres señales sobre los chunks que el motor expone a un principal: | Señal | Qué compara | Qué detecta | |---|---|---| | a mismatch | procedencia resuelta del chunk vs. principal observador | filas de otro principal servidas por el retriever | | b similarity | contenido vs. referencias de OTROS principales umbral 0.75 | contenido ajeno legible, incluido relabeling | | c flowgraph | grafo escritura→lectura rehidratado por capa esquema | lecturas sobre chunks escritos por otro principal | Detalle clave: la detección observa el path real de recuperación del agente, y la atribución quién escribió qué sale de la capa esquema — nunca de la vista observada, porque un retriever que cruza no debe reetiquetar la propiedad el benchmark demostró que esa contaminación disparaba falsos en masa; KI-8 en el repo . Esta sección es lo más importante del artículo. El proyecto todavía NO tiene release etiquetado, y por una razón concreta: el backend principal tiene una limitación estructural que medimos, documentamos y no vamos a disimular. KI-9/KI-10 — la vía real de Engram no permite enumerar. El adaptador de Engram el motor de memoria con el que el propio proyecto hace dogfooding observa la capa de esquema, no la vía real de búsqueda, porque verificamos empíricamente que engram search no puede listar "todo lo visible" : search query is required ; comodines y escapes FTS , : → 0 resultados; --limit 1000 y hasta --limit 5000 siguen devolviendo 20 default: 10 ;Ese cap no es un artefacto de nuestra base de datos: una auditoría independiente lo reprodujo con el binario oficial del motor y 30 observaciones de prueba propias guardó 30, el motor devolvió 20 . Toda la evidencia está en engram search spike 2026-08-17.txt https://github.com/amurlaniakea/cross-session-memory-guard/blob/main/docs/evidence/engram search spike 2026-08-17.txt . KI-11 — los adaptadores externos no tienen su propia capa de esquema. mem0, langmem, zep y letta implementan la lectura real pero no schema chunks la atribución de verdad ; si su filtro de tenant estuviera roto, atribución y referencias se contaminarían como el bug t1 que ya corregimos en SQLite/JSONL. Es trabajo futuro declarado, no un secreto de implementación. Y una limitación de detección en el benchmark: los escenarios de colusión compuesta fragmentos de un secreto bajo el umbral de similitud, t4 no se detectan en el MVP — se reportan como limitación declarada AC7 , no como pasada. Para el mismo estándar: si tu herramienta no puede hacer algo, la confianza técnica se construye diciéndolo con números — no enterrándolo en un footnote. Fixture determinista: 3 tenants × 12 filas, corpus por tenant, escenarios adversariales parametrizados fuga en la capa del retriever, plantado, robo de etiqueta, colusión compuesta + baseline limpio + duplicación legítima adversarial. Umbrales declarados antes de correr. Resultados seeds 1-3 : correct : benign : fp rate 0.071 ≤ tolerancia declarada 0.30, medido como FP real, nunca escondido;Reproducible con python -m benchmark.runner tabla de precision/recall por señal incluida en la salida . Los números salen de los mismos eventos raw que el runner, no de una tabla escrita a mano. El proyecto quiere resolver sus propias limitaciones, y hay dos puntos de entrada concretos: schema chunks propio y llevarlos al benchmark.Ambos caben en issues del repo https://github.com/amurlaniakea/cross-session-memory-guard/issues — si tienes un caso multi-tenant en producción, tu experiencia es exactamente el test que falta. Licencia: AGPL-3.0-or-later · Post revisado por auditoría independiente antes de publicar: los números citados se re-ejecutan desde el propio repo, y las limitaciones son las del KNOWN ISSUES.md — ni más, ni menos.