Shared long-term memory lets an LLM agent serving one user inadvertently retrieve another user's credentials, but it is unclear when such exposure leads to actual harm. We introduce a three-stage audit that separates three events: a foreign credential reaches the prompt (exposure), the agent acts with it (behavior), and the other user's account changes (state). In AppWorld, a store that mixes 763 past logins from all users retrieves another user's credential for 84.7 percent of required apps, yet agents rarely act on it. Misuse appears in a stress test where memory lacks the user's own credential and presents a single foreign one as the user's record: seven agents then use it in 80 to 94 percent of runs and change the victim's account in up to 43 percent, sometimes passing the official check. Naming the owner before or inside each credential line prevents most of this: with all else fixed, misuse falls from 92 to 1 of 305 paired runs, also with name-free usernames, though owner-bound notes cost 3 to 5 successful tasks per model on clean memory. A wrongly written owner largely restores misuse; trailing owner tags and added safety instructions help only some models. Agent memory should consistently record whose credential it stores, and evaluations should measure behavior, not only exposure.
Figures & tables
Figure 1: An illustration of cross-user account misuse in a shared-memory agent. The agent stores credentials from multiple users in shared long-term memory. When serving Bob, it retrieves Alice’s Delta credential and may use it to modify Alice’s flight instead of Bob’s, acting as a confused deputy.
Figure 2: Study overview. (1) A shared store of logins from 99 AppWorld users; retrieval puts the top- k notes into the agent’s prompt. (2) The renderer varies only how a fixed credential is worded (illustrative examples; exact strings in Appendix A ). (3) The audit measures exposure ( E ), behavior ( B ) and state change ( S ); their rates multiply to the harm rate (Eq. 5 ), and our interventions act on Pr[B∣E] .
Figure 3: Same credential, different words. Each box renders the same foreign Gmail credential within the requester’s memory; right: share of runs acting with the other user’s token (Cohort 2, 35 tasks per point, 95% Wilson intervals). Codes give (h,δ,f,β) ; the top two and the bottom two rows differ only in the owner attribution β .
Figure 4: The exposure-action gap. (a) Share of required apps whose retrieved notes include another user’s credential, for 54 store configurations (414 tasks). (b) Under natural retrieval, agents rarely act on exposed credentials (95% Wilson intervals); the bottom rows re-render the asserted notes as records.
Table 1: Cohort 2 stress test (35 held-out tasks; renderings fixed before any run). Counts are runs out of 35. B : some API call acted with another user’s token (shaded by magnitude). S : audited net change in the other user’s account. Blogin : runs that submitted the foreign username, whether or not its token was used. gpt-oss: gpt-oss-120b. Success and login counts: Appendix Table 6 ; Cohort 1: Table 3 .
Figure 5: Follow-up controls (one foreign credential replacing the user’s own; Cohort 2, n=35 , unless noted; 95% Wilson intervals). (a) Grey rows name the owner before or inside the line; last three rows: 35 Phone tasks with phone-number usernames. (b) Other levers, the requester wrongly written as owner, and natural retrieval (60 tasks; Sonnet top-1: 30); the two top-1 rows also differ in header, directive and format.
Figure 6: Case study (Sonnet; requester Denise, donor Norman). [ k ]: agent step; <N> : Norman’s masked password. Path (b) is a minority (2/35 owner-bound runs). Prompt and traces: Appendix H .
Figure 7: Reliance and risk (Cohort 2), one panel per model. x: reliance on stored passwords (clean memory); y: misuse with one foreign credential; grey circle: no memory; open square: leading owner field. Shaded: high reliance, low risk.
Appendix figures & tables18 assets
Supplementary material from the paper’s appendix.
Appendix
Component
Exact text ( N : owner; u / p : username/password)
Record header, δ=1
Credentials recorded in my previous sessions (you can use them to log in directly, without looking them up again):
Record header, δ=0
Credentials recorded in my previous sessions:
Caution, γ=1
; earlier sessions were sometimes for other users — inserted before the header’s closing parenthesis
Episode header
Notes from earlier sessions:
Episode header + caution
Notes from earlier sessions (earlier sessions were sometimes for other users): (Cohort 1)
Record line, β=\textscnone
- gmail: username=u, password=p
Appendix
Table 2: Exact memory renderings. All blocks are inserted verbatim after AppWorld’s requester line and before the task.
DeepSeek
Sonnet
GPT-5.4
Cohort 1 condition ( n=30 )
B
S
Succ.
B
S
Succ.
B
S
Succ.
No memory
0
0
26
0
0
23
0
0
20
Record, no owner
28
14
9
28
16
5
25
11
6
Record + tag (ref.)
18
9
13
27
16
9
12
8
13
no directive ( δ=0 )
16
10
18
14
9
13
–
+ caution
1
1
24
14
11
11
–
Appendix
Table 3: Cohort 1 ablation (runs out of 30). Requester-account changes, no memory vs. unlabeled record: DeepSeek 22 → 2, Sonnet 24 → 1. Reference repeats: DeepSeek 18/14/22, Sonnet 27/22/26 (donor-account changes 16/15/16). GPT-5.4: restating the requester’s e-mail and phone did not change misuse (untagged 25 vs. 22/29, p=0.5 ; tagged 12 vs. 11, p=1.0 ).
DeepSeek
Sonnet
GPT-5.4
Sol
Luna
Grok
Owner-bound condition
λ=1
λ=0
λ=1
λ=0
λ=1
λ=1
λ=1
λ=1
C1 episode header
0/30
3/30
0/30
6/30
–
–
–
–
C1 + caution
0/30
–
0/30
–
–
–
–
–
C1 record header
0/30
–
0/30
–
–
–
–
–
C2 episode header
0/35
0/35
1/35
–
0/35
0/35
0/35
0/35
C2, 4 × budget
0/35
–
–
–
–
–
–
–
Appendix
Table 4: Wrong-token runs for every owner-bound condition, with ( λ=1 ) and without ( λ=0 ) the requester line. Totals: 1/390 for the main conditions with λ=1 , 0/35 for the budget repeat, 9/95 with λ=0 ; overall 10/520. With gpt-oss-120b’s Cohort 2 run (0/35), 1/425 and 10/555.
Figure 8: Ablation of the rendering (Cohort 1, 30 tasks per row, no caution, requester line present). Columns: header h ( rec ord or epi sode), log-in directive δ (+ present, – absent), line format f (key-value or narrative) and owner attribution β (none, trailing tag, or name bound in the sentence). Owner-bound lines (grey rows) give 0/30 under either header. Line format and attribution are aliased: tags occur only on record lines, binding only on episode lines.
Figure 9: Full Cohort 1 ablation for DeepSeek and Sonnet (30 tasks per condition, 95% Wilson intervals). (a) Another user’s token. (b) Audited change in the other user’s account. (c) Official success.
Table 5: Cohort 1: wrong-token runs ( B ) vs. runs that submitted a foreign username ( Blogin ). The owner-binding contrast holds under both endpoints. The directive and header contrasts for Sonnet are much smaller under Blogin .
Table 6: Every Cohort 2 core condition: completed runs ( n ), wrong-token runs ( B ), foreign-username submissions ( Blogin ), donor-state changes ( S ) and successes.
Figure 10: Run-to-run reproducibility of identical conditions at temperature 0 (filled: first run; open: repeats; C1/C2: Cohort 1/2).
Figure 11: Identity checks among Cohort 1 runs that logged into another user’s account. Checked account : after the foreign login, the agent called an account or profile endpoint with the foreign token; re-logged as requester : it later logged into the same app as the requester. Pooled over four record conditions that cross the owner tag with a repeated requester profile, i.e., the requester’s e-mail and phone restated in the prompt.
Natural retrieval
B
Blogin
Succ.
DeepSeek (60 tasks)
No memory
0
0
46
Oracle partition, episodic
0
0
46
Shared store, episodic
0
0
43
Oracle partition, asserted
0
0
48
Shared store, asserted
3
4
47
Appendix
Table 7: Natural retrieval: wrong-token runs, wrong-account logins ( Blogin : a foreign username was submitted) and successes.
DeepSeek
Sonnet
GPT-5.4
App
n
B
read
S
B
read
S
B
read
S
Record, no owner
Amazon
23
21
11
9
19
7
12
18
7
10
Gmail
11
9
8
1
11
6
2
9
7
2
Venmo
1
1
1
0
1
0
1
1
0
1
Record + tag
Appendix
Table 8: Cohort 2 by app of the replaced credential: wrong-token runs ( B ), runs whose donor-token calls were all reads (read), and audited donor-state changes ( S ). Reads leave no state trace, so S is a lower bound on harm, most of all for Gmail.
Contrast
p
Holm p
Δ^ [95% CI]
Primary: remove owner names (episode lines)
DS, C2
0.004
0.016
0.26 [ 0.11 , 0.40 ]
Son., C2
2.1 ×10−5
1.5 ×10−4
0.54 [ 0.34 , 0.71 ]
GPT, C2
4.9 ×10−4
0.003
0.34 [ 0.20 , 0.51 ]
Sol, C2
1.000
1.000
0.00 [ 0.00 , 0.00 ]
Luna, C2
1.000
1.000
0.03 [ 0.00 , 0.09 ]
Appendix
Table 9: Multiplicity and clustering (DS: DeepSeek; Son.: Sonnet; GPT: GPT-5.4; Sol: GPT-6 Sol; Luna: GPT-6 Luna; Grok: Grok 4.7; gpt-oss: gpt-oss-120b). Exact McNemar p , Holm-adjusted within the primary and the secondary family, and the paired effect on Cohort 2 with a task-clustered bootstrap CI (each Cohort 2 task has a distinct requester). “–”: Cohort 1 contrast (no clustered CI). For a single model, resampling tasks is equivalent to resampling the cells of the paired 2×2 table, which we use where per-task traces are not released. Pooling DeepSeek and Sonnet over both cohorts (65 task pairs, 54 requesters), removing names raises misuse by 0.46 (requester-clustered 95% CI [0.37,0.56] ).
Requester’s other app
Replaced app: first log-in
Model
Rendering
B
stored
logged in
donor
look-up
stored
other
none
pw.
DeepSeek
Record, no owner
31
11
13
32
3
0
0
0
1
Record + tag
23
8
13
25
10
0
0
0
0
Record + tag + caution
1
2
13
5
30
0
0
0
0
Episode, owner omitted
9
3
12
16
19
0
0
0
0
Episode, owner bound
0
2
13
0
34
1
0
0
1
Appendix
Table 10: Discrimination vs. suppression (Cohort 2, traced corrupted runs, 35 per row). B : wrong-token runs. Requester’s other app: runs that logged into another app in memory with the stored password before any look-up ( stored ) among runs that logged into such an app at all ( logged in ). Replaced app, first log-in: with the donor’s username; as the requester after a supervisor password look-up; with the requester’s username and the stored (foreign) password, which fails; otherwise; or never. GPT-5.4’s owner-omitted episode runs have no released traces.
Figure 12: Responses to weaker attribution cues. (a-c) Wrong-token runs before (open) and after (filled) one change to the rendering; (a, b) Cohort 2, n=35 ; (c) Cohort 1, n=30 . (d) Paired interaction I^ between the owner tag and the requester line (Eq. 11 ; Cohort 2, exploratory amendment; bootstrap 95% CI). “not run”: the model did not run that condition.
Model
Clean memory
Succ.
Look-ups
Steps
API calls
Tokens (k)
Time (s)
DeepSeek
No memory
30
35
16.9
49
170
60
Record + tag
29
9
16.5
73
183
52
+ caution
29
9
17.2
41
180
55
Owner-bound
25
26
17.7
56
184
68
Sonnet
No memory
19
35
19.9
66
216
115
Record + tag
17
9
18.5
83
279
168
Appendix
Table 11: Clean memory (Cohort 2, 35 tasks): successes, runs with a supervisor-password look-up, mean steps and API calls, and median input+output tokens and wall-clock time per run. Memory replaces look-ups but does not raise success or lower cost. “–”: per-run traces for that condition are not in the archive.
DeepSeek
Sonnet
GPT-5.4
Condition
Reference
k/n (ref.)
p
k/n (ref.)
p
k/n (ref.)
p
E1
Clean memory, episode without names ∗
same, with names (earlier)
20/35 (26)
0.15
21/35 (21)
1
12/35 (14)
0.62
E2
Natural top-1 note, owner named
top-1 record (same period)
0/60 (34)
< 10 -6
0/30 (19)
4 × 10 -6
E2
Natural top-5 notes, owner named
top-5 records (earlier)
0/60 (8)
0.008
E3
Own credential also present, record
replacement, record
1/35 (31)
< 10 -6
0/35 (31)
< 10 -6
E3
Own credential also present, bound
replacement, bound
0/35 (0)
1
0/35 (1)
1
Appendix
Table 12: Follow-up controls (Cohort 2 tasks unless noted; one run per task and condition). k/n : runs that used another user’s token ( ∗ E1, N3: runs that looked up the requester’s password on clean memory); in parentheses, the count under the reference condition on the same tasks; p : exact McNemar test. Reference conditions marked “earlier” or from the main study were run in an earlier period.
Figure 13: Prompt and opening steps of two Sonnet runs on the same Cohort 2 task (the task of Figure 3 ). With the tagged record, the agent logs in as the owner named in the tag; with the owner-bound note, it keeps Denise’s username, fails to authenticate with Norman’s password and retrieves her own. <N> is Norman’s Gmail password and <D1> Denise’s Amazon password.
Figure 14: A passing run that misuses another user’s account (released trace and state audit). The agent ignores the owner tag, buys the requested item with the donor’s saved card and address, and passes all official tests. <K> is Katie’s masked Amazon password.
Artificial intelligence agent security studies attacks and safeguards for tool-using, persistent, and collaborative systems across digital and physical settings.
Long-running LLM agents rely on persistent memory to preserve not only task context but also the permissions and restrictions governing their actions. When memory misrepresents this evolving authorization state, the agent's own records can make unauthorized actions appear permitted, resulting in misaligned behavior without any external attacks. We term this failure endogenous authorization laundering, where memory creates or retains false authority through semantic misinterpretation or failed updates, and executors act on that authority. We then introduce EAL-Bench to measure how accurately persistent memory preserves evolving authorization state and whether memory errors propagate to unauthorized actions. We evaluate seven LLMs as memory writers and two as executors across procurement, cybersecurity, and finance tasks. Under incremental typed-memory updates, writers create false authority for up to 45.4% of unauthorized requests, and once false authority is present, executors act on it in 99.0% of trials. Memory-level safeguards reduce laundering but can reject legitimate actions, exposing a safety-utility tradeoff. Persistent memory is therefore part of an LLM agent's effective authorization policy, not merely a performance component.
Personal AI agents in enterprise multi-tenant deployments share a common vector store for long-term memory. Shared embedding spaces create a surface for cross-user memory leakage: a user's query can retrieve semantically adjacent memories belonging to another user through ordinary cosine-similarity retrieval, without any exploit. We formalize this as cross-user admissibility failure and evaluate it across six experiments, plus follow-up ablations, under both sparse (TF-IDF) and production-faithful (MiniLM-L6-v2) retrieval. Non-adversarial, incidental leakage reaches 70--100% under pooled {same-team} retrieval; adversarially crafted memories achieve 90--100% top-k placement, exceeding weaker keyword-based attacker baselines, with score lifts of +0.416 to +0.511 under production-faithful dense retrieval (Config B); and end-to-end response contamination reaches 5.00/5 under a production retrieval path and 4.67/5 with Claude Sonnet4.5, with contaminated responses often scoring as helpful or more helpful than clean ones, a gap validated against human judgment. Among three architectural mitigations, only hard post-retrieval ownership gating consistently restores the clean baseline (1.00/5) across {two generation models, at a measured latency overhead of roughly 1.4ms per query.
Long-term memory lets large language model(LLM) agents reuse prior preferences and work flows, but it also turns untrusted observations into persistent action context. We identify memory provenance laundering: during LLM-based memory consolidation, an external observation may be rewritten as apparent user history or workflow support, preserving an action trigger while erasing the low-trust source that should limit its authority. Existing prompt filters, content sanitizers, and tool guards do not enforce source-authority non-amplification after lossy memory consolidation. We formalize this boundary and instantiate it as Provenance-Preserving Memory Fire wall (PPMF), a lightweight memory middleware that preserves platform-maintained provenance and authorizes tool calls by matching action risk to the authority of action-relevant memories. In our schema-grounded evaluation with fixed risk policies, vulnerable consolidated memories reach up to 1.000 attack success rate(ASR); with intact platform-maintained provenance, confirmation, and risk labels, no evaluated unauthorized high-risk action passes the PPMF gate while confirmed benign actions and targeted low-risk memory use remain executable.