1 Introduction↩︎

Long-term memory is becoming a core part of language agents. Memory systems store past conversations, user preferences, and recurring personal context, allowing agents to maintain continuity across sessions [1]–[3]. Recent work improves memory writing, retrieval, and updating [4]–[6], and evaluations typically measure retrieval accuracy, long-term question answering, preference following, or task success [7]–[10]. This utility-focused view leaves an important question underexplored: when should available memory be integrated into responses?

Consider a routine request: “Can you suggest a place for lunch near campus?” Without memory, an assistant provides generic recommendations. With memory access, the assistant may retrieve that the user previously discussed eating-disorder recovery. The memory is relevant—it relates to food. But should the assistant reference this history when answering a casual lunch request? Privacy theory suggests that disclosure creates managed access, not blanket permission for all future reuse [11].

We call this the memory-use boundary problem: determining when available history should be integrated into current responses. This is distinct from privacy leakage (no adversary is involved) and from retrieval accuracy (the memory may be correctly retrieved but questionably used).

We use current-turn warrant to name the sufficient justificatory basis, signaled by the present user turn, for using prior memory in a response. This warrant is not the same as storage consent or semantic relevance. A user may have disclosed a sensitive fact in an earlier conversation, and a retriever may correctly find it related to the current topic, but the current prompt may still not invite the assistant to use it. Conversely, if the user explicitly asks for continuity or reopens the same topic, sensitive history may be appropriate to use. The boundary problem is therefore not whether an agent should remember users at all, but whether it can scope memory use to the current interaction.

To study this phenomenon, we introduce RBI-Eval (Relevant-But-Inappropriate Evaluation), a controlled probe set that measures memory-use behavior by comparing responses with and without access to sensitive history. Each item contains a benign current prompt paired with prior history containing sensitive disclosures. The key measurement is sensitive-history integration: whether the model explicitly references or relies on sensitive prior context.

We evaluate four LLMs under a no-memory reference, full-context exposure, and three retrieval-based memory conditions. Models show substantial behavioral differences: when memory is available, the separation score for sensitive-history integration (higher means less integration) falls by 8.9%–26.6% relative to the matched no-memory reference for GPT-5.4-mini, but by 51.1%–82.9% for Claude-Sonnet-4.6, DeepSeek-V4-Flash, and Qwen3.5-9B. Control experiments confirm this pattern is specific to sensitive content. Retrieval systems reduce how often sensitive memories reach the generator, but integration remains frequent once exposure occurs.

In summary, our contributions are threefold:

• We show that memory access can strongly shift boundary behavior under benign prompts, with conservative and high-integration patterns differing across model families.

• We show that the effect is specific to sensitive history rather than ordinary personalization, using controls on both a high-integration model and a conservative model.

• We decompose risk into retrieval exposure and generation-time integration, showing that retrieval reduces target hits but does not determine post-exposure use.

RBI-Eval adopts a conservative disclosure perspective: sensitive history should not be surfaced unless the current turn explicitly invites it. This reflects professional norms in general-purpose assistance but may not suit all contexts.

2 RBI-Eval↩︎

RBI-Eval compares responses to identical benign prompts with and without sensitive prior history. It targets cases where a memory is true and retrievable but not warranted by the current turn, separating memory availability from appropriate use.

2.1 Overview↩︎

Each probe case contains a persona profile \(p_u\), prior assistant–user history \(h_u\), marked memory signal \(s\), benign probe \(q\), and an item-level boundary rubric. For each probe case, responses are generated under no-memory, full-context, and retrieval-based memory conditions, so holding \(q\) fixed isolates the effect of memory access. Probes remain answerable without sensitive memory while making the target memory plausible to retrieve.

2.2 Memory-Use Dimensions↩︎

We measure four dimensions following established LLM evaluation practices [12], [13]:

Sensitive-history integration: Does the response explicitly reference or rely on prior sensitive disclosures? This captures the degree of historical grounding.

Relationship-maintenance agreement: Does the response prioritize preserving closeness over offering independent judgment? Related to sycophancy [14].

Affective intensity: Does the response escalate the emotional framing beyond the current prompt’s tone?

Assistant centrality: Does the response position the assistant as uniquely important to the user?

2.3 Construction: Personas, History augmentations, and Probes↩︎

We derive persona profiles from LoCoMo long-form dialogues [7]. Each profile records stable background, communication style, recurring concerns, and social context. We then construct assistant–user histories that fit the persona rather than directly converting human–human transcripts, following controlled generation practices for dialogue evaluation.

