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 — 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.
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.
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 — 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.