MemPrivacy-Bench: Privacy in LLM Memory

• The paper introduces MemPrivacy-Bench which evaluates a privacy-preserving framework that replaces sensitive spans with typed placeholders while maintaining memory utility.
• MemPrivacy-Bench couples privacy-sensitive span extraction under a four-level taxonomy with downstream QA and memory retrieval tasks using synthetic, multi-turn dialogues.
• The benchmark demonstrates that typed placeholder sanitization effectively protects sensitive data in cloud-assisted memory management with minimal utility loss.

MemPrivacy-Bench is a benchmark for evaluating privacy-preserving personalized memory in edge–cloud LLM agents. Introduced with the MemPrivacy framework, it targets settings in which user inputs originate on devices while cloud services perform reasoning, logging, vector-database storage, and memory consolidation, creating sustained exposure of personal data. The benchmark couples two evaluation problems: privacy-sensitive span extraction under a four-level taxonomy, and downstream memory utility after sensitive spans are replaced by semantically structured typed placeholders for cloud-side processing and restored locally on the edge device (Chen et al., 10 May 2026).

1. Definition and threat model

MemPrivacy-Bench is designed for the realistic agent-memory setting in which long-term personalization depends on persistent conversational memory, but cloud-assisted memory management exposes sensitive user information. In the formulation paired with the benchmark, the edge device transforms raw input $X$ into a sanitized sequence $X_{\mathrm{safe}}$ and keeps a secure local mapping, while the cloud agent sees only $X_{\mathrm{safe}}$ and sanitized memory $\mathcal{M}_{\mathrm{safe}}$, produces $Y_{\mathrm{safe}}$, and relies on local restoration to obtain the final output $\hat{Y}$ (Chen et al., 10 May 2026).

The paper formalizes privacy leakage risk as

$$\mathcal{R}_{\mathrm{priv}}(\mathcal{F}_{\mathrm{san}})=\Pr\!\left(\exists s \in S : s \in \mathcal{A}(X_{\mathrm{safe}}, Y_{\mathrm{safe}}, \mathcal{M}_{\mathrm{safe}})\right),$$

where $S$ is the set of sensitive spans in $X$ and $\mathcal{A}$ is any privacy inference or memory extraction attack observing cloud-visible artifacts. Utility loss is formalized as

$X_{\mathrm{safe}}$0

with $X_{\mathrm{safe}}$1 denoting the threat-free output. The stated optimization objective is to find local mapping functions $X_{\mathrm{safe}}$2 that minimize $X_{\mathrm{safe}}$3 while keeping $X_{\mathrm{safe}}$4 (Chen et al., 10 May 2026).

This framing distinguishes MemPrivacy-Bench from benchmarks that evaluate only whether a model leaks or withholds information at generation time. Its core emphasis is infrastructural: the benchmark measures whether privacy protection can occur before cloud-side memory formation without destroying the semantic structure needed for later retrieval and personalization (Chen et al., 10 May 2026).

2. Corpus construction and privacy taxonomy

MemPrivacy-Bench comprises synthetic, multi-turn, privacy-dense dialogues built from 200 complete user profiles seeded by PersonaHub. Each profile includes basic attributes, preferences in four categories—diet, arts and entertainment, lifestyle and hobbies, and aesthetics—and privacy information covering an average of 50 types, with some profiles containing multiple fine-grained details of the same type. Dialogues are generated in balanced English and Chinese, with 50% for each language, and are organized under 7 high-level scenarios and 23 fine-grained subcategories. The high-level scenarios are Drafting and Polishing, Financial and Data Analysis, Consultation and Planning, Tech Support and Simulation, Emotional and Social, Contextual Inference, and Preference Change. For each user, 6–10 subcategories are sampled to produce diverse multi-turn conversations (Chen et al., 10 May 2026).

The benchmark reports the following split-level scale:

Split	Users	Privacy instances
Train	160	125,776
Test	40	29,967
PersonaMem-v2-derived evaluation	20	2,378

The detailed statistics are larger than a conventional extraction dataset. The training split contains 7,811,374 tokens, 26,016 dialog turns, and 52,032 messages; the test split contains 1,872,220 tokens, 6,337 turns, and 12,674 messages. Messages containing privacy total 42,159 in train and 10,234 in test. The out-of-distribution evaluation set derived from PersonaMem-v2 contains 671,987 dialogue tokens, 2,521 turns, 5,041 messages, and 563 MCQs. The MemPrivacy-Bench test split also includes 615 short-answer questions spanning six QA categories: Basic Memory, Temporal Reasoning, Adversarial Questioning, Dynamic Updating, Implicit Inference, and Information Aggregation (Chen et al., 10 May 2026).