RBI-Eval uses four history augmentation tracks: questioned choice, acute distress, support recedes, and sensitive disclosure. Each plants an ordinary interaction dynamic. The sensitive-disclosure track introduces one private event and does not revisit it, so later integration cannot be explained by repeated topical salience. Probes are benign single-turn requests such as casual planning questions, mild emotional check-ins, decision prompts, and light reflections.

Candidate probes are filtered to preserve the construct. We remove cases that explicitly ask the assistant to remember, reopen the same sensitive event, create an urgent safety need, or make sensitive-history integration necessary for a helpful answer. Accepted items therefore keep the measurement focused: the current probe is answerable without the sensitive memory, but the prior history makes that memory available to the system.

Each accepted item also records a boundary rationale, not just a target label. The rationale states what a helpful answer can use from the current turn, what would count as crossing into unwarranted sensitive history, and which forms of ordinary personalization remain acceptable. This annotation is important because RBI-Eval is not trying to suppress social context wholesale. It asks whether an assistant can distinguish benign adaptation from reopening private history. Appendix Table 4 gives the scoring rubric, and Appendix Table 6 summarizes how probe families instantiate the boundary.

2.4 Dataset Statistics and Composition↩︎

RBI-Eval contains 2,400 single-turn probe cases derived from 10 personas. The probe set includes four probe families (attitude reversal, mild complaint escalation, disengagement request, and casual sensitive lure) that correspond to the four measurement dimensions. Responses are collected under controlled memory conditions, and each probe family tests a specific aspect of memory-use behavior under benign current prompts.

To isolate the effect of sensitive content, we include control conditions following best practices in controlled evaluation [15]: neutral relevant memory (non-sensitive personalization), boundary-policy control (explicit restraint instruction), oracle-sensitive and irrelevant-sensitive controls (varying topical fit), and transparent-vector memory (direct text exposure). Appropriate-use controls ensure that conservative behavior is not achieved by suppressing all memory: these include explicit requests for memory, topic reintroduction, and non-sensitive preference use.

The controls are paired around current-turn warrant. Neutral relevant memory and non-sensitive preference use represent cases where personalization should remain allowed; oracle-sensitive, irrelevant-sensitive, and transparent-vector settings stress whether mere availability or presentation of sensitive text causes uptake. This pairing makes the control results interpretable as boundary behavior rather than as a generic preference for short, cautious, or impersonal answers.

2pt

3 Experiments↩︎

We organize the measurement around three questions: does memory access shift boundary behavior relative to no-memory responses, are shifts specific to sensitive history rather than personalization generally, and how much of the effect is explained by retrieval exposure versus generation-time integration?

3.1 Experimental Setup↩︎

3.1.0.1 Base LLMs.

We evaluate 4 generation models: Claude-Sonnet-4.6 [16], GPT-5.4-mini [17], DeepSeek-V4-Flash [18], and Qwen3.5-9B [19]. They cover different model families and show a range of memory-use behaviors.

3.1.0.2 Memory conditions.

For each model, we compare a no-memory baseline with full-context history exposure and three memory conditions: Mem0 [3], A-Mem [4], and MemU [20]. No-memory baseline responses receive only the current probe; the full-context condition receives a fixed-budget history representation; retrieval systems ingest the same history but return their own memory entries, following standard practices in retrieval-augmented generation [21]. DeepSeek and GPT-5.4-mini additionally support transparent-vector, boundary-policy, and control-slice analyses for Q2; DeepSeek provides the retrieval-exposure annotations used for Q3.

3.1.0.3 Prompting and scoring.

All primary runs use a neutral prompt: answer the current user message, with memory supplied only through the assigned condition. The prompt does not state the desired memory-use rule. The scoring pass uses a condition-blind judge that hides model identity, memory condition, and retrieval method and assigns continuous 0–1 scores for the four dimensions, following rubric-based LLM evaluation practice [12], [13]. Appendix 8 summarizes the evaluation protocol.

3.1.0.4 Metric.

For model \(m\), condition \(c\), persona \(u\), probe \(q\), and dimension \(d\), let \(v_{m,c,u,q,d}\in[0,1]\) be the normalized dimension score. We report an absolute separation score for every condition: \[\mathrm{\small BSS}^{\mathrm{abs}}_{m,c,d}=100\left(1-\mathbb{E}_{u,q}v_{m,c,u,q,d}\right). \label{eq:bss}\tag{1}\] Scores lie in \([0,100]\), higher indicates more conservative memory use. Paired diagnostics compute integration shifts relative to matched no-memory responses.

3.2 Q1: Does Memory Access Shift Boundary Behavior?↩︎

3.2.0.1 Memory access changes what counts as evidence.

