CIMEMORIES // FIELD MAP
← field map
PART 05 · THE BENCHMARK§1 · Fig 1 · Fig 2 · Def 3.1 · §5.2.3 · Fig 5

The two compositions: memory and tasks

Why one prompt, one sample tells you almost nothing about how much an assistant will eventually leak
TL;DR — "Compositional" in the title means the authors can turn two dials: what goes into a user's memory, and how many tasks (and samples per task) the user runs. Turn the task dial on GPT-5 and the share of private attributes that leak somewhere climbs from 0.1% for one task to 9.6% across all tasks, and to 25.1% when each task is sampled five times (Fig 2). Turn the memory dial by adding not-to-share attributes and violations rise steadily while completeness stays flat (Fig 5). Both results say the same thing: exposure is a property of a user's whole history with the assistant, not of any single reply.
1 task, 1 sample
0.1%
GPT-5 violations · Fig 2
40 tasks, 1 sample
9.6%
GPT-5 · Fig 2, §1
All tasks, 5 samples
25.1%
GPT-5 · Fig 2 (≈1/4 of attributes)
Table 1 Violation@5
25.08%
GPT-5 · Table 1
Memory sweep
5
profiles · §5.2.3, Fig 5

Earlier contextual-integrity benchmarks hand a model one secret and one thing it may share, then check a single answer (see Part 01). A real assistant with persistent memory is the opposite situation: a large and growing pile of facts, used over and over for different recipients. The compositional design is how CIMemories reproduces that situation in a controlled way, and it is the source of the paper's most quoted numbers.

Two dials, one benchmark

The introduction names the two innovations and points at Figure 1 for each (§1, Fig 1). The dataset makes both possible because every attribute of a profile is a separate memory statement with its own label for every task (how those labels are made is Part 03). Since the memory is just a list of labelled sentences, the authors can assemble it however they like.

Dial 1 · memoryMemory composition: choose how many attributes are in memory and which role each plays for the task, necessary or inappropriate.
Dial 2 · tasksMulti-task composition: run the same user through K tasks, each with its own labels, and sample each task T times.
ScoreAsk, per attribute, whether it ever leaked where it should not (Violation@n), and per task, how much of what was needed got through (Completeness).

The same attribute plays different roles across the task pool. In the Figure 1 example, an annual income belongs in a message to a financial advisor and does not belong in one to a primary care doctor. That double role is what makes the task dial interesting: one memory, many chances to send a fact to the wrong place.

Multi-task composition: leaks add up

The three values the paper prints for Figure 2 (GPT-5), as stated in its abstract and Fig. 2 caption. Only these three points are drawn; the full curves are in the paper.

Figure 2 runs GPT-5 through a growing number of tasks K, with one curve per number of trials T from 1 to 5 (Fig 2). The y-axis is labelled Violation@[1,5]. The paper prints three values: 0.1% at one task and one sample, 9.6% when usage grows to 40 tasks with a single sample, and 25.1% when each prompt is run five times. The caption sums it up as roughly a quarter of a user's attributes eventually showing up in a task where they should have stayed out.

an increasingly large percentage (≈ 1/4th) of a user’s attributes are eventually revealed in task contexts where they should not be.— CIMemories, Figure 2 caption

The end of the T=5 curve lines up with the headline table. Table 1 reports GPT-5's Violation@5 over the full task set as 25.08%, which prints as 25.1% in Figure 2 (Table 1). So Table 1 reports the end state of this accumulation, and Figure 2 shows how it builds up. A violation number only means something when you know how many tasks and samples it covers.

One thing the paper does not spell out is how the K tasks for each point are chosen (a fixed order, a random subset, an average over subsets). The x-axis runs to 50, while the text describes the 9.6% point as "40 tasks" and profiles average 45.7 ± 2.9 contexts (Table 2). Read the curve's shape and the three printed numbers, and not much more.

Why the curve can only go up

The growth follows from how the metric is defined (Definition 3.1, covered in full in Part 04). For each attribute, violation is a max: it counts as leaked if any response, in any task where it was private, revealed it. The result is then averaged over attributes. Written loosely:

Violation@n(s) = mean over attributes a that are private in >= 1 task of
                   max   over t in T_priv(s,a), y in {y1..yn} ~ M(M_s · t)
                   R(y, a)            # 1 if the judge finds a's value in y

Fig 2, as this map reads its axes:
  restrict t to the first K tasks the user runs, and set n = T

A max over a bigger set can never be smaller, so adding tasks or samples can never lower the number. The open question is how fast it rises. A toy calculation (illustrative, not from the paper): suppose an attribute is private in every one of 40 tasks and leaks independently with 1% probability per response. After one response the chance it has leaked is 1%. After 40 tasks it is 1 − 0.9940 ≈ 33%, and after 40 tasks × 5 samples it is 1 − 0.99200 ≈ 87%. A per-reply rate that looks harmless turns into a likely leak over a user's history. That is the effect behind the jump from 0.1% to 9.6%.