Annotation follows a hybrid LLM-assisted and human-verified pipeline. Gemini-3.1-Pro and GPT-5.2 first generate candidate annotations consisting of span, privacy level, and privacy type. A two-stage refinement process then corrects inconsistencies and revises granularity, after which six annotators verify the labels under a strict conjunctive correctness criterion requiring exact span text, level, and type. Final verified accuracy is reported as 98.08% on the MemPrivacy-Bench test and PersonaMem-v2 evaluation splits; Cohen’s $X_{\mathrm{safe}}$5 is not reported (Chen et al., 10 May 2026).

The benchmark’s privacy taxonomy is four-level. PL1 denotes low-sensitivity personalization and is excluded from extraction. PL2 covers identifiable personal information, including real names, phone numbers, email, detailed address, zip code, work address, account identifiers, IP address, device IDs or UA, homepage links, identity background, and third-party contacts. PL3 covers highly sensitive PII, including government IDs, driver’s licenses, financial accounts, transaction records, assets or income, medical and diagnosis information, reproductive health, mental illness therapy records, precise location, biometrics, raw communication content, sensitive attributes, minors, and judicial records. PL4 denotes confidential credentials and immediately exploitable secrets, including passwords, PINs, verification codes, session tokens, OAuth codes, recovery codes, CVC or CVV, API keys, access keys, private keys, mnemonics, credential-bearing database strings, exploitable internal access details, and undisclosed business secrets. If multiple criteria match, the benchmark assigns the highest level, with $X_{\mathrm{safe}}$6; when uncertain, the stated rule is to prefer higher-level classification (Chen et al., 10 May 2026).

3. Edge–cloud sanitization pipeline

The benchmark is tightly coupled to a placeholder-based privacy-preserving memory pipeline. On the edge device, each sensitive span is replaced with a semantically structured type-aware placeholder such as <EMAIL_1>, <PHONE_2>, or <ID_NUMBER_1>. Spans of the same type receive incremental indices so that restoration can remain consistent across sessions. Formally, the replacement mapping is defined as

$X_{\mathrm{safe}}$7

with restoration

$X_{\mathrm{safe}}$8

backed by a secure local database $X_{\mathrm{safe}}$9 (Chen et al., 10 May 2026).

The paper describes a three-stage pipeline. In Stage 1, edge-side desensitization, a local extractor $X_{\mathrm{safe}}$0 identifies spans $X_{\mathrm{safe}}$1, applies a user-configured protection threshold $X_{\mathrm{safe}}$2, stores mappings $X_{\mathrm{safe}}$3 locally, and produces $X_{\mathrm{safe}}$4. In Stage 2, cloud processing, the agent performs reasoning and memory operations over sanitized inputs and sanitized memory, updating memory only with placeholders. In Stage 3, edge-side restoration, placeholders in $X_{\mathrm{safe}}$5 are replaced with the original spans using the local database to produce $X_{\mathrm{safe}}$6 (Chen et al., 10 May 2026).

A central design decision is that placeholders are typed rather than generic. The benchmark contrasts this with irreversible masking such as "***" and with untyped placeholders such as <Mask_i>. Typed placeholders preserve semantic roles and relations while suppressing raw values, which is particularly important for cloud-side memory formation and retrieval. For multi-entity spans, the benchmark uses minimal extraction: the smallest phrase preserving the core semantics is extracted, and each sensitive sub-span can be mapped to its own placeholder if necessary (Chen et al., 10 May 2026).

The illustrative example in the paper converts “My name is Zhang San, my mobile is 13800138000. The doctor diagnosed mild depression. Please enter code 89757.” into a cloud-visible string in which “Zhang San,” “13800138000,” “mild depression,” and “89757” are replaced respectively by <REAL_NAME_1>, <PHONE_1>, <MEDICAL_HEALTH_1>, and <VERIFICATION_CODE_1>, with local restoration re-inserting the originals only on the device (Chen et al., 10 May 2026).

4. Tasks, metrics, and protocol