No-memory responses rarely integrate sensitive history, as expected: the model cannot reference context it does not receive. The important pattern is what happens once memory is available (Table 1). For three model families, ordinary prompts often become interpreted through prior sensitive disclosures. GPT-5.4-mini is more restrained, but it is not completely unaffected. This contrast shows that the boundary problem is not just whether memory is retrieved; it also depends on whether the generator treats retrieved history as warranted evidence for the current turn.

3.2.0.2 Models encode different memory-use policies.

The model-level patterns look like different memory-use policies, not small calibration noise. GPT-5.4-mini usually keeps the current prompt separated from sensitive history. DeepSeek and Qwen more readily fold that history into the response. Claude sits between these regimes, with behavior that depends more on the case. These differences suggest that memory-use behavior is a design property of the model–memory stack, rather than a fixed consequence of giving any model long-term context.

3.2.0.3 The effect is not generic over-personalization.

The diagnostic dimensions help interpret the result. Relationship-maintenance, affective intensity, and assistant centrality do not move in the same way as sensitive-history integration. This matters because it rules out a simpler story in which memory merely makes responses warmer, more agreeable, or more dependent. The main effect is more specific: sensitive history becomes part of the answer even when the current prompt does not invite it.

Figure 3 gives the paired case-level view. The conservative model remains concentrated near no change, while the other model families shift upward across memory conditions. The clustered uncertainty checks in Appendix Table 8 show that this pattern is not driven by one persona or one probe family.

Appendix Figure 8 further checks the item-family axis. The shift appears not only in sensitive-lure prompts, where a strong effect would be easiest to expect, but also in attitude-reversal and disengagement prompts that resemble ordinary advice or preference updates. This strengthens the interpretation that the boundary issue comes from making sensitive history available under benign prompts, rather than from a narrow wording artifact.

3.3 Q2: Are Shifts Specific to Sensitive History?↩︎

Table 2 reports paired control conditions for DeepSeek and GPT-5.4-mini.

2pt

3.3.0.1 Personalization alone does not explain the effect.

The controls separate sensitive-history use from ordinary personalization. Non-sensitive memories do not trigger the same behavior, and an explicit boundary policy suppresses sensitive-history integration while still allowing ordinary memory use. RBI-Eval is therefore not penalizing personalization in general. It is measuring a narrower failure mode: treating sensitive prior history as relevant enough to surface when the current turn has not warranted its use.

3.3.0.2 Sensitive context changes uptake, but policy matters.

The remaining controls show that sensitivity itself changes model behavior, but not uniformly across models. Some systems treat sensitive context as a strong cue for how to interpret even benign prompts, while the conservative model often resists that cue. This is why topical relevance is too weak as a decision rule. A memory can be related to the prompt and still be inappropriate to use; the model-side policy determines whether that distinction is respected.

Appendix Table 11 makes this point more explicit by separating sensitive content, target-only context, and relevance-independent sensitivity. The useful takeaway is qualitative: a memory policy cannot reduce to topical relevance. It must also account for sensitivity, presentation format, and whether the current turn provides warrant to use that history.

3.3.0.3 Warranted use is a separate requirement.

Table ¿tbl:tab:licensed-controls? adds positive-use controls for the same issue. A useful memory system should not avoid boundary errors by ignoring memory altogether; it should use memory when the user clearly invites it and avoid extending that warrant beyond the current turn. DeepSeek handles ordinary non-sensitive preferences cleanly, but sensitive-topic cases remain difficult: explicit requests and topic reopening still produce substantial over-scope use. This result sharpens the benchmark’s target. RBI-Eval is not measuring memory suppression; it measures whether the system can scope memory use to the current-turn warrant.

3.3.0.4 Memory interfaces can invite use.

The transparent-vector condition also shows that the memory interface can shape behavior. Presenting recalled text as system-provided memory may make it feel like context the assistant should use, consistent with findings on context influence in retrieval-augmented systems [22]. Yet the model contrast remains, so the interface is not deterministic. Memory packaging and generator policy interact.

3.4 Q3: How Much Comes from Retrieval Exposure?↩︎

We decompose integration risk by whether a sensitive target memory was retrieved; Appendix Table 7 reports exposure rates.

3.4.0.1 Retrieval controls what reaches the generator.

Figure 4 separates two steps: whether the target sensitive memory reaches the generator, and whether the generator uses it once exposed. Retrieval-based systems reduce exposure relative to full-context access. This makes retrieval filtering a major mitigation lever: the safest sensitive memory is often the one that never enters the generation prompt for a casual turn.

3.4.0.2 Exposure still requires generation-time restraint.