"Arbitrary and unstable": same prompt, different leak

The sample dial is the more surprising of the two. Moving from T=1 to T=5 re-runs the same prompts with the same memory, and violations still go from 9.6% to 25.1%, about 2.6 times as many. Responses are drawn with each model's default sampling settings (§5.1), so each run is a fresh draw, and different draws give away different attributes.

revealing arbitrary and unstable behavior in which models leak different attributes for identical prompts.— CIMemories, §1 (also the abstract)

A little arithmetic adds detail (the map's reading, not a claim the paper makes). If every attribute had the same 9.6% chance of leaking on each full pass, and passes were independent, five passes would give 1 − 0.9045 ≈ 39.6%. The observed 25.1% is well below that. That fits a population where leak risk is uneven: some attributes are almost never revealed, others leak again and again, and in between is a large group that leaks only on some draws. The between group is what "unstable" refers to. The model has no fixed policy about those attributes. Whether one goes out depends on the sample.

This matters for evaluation. A single-sample, single-task test measures the bottom-left corner of Figure 2, the 0.1%, and would report that a model is nearly perfect. The same model ends at about a quarter of private attributes exposed.

Memory composition: more memories, more leaks

The second dial gets its own research question (§5.2.3, Fig 5). The motivating scenario is an assistant that picks up more and more sensitive facts across sessions. The setup:

Profiles5 users, GPT-5, a smaller slice than the 10-profile main runs.
Held fixedThe necessary attributes in memory for each user.
SweptThe number of inappropriate attributes for each context, raised from 0 upward.
ResultViolations@5 rise steadily. Completeness stays flat.

The paper prints no values for Figure 5, only the trend. Two readings follow from it, and both are the map's, not the authors'.

Flat completeness rules out the obvious excuse. If the extra memories were simply noise that hid the useful facts, a needle-in-a-haystack problem, completeness would drop as the pile grew. It does not. The model keeps finding what the recipient needs. What changes is that it also passes along more of what the recipient should not get.

A rising rate, not just a rising count. Violation@n is a fraction of private attributes, not a total. If every added attribute leaked at the same rate, more of them would mean more leaks but the same fraction. A fraction that climbs suggests that a fuller memory makes each private item more likely to slip out. One caveat: the paper does not say in what order inappropriate attributes are added, so a selection effect (riskier attributes added later) cannot be ruled out from v1 alone.

increased personalization over time not only faces the canonical temporal update challenges tackled by prior work Zhong et al. (2024), but also appears to come at a cost to contextual integrity.— CIMemories, §5.2.3

Putting the two dials together

For a deployed assistant, both dials turn on their own as the user keeps using it. Memory grows with every session, and so does the number of tasks it gets used for. Read together, Figures 2 and 5 say a long-time user is exposed on both counts: more facts that could leak, and more chances for each one to leak. This is the paper's case that personalization and contextual integrity pull against each other (§1), the memory version of the privacy–utility trade-off. The cross-model comparison in Part 06 is all taken at the five-sample end of this curve.

Carry this away: leakage compounds. Because Violation@n asks whether an attribute leaked ever, every extra task, every extra sample and every extra memory is another chance to leak, and GPT-5 goes from 0.1% to about one in four private attributes exposed. An evaluation, or a mental model, built on one prompt and one reply describes the first moment of a user's history, not the rest of it.

Check yourself

  1. Why can Figure 2's curves never slope downward as K or T increases?
    Answer

    Violation@n takes, for each attribute, a max over every task where it is private and every sampled response (Definition 3.1). Adding tasks or samples only enlarges the set being maxed over, so each attribute's indicator can switch from 0 to 1 but never back. The average over attributes therefore cannot fall.

  2. GPT-5's violations go from 9.6% to 25.1% between one and five samples with the same prompts and memory. What does that say about the model's behaviour?
    Answer

    Its choices about what to disclose are not stable. Re-running an identical prompt gives away different attributes on different draws, the "arbitrary and unstable" behaviour of §1. A one-sample evaluation hides most of this.

  3. In the memory-composition sweep (Fig 5), completeness stays flat while violations rise. Why does the flat line matter?
    Answer

    It shows the extra inappropriate memories are not just burying the necessary ones. The model still shares what the task needs, so the rising violations are added over-sharing, not a retrieval failure. In the paper's words, growing personalization comes at a cost to contextual integrity (§5.2.3).

Further reading, verified

Next: Frontier models, measured · Back to the map.