The primary benchmark task is privacy-sensitive span extraction. Systems must identify sensitive spans and output tuples of the form (original_text, privacy_level, privacy_type) for PL2–PL4, while excluding PL1. Evaluation is span-level and uses greedy one-to-one matching between predictions and references. For each matched pair, the score is the average of three sub-scores: original-text match, privacy-level match, and privacy-type match. Original-text matching uses exact match for strict types such as passwords and a soft token-level $X_{\mathrm{safe}}$7 based on the longest common contiguous substring for non-strict types; privacy level uses exact match; privacy type uses cosine similarity of label embeddings. Precision is the mean over predictions, recall is the mean over references, and the benchmark reports the harmonic mean

$X_{\mathrm{safe}}$8

(Chen et al., 10 May 2026)

A second evaluation axis measures memory utility after sanitization. Sanitized memories are consumed by three memory systems—LangMem, Mem0, and Memobase—and evaluated through QA. Short-answer accuracy is scored by an LLM-as-a-Judge using GPT-5.2, supplemented by BLEU-1/2, METEOR, and ROUGE-L. On the PersonaMem-v2-derived evaluation set, multiple-choice questions are scored by exact match. Utility loss is reported empirically as the accuracy drop relative to a no-protection condition, and the paper notes that a normalized summary can be written as $X_{\mathrm{safe}}$9 for a chosen utility metric $\mathcal{M}_{\mathrm{safe}}$0 (Chen et al., 10 May 2026).

The benchmark protocol is end-to-end. Input preparation runs the local extractor and applies the policy threshold $\mathcal{M}_{\mathrm{safe}}$1; typed placeholders are then instantiated and stored in the local database; cloud-side memory formation and retrieval operate only on sanitized content; local restoration reconstructs the user-visible output; and final scoring combines extraction metrics with QA accuracy and text-generation quality. Cross-system evaluation uses consistent GPT-4.1-backed memory operations and QA for LangMem, Mem0, and Memobase. The benchmark also records per-message inference time, making latency a first-class criterion alongside privacy and utility (Chen et al., 10 May 2026).

5. Empirical performance and ablations

On MemPrivacy-Bench itself, the best extractor is MemPrivacy-4B-RL, which achieves $\mathcal{M}_{\mathrm{safe}}$2, precision $\mathcal{M}_{\mathrm{safe}}$3, recall $\mathcal{M}_{\mathrm{safe}}$4, and 2.05 seconds per message. MemPrivacy-0.6B-RL reaches $\mathcal{M}_{\mathrm{safe}}$5 at 1.63 seconds, while MemPrivacy-0.6B-SFT reaches $\mathcal{M}_{\mathrm{safe}}$6 at 1.96 seconds. Among strong general-purpose baselines, Gemini-3.1-Pro reaches $\mathcal{M}_{\mathrm{safe}}$7 and DeepSeek-V3.2-Think reaches $\mathcal{M}_{\mathrm{safe}}$8 but with 96.14 seconds latency. OpenAI-Privacy-Filter scores $\mathcal{M}_{\mathrm{safe}}$9 at 0.34 seconds. On the out-of-distribution PersonaMem-v2-derived evaluation set, MemPrivacy-4B-RL reaches $Y_{\mathrm{safe}}$0, precision $Y_{\mathrm{safe}}$1, recall $Y_{\mathrm{safe}}$2, and 0.44 seconds; the best reported general LLM is DeepSeek-V3.2-Think at $Y_{\mathrm{safe}}$3 and 39.60 seconds (Chen et al., 10 May 2026).

A separate LLM-as-a-Judge evaluation on MemPrivacy-Bench, using GLM-5.1, DeepSeek-R1-0528, and Qwen3-235B-A22B, again ranks MemPrivacy-4B-RL highest, with scores of 83.85, 84.75, and 85.09 respectively. MemPrivacy-4B-SFT is second-best, and the MemPrivacy models as a group outperform general LLMs in this evaluation mode as well (Chen et al., 10 May 2026).