Exposure control is not enough. Once sensitive history appears in the prompt, generators often treat it as usable context. This points to a boundary-awareness gap: current systems can use relevance signals, but they do not reliably ask whether the current turn invites that memory use. Retrieval-time filtering is therefore necessary but not sufficient; generation-time safeguards are also needed.

3.4.0.3 The content of retrieved memory matters.

The retrieval systems also differ in what kind of memory they surface. Some return broad preference-like summaries; others expose more concrete autobiographical anchors. This changes the generator’s decision problem. The design implication is twofold: retrievers should avoid surfacing sensitive anchors for casual prompts, and generators need guidance for what to do when such anchors are present–ignore them, abstract away from them, ask permission, or mention them only when clearly invited.

Appendix Table 13 and the case studies illustrate why this matters operationally. A compact summary can feel like a harmless preference, while a concrete autobiographical memory invites a more intimate answer. Both can be relevant to the same prompt, but they impose different obligations on the generator. A retrieval system should therefore expose not only a memory string, but also metadata about sensitivity and permitted use.

4 Discussion↩︎

4.0.0.1 Memory integration varies across model–memory stacks.

The results reveal systematic differences in how models handle available sensitive history. The large effect size between GPT-5.4-mini and the other evaluated models (Cohen’s \(d = -1.506\), Appendix Table 9) shows that memory-use behavior varies substantially across model–memory stacks, rather than being a fixed consequence of giving a model long-term context. Boundary-policy controls, implemented by adding current-turn restraint to the Mem0 condition, reach 99.9 BSS for DeepSeek and 100.0 for GPT-5.4-mini (Table 2), showing that current-turn instructions can substantially reduce sensitive-history integration in this benchmark. Three strategies emerge: model selection (prefer models that show lower sensitive-history integration for sensitive domains), retrieval-time filtering (roughly 71–84% lower exposure-and-use risk among retrieval-memory systems), and prompt-level policies (Mem0 plus boundary instruction raises DeepSeek BSS from 28.3 to 99.9).

4.0.0.2 Why sensitive-history integration is the primary measurement.

Sensitive-history integration, reported as inappropriate recall (IR) in Appendix Table 10, shows weak correlation with other dimensions, confirming it captures a distinct behavioral dimension. Sensitive-history integration is more specific because it requires access to prior context and measures whether that context becomes central to the response. A model showing high integration is not necessarily producing lower-quality responses; the question is whether such integration is warranted by the current prompt.

4.0.0.3 Design implications: two-stage defense.

Our findings suggest combining retrieval-time and generation-time safeguards. Retrieval-time filtering is the primary mitigation lever, reducing total exposure-and-use risk by roughly 71–84% across the three retrieval-memory systems through sensitivity-aware ranking, exposure budgeting, and retrieval selectivity. Generation-time safeguards handle residual risk: the high integration-if-hit rates (66.7–94.9%) indicate generators lack boundary-awareness. Mitigation options include prompt-level policies, choosing among mention/abstraction/avoidance, and ask-before-use for high-sensitivity memories. User-facing controls should separate storage from permission to surface, enabling “background only” settings and per-topic memory-use preferences. Detailed recommendations appear in Appendix 11.8.

4.0.0.4 Permission as runtime state.

A practical lesson is that memory governance should not collapse storage, retrieval, and use into one switch. A user may want an assistant to retain a sensitive fact for future continuity while expecting ordinary turns to proceed without that fact. Systems therefore need lightweight signals for current-turn warrant: whether the present request invites direct recall, abstract background adaptation, permission seeking, or no use. This framing also explains why retrieval and generation safeguards should be evaluated together rather than as separate components.

5 Related Work↩︎

5.0.0.1 Memory utility evaluation.

Retrieval-augmented generation and context filtering show that selected information shapes generation [21]–[23]. Long-term memory systems improve continuity through persistent user context [1]–[6], [24]–[32]. Existing memory evaluations test retrieval accuracy, long-horizon QA, preference following, or profile inference [7]–[10], [33]. These tasks usually reward successful use of stored context. RBI-Eval instead studies a different failure mode: memory can be available and relevant, yet still inappropriate to surface in the current turn.

5.0.0.2 Privacy and contextual integrity.

Privacy research distinguishes secrecy from appropriate disclosure and information flow [11], [34]–[36]. This distinction is central for assistant memory: a fact may be legitimately stored, and may even help in some future context, without being warranted for every casual request. Recent privacy benchmarks and memory-privacy studies examine privacy norms, leakage, and sensitive inference [37], [38]. RBI-Eval builds on this view by operationalizing the boundary between stored history and current-turn warrant.

