CrossSessionMemoryGuard: vigilando la exfiltración de memoria cross-session en agentes multi-tenant TL;DR Los agentes con memoria persistente compartida entre usuarios/sesiones pueden filtrar datos de un principal a otro sin que nadie lo observe.
CrossSessionMemoryGuard es un sensor read-only que 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.
El problema: la confidencialidad read-time no está vigilada 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 — 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ó.
El hueco de mercado, con evidencia verificable 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 (: 4.632 repos, : 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.
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.
Qué hace el sensor 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 ().
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).
Limitaciones actuales 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 no puede listar "todo lo visible": query vacía → error (); comodines y escapes FTS (, ) → 0 resultados; cap duro de 20 resultados por query — y hasta siguen devolviendo 20 (default: 10); la cobertura es función del conjunto de queries: con 15 queries amplias cubrimos el 87,9% de las observaciones reales (80/91), con 23 el 96,7%, y solo se llega al 100% con queries hechas a medida de las filas que faltaban — es decir, hay que saber ya qué buscar.
Ese cap no es un artefacto de nuestra bas