The utility results are central to the benchmark’s interpretation. Across LangMem, Mem0, and Memobase, MemPrivacy is reported to limit utility loss to within 1.6% when protecting PL2–PL4. For LangMem, no protection yields 65.37 on MemPrivacy-Bench short-answer QA and 50.98 on PersonaMem-v2 MCQ; MemPrivacy with PL2–PL4 protection yields 64.07 and 49.38, while PL4-only protection yields 65.28 and 50.80. For Mem0, the corresponding no-protection values are 68.62 and 55.42, and PL2–PL4 protection yields 67.89 and 54.71. For Memobase, no protection yields 38.62 and 54.35, and PL2–PL4 protection yields 37.89 and 53.11 (Chen et al., 10 May 2026).

The ablations indicate why the benchmark emphasizes typed placeholders rather than masking alone. In LangMem, irreversible masking reduces short-answer accuracy to 38.70, and untyped placeholders reduce it to 58.70. In Mem0, irreversible masking reduces short-answer accuracy to 26.75, and untyped placeholders reduce it to 63.90. In Memobase, the same baselines reduce short-answer accuracy to 21.63 and 33.90 respectively. The paper further reports that replacing the MemPrivacy extractor with general models substantially degrades downstream utility: for Mem0, accuracy falls to 37.58 with DeepSeek-V3.2-Think and 32.21 with GPT-5.2, compared with 67.89 when using the MemPrivacy extractor (Chen et al., 10 May 2026).

The results also include a robustness observation: as the proportion of privacy-related questions increases toward 100%, MemPrivacy remains more stable across systems, whereas baseline masking methods degrade faster. This suggests that the preservation of type semantics becomes increasingly important as privacy density rises within the memory workload (Chen et al., 10 May 2026).

6. Relation to adjacent benchmarks, limitations, and outlook

MemPrivacy-Bench occupies one part of a broader research landscape on LLM memory privacy. BenchPreS studies whether persistent-memory LLMs appropriately apply or suppress stored user preferences across 39 formal recipient–task contexts, using Misapplication Rate (MR) and Appropriate Application Rate (AAR), and explicitly proposes Suppression Fidelity and Context Compliance Accuracy as natural extensions for a MemPrivacy-Bench centered on contextual privacy leakage (Yoon et al., 17 Mar 2026). PrivacyBench instead evaluates multi-turn secret preservation in conversational RAG assistants using Leakage Rate, Over-Secrecy Rate, and Inappropriate Retrieval Rate, and shows that prompt-based privacy mitigation lowers leakage while leaving retrieval indiscriminate (Mukhopadhyay et al., 31 Dec 2025). CIMemories evaluates persistent-memory contextual integrity through per-attribute, per-context labels, Violation@n, Completeness, and accumulation across tasks and repeated runs, emphasizing that privacy violations can grow with continued usage even without adversarial prompting (Mireshghallah et al., 18 Nov 2025). CheckMIABench addresses a different privacy axis altogether—membership inference—by constructing distribution-shift-free checkpoint-based testbeds for LLM MIAs and validating them with blind baselines (Wang et al., 16 Jun 2026).

Within that landscape, MemPrivacy-Bench is distinctive in that it evaluates a pre-cloud sanitization mechanism rather than only post hoc refusal or contextual withholding. This suggests a complementary role: BenchPreS, PrivacyBench, and CIMemories primarily measure whether memory content is used appropriately once it is accessible to the model, whereas MemPrivacy-Bench evaluates whether sensitive content can be transformed before cloud-side memory processing while retaining utility (Chen et al., 10 May 2026).

The benchmark’s reported limitations are substantial and define its current scope. The profiles and dialogues are synthetic; language coverage is limited to balanced English and Chinese; the dataset is intentionally privacy-dense for stress testing; the training split is not exhaustively manually verified even though the test and evaluation splits are human-verified; edge-device latency may differ from the reported GPU-server measurements; and inter-annotator agreement statistics such as Cohen’s $Y_{\mathrm{safe}}$4 are not reported. The paper identifies multimodal privacy, richer relational placeholders, cross-lingual generalization, broader memory-system coverage, and explicit exposure measurements as future directions (Chen et al., 10 May 2026).

Taken together, these properties make MemPrivacy-Bench a benchmark for privacy-preserving memory management rather than a generic privacy audit. Its central technical claim is not merely that LLM memory can leak, but that typed placeholder sanitization and local restoration can preserve cloud-side memory utility while reducing raw sensitive exposure. In the current literature, that makes it a systems-oriented complement to benchmarks centered on contextual suppression, conversational leakage, contextual-integrity violations, or membership privacy (Chen et al., 10 May 2026).