5.0.0.3 Personalized safety.

Long-context and personalized-safety work shows that user context can shift model behavior [39]–[47]. These evaluations often focus on harmful requests, jailbreak-like settings, leakage, or adversarial extraction. RBI-Eval targets a more ordinary interaction pattern: the prompt is benign, the memory is already available, and the question is whether using that memory would cross a social boundary.

5.0.0.4 Sycophancy and over-personalization.

Sycophancy and over-personalization studies show that models can over-align with users or overuse personal context [14], [48]–[51]. RBI-Eval uses related behaviors as diagnostic dimensions, but its primary measurement is sensitive-history integration under memory access. This separates general agreement or warmth from the memory-specific decision to surface prior sensitive history.

6 Conclusion↩︎

Long-term memory systems face a design question: when should available history be integrated into current responses? Using RBI-Eval, we find that memory access can substantially shift sensitive-history integration, that this pattern is specific to sensitive content rather than ordinary personalization, and that retrieval filtering reduces exposure but does not settle post-exposure use. Future work should expand to multilingual settings, diverse cultural norms, and direct user preference elicitation.

Limitations↩︎

6.0.0.1 Normative and deployment scope.

RBI-Eval encodes a conservative norm: sensitive history should not be surfaced unless the current turn invites it. This is appropriate for general-purpose assistants, but not universal. Some cultures, domains, or relationship models may prefer stronger proactive continuity, especially in care-oriented settings. We therefore interpret integration scores as evidence about a system’s memory-use policy, not as a universal ranking of what every deployment should do.

6.0.0.2 Construct and measurement validity.

The boundary between helpful personalization and intrusive integration is partly subjective, and near-boundary cases may reflect genuine social ambiguity. The automatic judge is condition-blind, yet it may still inherit normative assumptions from its training distribution. RBI-Eval also detects overt sensitive-history integration rather than silent profiling or implicit influence, so high BSS should not be read as a complete privacy guarantee.

6.0.0.3 Coverage.

The benchmark uses 10 English-language personas, repeated probe families, text-only single-turn interactions, and LoCoMo-derived adult conversations. This design supports controlled matched comparisons, but it does not cover multilingual settings, richer user populations, or products where historical continuity is part of the intended service. Future work should expand personas, languages, relationship types, and multi-turn repair behaviors while preserving the no-memory reference design.

Ethical Considerations↩︎

RBI-Eval uses fictionalized assistant–user histories grounded in public research data, not private deployment logs. We will release data and evaluation protocols upon acceptance. The benchmark is intended for defensive memory governance, not user profiling, suppression of all personalization, or deployment certification. Real deployments should pair RBI-Eval measurements with user studies, consent controls, domain guidelines, and ethical review.

7 Benchmark Construction Details↩︎

RBI-Eval is designed to isolate the social boundary of memory use, rather than general memory utility. The construction pipeline follows the style of recent personalization benchmarks: start from long-horizon dialogue-derived personas, add controlled history manipulations, generate benign probes, then filter examples so that the current user message does not itself require sensitive memory use.

7.1 Persona Induction↩︎

We build personas from LoCoMo-derived long-form dialogues. For each selected conversation, the preprocessing pipeline constructs a persona profile with four fields: stable background, communication style, recurring concerns, and social context. Each field is grounded in evidence from the source dialogue. The purpose is not to predict private traits, but to maintain biographical and stylistic consistency when creating assistant–user histories.

RBI-Eval contains 10 personas and 2,400 single-turn probe cases. The probes are balanced across four boundary dimensions and four probe families. Response-level samples are produced by running these probe cases under the assigned memory conditions.

7.2 Measurement Rubric↩︎

Table 4 defines the four dimensions used for response-level scoring. The primary dimension is sensitive-history integration: whether the assistant uses prior sensitive history to interpret the user when not explicitly invited. The other three dimensions are diagnostic checks. They test whether memory access also shifts the assistant toward excessive agreement, emotional escalation, or relationship centrality. The Not sufficient column marks behaviors that should not be counted, so ordinary tact, proportionate empathy, and appropriate preference use are not penalized.

7.3 History Augmentation↩︎

Each persona receives four memory-use augmentation tracks corresponding to the four evaluation dimensions in Table 5. The tracks are written as ordinary interaction history rather than explicit labels. For example, the sensitive-history integration track introduces a single sensitive disclosure and then leaves it unrepeated, so later integration is not triggered by repeated topical salience. This keeps the measurement focused on the model’s decision.

Figure 5 gives the complete dual-agent prompt schema used to generate inserted history sessions. The user-agent payload receives the selected seed and full augmentation-template markdown; the assistant-agent payload does not receive the target dimension, seed, or template text.

7.4 Probe Families↩︎

RBI-Eval probes are benign and single-turn. Each probe records a persona id, probe family, primary dimension, current user prompt, and boundary rubric. Table 6 summarizes the probe families used in the current run. Candidate probes are filtered to preserve the construct: we remove cases that explicitly ask the assistant to remember, reopen the same sensitive event, create an urgent safety need, or make sensitive-history integration necessary for a helpful answer.

None

4pt

8 Experimental Setup↩︎

8.1 Control Conditions↩︎

The neutral relevant control inserts non-sensitive personal detail that could support ordinary personalization. The boundary-policy control adds an explicit current-turn restraint to the Mem0 condition. The oracle-sensitive control directly provides the target sensitive memory. The irrelevant-sensitive control provides sensitive history that is not needed for the probe. Appropriate-use positive controls ask the user to explicitly use prior history, reintroduce the same sensitive topic, or rely on a non-sensitive preference; Table ¿tbl:tab:licensed-controls? reports this slice in the main results. Transparent vector memory exposes retrieved memory text in a simple vector-retrieval format. Together these controls test whether sensitive-history integration is driven by personalization density, sensitive content, semantic relevance, current-turn invitation, retrieval representation, or generation-time restraint.

8.2 Evaluation Setting↩︎

Each item is evaluated under no-memory (stateless), full-context, and retrieval-memory conditions, using the neutral prompt in Figure 6. The prompt asks for a direct answer to the current user message and does not state the desired memory-use rule.

8.3 Automatic Evaluation↩︎

The primary automatic judge is GPT-5.4 and is condition-blind. It receives the current user message, assistant response, and probe rubric, but not the model identity, memory condition, or retrieval method. The judge assigns continuous 0–1 scores for the four dimensions, together with evidence spans and a short rationale. Main tables report BSS on a 0–100 scale, where higher values indicate more conservative memory use.

None

None

8.4 Human Evaluation Protocol↩︎

The human evaluation validates whether the automatic judge tracks memory-use judgments rather than surface personalization cues. The validation package samples 600 responses stratified by model, memory condition, probe family, and dimension. Each response is independently annotated by 2 annotators who are blind to model identity and memory condition. The automatic judge achieves an overall agreement of 92.1% with human judgments across the sampled responses.

9 Implementation Details↩︎

9.1 Execution Environment↩︎

Our experiments are conducted on a single NVIDIA A40 GPU. Claude-Sonnet-4.6, GPT-5.4-mini, and DeepSeek-V4-Flash are accessed through provider APIs. Qwen3.5-9B is deployed locally and served with vLLM. For memory-augmented agents, we use local runners for memory storage and retrieval: Mem0 uses a local Mem0 store, A-Mem uses our local implementation, and MemU uses the local MemU runner. Retrieval uses text-embedding-3-small; auxiliary extraction, metadata, and memory-construction calls use DeepSeek-V4-Flash (deepseek-v4-flash). Unless otherwise noted, retrieval-memory conditions return the top 5 memory entries to the generator; the stateless condition has no retrieval and the full-context condition uses the fixed full-history budget. The automatic judge uses GPT-5.4 through API calls in the condition-blind scoring pipeline. For all response-generation calls, we set temperature = 0.

9.2 Neutral Generation Prompt↩︎

Figure 6 gives the response-generation template used for the main neutral setting. The instruction is intentionally minimal: the model receives the current user message and whichever memory context is exposed by the condition, but it is not told which boundary dimension is being tested.

9.3 Automatic Judge Template↩︎

Figure 7 shows the condition-blind judge template. The judge sees the current prompt, the assistant response, and the item rubric, but model names and memory-condition labels are hidden.

10 Additional Experimental Results↩︎

10.1 Retrieval Exposure Analysis↩︎

This analysis supports Q3 by separating retrieval exposure from generation-time integration. It asks whether sensitive-history integration mainly happens when the retriever returns the target sensitive memory, or whether integration also occurs without that target hit.

Table 7 reports the two quantities needed for this decomposition. Target hit measures whether the memory interface exposes the specific sensitive history tied to the current probe. Integration if target hit then conditions on that exposure and measures whether the response integrates the retrieved sensitive history.

The pattern shows that retrieval filtering reduces exposure but does not remove the downstream integration risk. Retrieval-based memory systems expose the target sensitive session less often than full-context memory, yet once that target session is exposed, integration remains frequent. This supports the interpretation that memory-use behavior arises from both retrieval exposure and generation-time decisions.

11 Additional Analysis↩︎

11.1 Statistical Uncertainty↩︎

Table 8 reports the paired BSS-point loss for sensitive-history integration behind Table 1. Each memory row compares a condition with the same model’s matched no-memory baseline on matched persona–probe pairs. Intervals use cluster bootstraps over personas and probe families. The \(p\) values use paired sign flips on the signed integration-score differences.

1pt

This table is a validity check for the main result rather than a separate leaderboard. It asks whether the shift in sensitive-history integration in Table 1 still holds after accounting for the two main dependence structures in RBI-Eval: repeated personas and repeated probe families. The diagnostics support this interpretation. Every clustered interval remains above zero and every sign-flip test is significant, so the central finding is not explained by a few unusually vulnerable personas, a single probe template, or treating all 2,400 probe cases as independent rows.

Substantively, the table supports the claim that memory access can turn relevant-but-unwarranted personal history into evidence for an otherwise ordinary current prompt. This is the failure mode RBI-Eval is designed to test: the memory is relevant in the broad history, but not warranted by the current turn. The smaller losses for GPT-5.4-mini show that this behavior is not inevitable for every model-memory stack, while the much larger and consistently positive losses for Claude-Sonnet-4.6, DeepSeek-V4-Flash, and Qwen3.5-9B show that retrieval or memory packaging alone does not reliably enforce the boundary. A-Mem sometimes attenuates the loss, but it does not eliminate it. The table therefore validates the robustness of the benchmark signal and the need to model current-turn warrant explicitly; it does not by itself establish deployment prevalence or a unique causal mechanism.

11.2 Probe-Family Robustness↩︎

RBI-Eval reuses personas, probe families, and memory-signal templates across many paired cases, so aggregate scores should not be read as if all rows were independent. Figure 8 shows item-level BSS shifts for sensitive-history integration separately for each probe family in the complete DeepSeek condition-blind pass. Each box summarizes the paired shift against the no-memory baseline for one memory condition within one probe family.

The pattern is not confined to a single current-turn family. Neutral relevant memory stays near zero shift across panels, while sensitive controls and memory-exposure conditions shift upward in most families. The strongest shifts appear in casual sensitive lure and mild complaint escalation probes, but attitude-reversal and disengagement probes also show broad movement away from the no-memory baseline. This supports the main interpretation: the pattern is not only a small set of item templates, but a recurring effect of making sensitive history available under benign current prompts.

11.3 Model Effect Size Analysis↩︎

Table 9 provides a descriptive check on the model split discussed in Section 3.2. We group GPT-5.4-mini separately because the main results show a consistently more restrained pattern of sensitive-history integration. The \(N\) column counts response-level rows under the four memory-access settings (full context plus three retrieval systems), excluding the matched no-memory reference. The sign of Cohen’s \(d\) only reflects this group ordering; the relevant point is the size of the separation. This supports reporting model-specific behavior rather than averaging all systems into a single memory-access effect. It should be read as a summary of observed behavior in RBI-Eval, not as evidence that one model family is categorically immune to boundary violations.

11.4 Dimension Correlation Analysis↩︎

Table 10 asks whether IR is merely a proxy for broader over-personalization. The answer is no. The correlations with sycophancy, affective amplification, and dependency induction are positive but weak, which means the dimensions move together in some cases but do not collapse into the same behavior. This matters for interpretation: a response can be warm or agreeable without surfacing sensitive history, and it can surface sensitive history without strongly increasing dependency language. We therefore keep sensitive-history integration as the primary diagnostic rather than treating it as another generic personalization score.

11.5 Control Effects Decomposition↩︎

Table 11 unpacks the DeepSeek controls in Table 2 into three contrasts. The sensitive-content contrast measures how much behavior changes when the available context contains the target sensitive history. The target-only-context contrast asks whether isolating the target sensitive history changes uptake relative to full-context exposure. The relevance-independent contrast checks whether sensitive material can still shape responses when it is not topically needed for the current prompt. Together, these controls show why retrieval relevance is not enough as a policy rule: sensitivity, presentation, and current-turn warrant all affect whether memory should be used.

11.6 Implicit Effects in Irrelevant-Sensitive Condition↩︎

Table 12 examines cases where sensitive history is available but not relevant to the current prompt. The split by IR level is meant to test whether visible recall is the only pathway through which memory changes behavior. The high-recall group also shows higher sycophancy, affective, and dependency scores, while the low-recall group remains above the neutral-relevant baseline reported in the caption. This suggests that sensitive memories can affect tone and framing even when the response does not explicitly mention the sensitive fact. We treat this as a secondary diagnostic, because the main safety concern remains explicit unwarranted integration.

11.7 Memory Features by Retrieval System↩︎

Table 13 audits the retrieved memory text in high-integration cases. The comparison helps explain why retrieval systems differ even when they are attached to the same base model. A-Mem often returns concrete first-person material, while Mem0 and MemU tend to return more abstract summaries. This does not mean that abstraction alone controls risk; Table 7 shows that target exposure and conditional integration both matter. The feature audit is therefore best read as supporting evidence for a two-stage pathway: what the memory system exposes, and how the generator decides to use it.

11.8 Design Recommendations↩︎

The recommendations below synthesize the preceding audits rather than introduce a new experiment. Table 11 motivates separating sensitivity, format, and current-turn warrant; Table 7 shows why retrieval filtering must be paired with generation-time restraint; and Table 13 shows that the wording and abstraction level of retrieved memories can change how usable they appear to the model. The practical implication is that memory safety should be implemented at multiple points in the stack.

11.8.1 Retrieval-time filtering strategies.↩︎

11.8.1.1 Sensitivity-aware ranking

: Downrank memories tagged as sensitive unless the probe explicitly invites recall (e.g., contains phrases like “based on my history”).

11.8.1.2 Exposure budgeting

: Limit how often sensitive memories surface across a conversation to prevent repeated exposure.

11.8.1.3 Retrieval selectivity

: Filter for high-relevance cases; Table 7 shows that A-Mem exposes the target sensitive memory in 23.4% of cases, but generation-time restraint is still needed when exposure occurs.

11.8.2 Generation-time safeguards.↩︎

11.8.2.1 Prompt-level policies

: Explicit instruction (“Only use prior context if explicitly invited”) raises DeepSeek Mem0 BSS from 28.3 to 99.9.

11.8.2.2 Mention vs. abstraction vs. avoidance

: Generators should choose among explicit mention, abstraction (“Given your dietary needs…”), or avoidance based on probe characteristics.

11.8.2.3 Ask-before-use

: For high-sensitivity memories (trauma, medical conditions), ask permission before referencing (“I recall you mentioned X—would it be helpful to discuss that now?”).

11.8.3 User-facing controls.↩︎

11.8.3.1 Background-only tagging

: Users can tag memories to inform tone but prevent explicit mention.

11.8.3.2 Per-topic sensitivity levels

: Set memory-use policies per topic (e.g., “health: ask first,” “preferences: always use”).

11.8.3.3 Review and revoke

: Users can review past disclosures and revoke permission without deleting conversation history.

12 Case Studies↩︎

12.1 Case Study Part I: Retrieved Memory Contents↩︎

Figure 9 holds the persona and current query fixed, then shows the memories returned by each memory system. The query is a low-stakes request for a quiet solo outing. The retrieved memories are topically useful, but several also surface private reflection, family, grief, or prior emotional context that the current query does not ask the assistant to reopen.

None

This case separates retrieval exposure from generation. Mem0 mostly returns broad preference summaries that can support generic outing advice without naming a sensitive event. A-Mem and MemU expose more concrete autobiographical anchors: family conflict, bereavement, the mother’s house, and meditation routines. These memories are relevant to a quiet outing, but the current query does not warrant reopening them. The risk is therefore not just wrong retrieval: systems can retrieve useful context while also making private material available to the generator.

12.2 Case Study Part II: Response Comparison Across Base LLMs↩︎

Figure 10 fixes the memory system to MemU and compares four base LLMs on the same query. All four responses provide a plausible solo-outing suggestion, but they also turn the retrieved personal history into explicit advice. The IR scores remain high across base LLMs, showing that the failure is not tied to a single generator. The case also shows why topical relatedness is not the same as permission to reuse personal history: the current turn asks for a quiet solo outing, not for the assistant to reopen family, grief, meditation, or prior yoga routines.

None

Read together, the two case studies show the two-stage boundary problem behind the aggregate results. Part I shows retrieval-stage availability: memory systems differ in how much sensitive context they expose. Part II shows generator-stage uptake: once MemU exposes the private anchors, four base LLMs weave them into the answer. The case is not new aggregate evidence by itself; it makes the main pattern concrete. Relevance alone is too weak a decision rule, because a memory can be useful for personalization while still being unwarranted in the current turn.

13 LLM Usage↩︎

This statement concerns the authors’ use of AI assistants during preparation of the work, not the LLMs used as study objects or automatic evaluators in the experiments described above. We used AI assistance only for auxiliary code construction and limited text polishing. We did not use AI assistants for any other part of the research process.

References↩︎