cs.CRNov 21, 2025

Cross-User Poisoning: User-Task Boundary Failures in Multi-User Collaborative Language Agents

Authors: Atharv Singh Patlan, Peiyao Sheng, S. Ashwin Hebbar, Prateek Mittal, Pramod Viswanath

Organizations: Princeton University · Sentient

Read PDF
Ask AI
Cite

Copy citation

DOINot available for this paper

Abstract

Language agents are moving from single-user assistants to shared collaborators in workspaces, forums, and group chats. A shared agent observes interleaved messages from multiple users, maintains persistent context, and executes tool actions, creating a boundary problem absent from standard single-user agents: the agent must decide not only whether an instruction is safe, but which user or task it is allowed to govern. We identify cross-user poisoning (CUP), where an adversary injects a message into shared context that is later applied while the agent serves a benign user, causing unauthorized actions or responses outside the instruction's intended scope. We validate CUP on two deployed multi-user agents, Continua and ElizaOS, and introduce MURMUR, a framework for evaluating shared-context agents under concurrent multi-user interactions. Across Slack, Workspace, and Airline domains, CUP achieves high attack success, persists across later interactions, and remains substantially more effective than matched prompt-injection attacks. We evaluate boundary-scoping defenses and find that context summarization alone is insufficient, while task clustering and provenance prompting substantially reduce non-adaptive propagation. These results show that robust multi-user agents require explicit user/task scoping rather than generic input filtering or context compression.

Figures & tables

Figure 1: Cross-user poisoning differs from standard single-user attacks. Left: In single-user prompt injection (PI) or jailbreaking, defenses target malicious instructions from the current user or untrusted data. Middle: In CUP, a legitimate-looking instruction from one user can persist in shared context and later affect another user, as shown in a real-world attack on Continua ( Continua, 2025 ) . Right: Existing defenses do not cleanly transfer: jailbreak filtering reduces but does not eliminate CUP, while instruction detectors for PI over-flag benign collaborative messages, reducing utility.
AttackAdversarial sourceBoundary exploitedConsequence
JailbreakCurrent userPolicy or safety boundaryModel policy/safety violation in current users’ session
Prompt InjectionExternal data sourceInstruction–data boundaryHarm to current users due to untrusted content being consumed as instruction
Cross-user PoisoningAnother legitimate user in shared contextUser, identity, and task boundaryOne user’s instruction propagates to other users or workflows, potentially persisting across shared context
Table 1: Boundary-based taxonomy of agent attack vectors.
Figure 2: Cross-platform CUP in ElizaOS. Left: An attacker in Discord instructs ElizaOS to send future airdrops to an attacker-controlled wallet. Middle: Later, a benign user on X requests a transfer to a different address. Right: While serving this user, ElizaOS applies the attacker-planted rule and transfers funds to the attacker’s wallet instead of the requested destination.
Figure 3: Workflow of MURMUR . Benchmark tasks are adapted into shared multi-user sessions, interleaved in a common transcript, optionally poisoned by an attacker message, and evaluated for both task utility and cross-user robustness.
Figure 5
ModelCUPCUP+ProtectAI
GPT-4.169.443.3
4.1-mini51.030.7
4.1-nano18.86.7
Sonnet 484.956.3
GPT-5.438.622.3
Table 2: ASR(%) for CUP. CUP retains a significantly high ASR even in the presence of an input filtering jailbreaking defense. 95% CIs in Appendix L .
Figure 7
Env.DefenseASRTSR under attackNo-defense TSR
SlackTask clustering0 0.0 [0.0, 5.5]64.0 [50.0, 76.2]81.0 [73.2, 86.9]
Context aug.0 0.0 [0.0, 3.5]96.2 [90.6, 98.5]
Summarization23.3 [14.6, 35.5]56.4 [53.3, 59.5]
WorkspaceTask clustering0 0.0 [0.0, 4.6]72.8 [68.6, 78.3]72.1 [66.1, 77.4]
Context aug.0 0.0 [0.0, 1.4]95.4 [92.2, 97.3]
Summarization32.9 [29.3, 37.8]53.8 [49.9, 56.2]
Table 3: Boundary-scoping defenses on GPT-4.1 over three runs (%, with 95% confidence intervals). Defended TSR is measured under attack; no-defense TSR is without attack or defense.
Appendix figures & tables21 assets

Supplementary material from the paper’s appendix.

Appendix

 xt∼G( ⋅∣πGg(ut)(Ht),ut,ρut,Dg(ut))x_{t}\sim\mathcal{G}(\,\cdot\mid\pi_{G_{g(u_{t})}}(\mathcal{H}_{t}),u_{t},\rho_{u_{t}},D_{g(u_{t})}) 
Appendix
Algorithm 1 MURMUR Conversation Session
CategoryPersonaCategoryPersona
Behavioradmits_mistakesEmotionangry
Behaviorbudget_constrainedEmotioncalm
BehaviorcooperativeEmotiondistraught
BehaviorpersistentEmotionimpatient
BehaviorpersuasiveEmotionstressed
Behaviorprefers_human_escalationEmotionworried
Appendix
Table 4: List of user personas in MURMUR
TemplateWorkspaceSlackAirline
Main45.081.981.3
T1: minimal role-style39.768.279.5
T2: natural language38.664.472.1
Appendix
Table 5: ASR(%) under alternative CUP attacker-message templates on GPT-4.1. CUP remains effective across different templates, showing that CUP is not specific to the original wrapper.
DefenseBenign FP (%)
DataSentinel89.06
MELON100.00
PromptGuard53.12
GPT-5.4 Judge35.53
Appendix
Table 6: False-positive rates of input-level defenses on benign user messages.
TS-Guard settingBenign sessions disrupted (%)Successful CUP sessions detected (%)
Risk =1.0=1.01.2031.5
Risk ≥0.5\geq 0.527.9385.4
Appendix
Table 7: Security–utility trade-off of the TS-Guard action-level guard on GPT-4.1.
Figure 8: Utility and tool-use behavior under increasing task concurrency. TSR remains stable through moderate concurrency, while tool calls initially decrease and then rebound at higher concurrency.
ModelTau-bench (Airline)AgentDojo (Slack)AgentDojo (Workspace)
GPT-4.146.781.072.1
Claude Sonnet 434.467.770.4
GPT-4.1-mini30.071.550.2
GPT-4.1-nano12.252.445.7
GPT-5.459.395.092.5
Appendix
Table 8: Task Success Rate (TSR, %) with three concurrent tasks across benchmarks.
ModelWorkspaceSlackAirline
No DefenseProtAINo DefenseProtAINo DefenseProtAI
GPT-4.145.03481.96681.330
GPT-4.1-mini37.53046.73468.728
GPT-4.1-nano6.252.9247.313
Claude Sonnet 479.65895.27880.033
GPT-5.432.52428.62254.721
Appendix
Table 9: Average ASR (%) under external defenses. For ProtectAI, ASRs are recomputed after flagged templates are removed.
DomainTSRASR
Airline14.0%83.51%
Slack61.2%79.76%
Workspace54.6%43.33%
Appendix
Table 10: Performance of GPT-4.1 TSR and ASR when all simulated users see all messages
Model≥\geq 1≥\geq 2≥\geq 3≥\geq 4≥\geq 5
GPT-4.11511984
GPT-4.1-mini1610871
GPT-4.1-nano30000
Claude Sonnet 42520201918
Appendix
Table 11: Slack (5 concurrent tasks): cross-user poisoning persistence (CDF counts). Totals per model == 25 sims; “ ≥j\geq j ” = persisted to at least task jj .
Model≥\geq 1≥\geq 2≥\geq 3≥\geq 4≥\geq 5
GPT-4.1302418159
GPT-4.1-mini2715933
GPT-4.1-nano120000
Claude Sonnet 44848484539
Appendix
Table 12: Workspace (5 concurrent tasks): persistence (CDF counts). Totals per model == 48 sims.
Model≥\geq 1≥\geq 2≥\geq 3≥\geq 4≥\geq 5
GPT-4.1272423218
GPT-4.1-mini262117104
GPT-4.1-nano20161087
Claude Sonnet 4302725239
Appendix
Table 13: Airline (5 concurrent tasks): cross-user poisoning persistence (CDF counts). Totals per model == 30 sims; “ ≥j\geq j ” = persisted to at least task jj .
# TasksAirline (300)Slack (126)Workspace (240)Total
113489186409
214594180419
3140102173415
413899169406
513190169390
Appendix
Table 14: Task Success Rate under concurrency (GPT-4.1). Results computed over 666 total trials: Airline (300), Slack (126), Workspace (240). TSR increases slightly at two tasks, then declines as interference grows.
# TasksAirlineSlackWorkspaceAverage
16.21 ±\pm 0.338.94 ±\pm 0.084.14 ±\pm 0.036.43
25.88 ±\pm 0.198.60 ±\pm 0.173.98 ±\pm 0.056.15
35.17 ±\pm 0.207.44 ±\pm 0.183.64 ±\pm 0.045.42
45.40 ±\pm 0.216.83 ±\pm 0.123.59 ±\pm 0.075.27
57.49 ±\pm 0.347.06 ±\pm 0.093.90 ±\pm 0.036.15
Appendix
Table 15: Tool use under concurrency (GPT-4.1). Values averaged over 666 total trials: Airline (300), Slack (126), Workspace (240). Tool calls per task decrease initially, then rise again as confusion accumulates.
 SlackWorkspaceAirline
ModelPICUPPICUPCUP
GPT-4.11.9 [0.5, 6.7]81.9 [73.5, 88.1]0.0 [0.0, 1.6]45.0 [38.8, 51.3]81.3 [74.3, 86.8]
GPT-4.1-mini3.8 [1.5, 9.4]46.7 [37.4, 56.2]0.4 [0.1, 2.3]37.5 [31.6, 43.8]68.7 [60.9, 75.5]
GPT-4.1-nano1.9 [0.5, 6.7]2.9 [1.0, 8.1]1.7 [0.6, 4.2]6.2 [3.8, 10.1]47.3 [39.5, 55.3]
Claude Sonnet 41.0 [0.2, 5.2]95.2 [89.3, 97.9]0.0 [0.0, 1.6]79.6 [74.0, 84.2]80.0 [72.9, 85.6]
GPT-5.40.0 [0.0, 3.5]28.6 [20.8, 37.8]0.0 [0.0, 1.6]32.5 [26.9, 38.7]54.7 [46.7, 62.4]
Appendix
Table 16: ASR (%) of PI and CUP with 95% Wilson confidence intervals (cf. Tables 7 and 9 ).
ModelCUPCUP+ProtectAI
GPT-4.169.4 [65.6, 73.2]43.3 [39.0, 47.7]
GPT-4.1-mini51.0 [46.4, 55.5]30.7 [26.4, 35.0]
GPT-4.1-nano18.8 [15.8, 21.8]6.7 [4.5, 8.9]
Claude Sonnet 484.9 [81.9, 88.0]56.3 [52.1, 60.5]
GPT-5.438.6 [34.2, 43.0]22.3 [18.5, 26.2]
Appendix
Table 17: CUP ASR (%) averaged over the three environments with stratified 95% confidence intervals (cf. Table 2 ).
Env. (sessions)APR2\mathrm{APR}_{2}APR3\mathrm{APR}_{3}APR4\mathrm{APR}_{4}APR5\mathrm{APR}_{5}
Slack (59)69.5 [56.9, 79.7]62.7 [50.0, 73.9]57.6 [44.9, 69.4]39.0 [27.6, 51.7]
Workspace (117)74.4 [65.8, 81.4]64.1 [55.1, 72.2]53.8 [44.8, 62.6]43.6 [34.9, 52.6]
Airline (103)85.4 [77.4, 91.0]72.8 [63.5, 80.5]60.2 [50.5, 69.1]27.2 [19.5, 36.5]
Appendix
Table 18: Attack persistence rates (%) at k=5k=5 with 95% Wilson confidence intervals, over sessions with at least one successful attack ( APR1=100%\mathrm{APR}_{1}=100\% ; cf. Figure 7 ).
Figure 9: Mallory introduces a response-style preference and link-inclusion rule.
Figure 10: Continua applies Mallory’s preference while responding to Krimo.
Figure 11: Krimo’s counter-instruction also propagates across users.
Figure 12: The attacker turns a user-specific preference into a persistent global rule.
More in this topic

Data Poisoning Attacks

Data poisoning attacks manipulate training or retrieval data to corrupt model behavior, implant backdoors, or undermine reliability.

See all 123 papers

Explore similar work

CardsList
Apr 1, 2026

No Attacker Needed: Unintentional Cross-User Contamination in Shared-State LLM Agents

LLM-based agents increasingly operate across repeated sessions, maintaining task states to ensure continuity. In many deployments, a single agent serves multiple users within a team or organization, reusing a shared knowledge layer across user identities. This shared persistence expands the failure surface: information that is locally valid for one user can silently degrade another user's outcome when the agent reapplies it without regard for scope. We refer to this failure mode as unintentional cross-user contamination (UCC). Unlike adversarial memory poisoning, UCC requires no attacker; it arises from benign interactions whose scope-bound artifacts persist and are later misapplied. We formalize UCC through a controlled evaluation protocol, introduce a taxonomy of three contamination types, and evaluate the problem in two shared-state mechanisms. Under raw shared state, benign interactions alone produce contamination rates of 57--71%. A write-time sanitization is effective when shared state is conversational, but leaves substantial residual risk when shared state includes executable artifacts, with contamination often manifesting as silent wrong answers. These results indicate that shared-state agents need artifact-level defenses beyond text-level sanitization to prevent silent cross-user failures.

Tiankai Yang, Jiate Li, Yi Nian +5

University of Southern California · Michigan State University · Northwestern University +1

LLM Agent SecurityLLM Agent SafetyLLM Agent ReliabilityMemory-Augmented Language Model AgentsLLM Agent Evaluation
AskPDF
Mar 19, 2026

Multi-User Large Language Model Agents

Large language models (LLMs) and LLM-based agents are increasingly deployed as assistants in planning and decision making, yet most existing systems are implicitly optimized for a single-principal interaction paradigm, in which the model is designed to satisfy the objectives of one dominant user whose instructions are treated as the sole source of authority and utility. However, as they are integrated into team workflows and organizational tools, they are increasingly required to serve multiple users simultaneously, each with distinct roles, preferences, and authority levels, leading to multi-user, multi-principal settings with unavoidable conflicts, information asymmetry, and privacy constraints. In this work, we present the first systematic study of multi-user LLM agents. We begin by formalizing multi-user interaction with LLM agents as a multi-principal decision problem, where a single agent must account for multiple users with potentially conflicting interests and associated challenges. We then introduce a unified multi-user interaction protocol and design three targeted stress-testing scenarios to evaluate current LLMs' capabilities in instruction following, privacy preservation, and coordination. Our results reveal systematic gaps: frontier LLMs frequently fail to maintain stable prioritization under conflicting user objectives, exhibit increasing privacy violations over multi-turn interactions, and suffer from efficiency bottlenecks when coordination requires iterative information gathering.

Shu Yang, Shenzhe Zhu, Hao Zhu +5

KAUST · UT Austin · Stanford University +1

LLM AgentsLLM Agent Evaluation
AskPDF
Sep 30, 2026

Worse Together: How Performance Breaks Down in Multi-User Multi-Agent Teams

People are increasingly delegating tasks to AI agents, and those agents are increasingly encountering other people's agents over shared resources such as a codebase, a calendar, or a budget. When each agent acts for a different user with different goals, coordination often fails, and the group ends up worse off than if a single agent had acted for everyone. We study this multi-user, multi-agent setting across five frontier models and 77 scenarios in four environments: an API key environment in which agents share a compute budget, a clinic in which they share a calendar, a personal assistant environment in which they share a group order or booking, and a merge queue in which they share a release cutoff. In each scenario, we compare a single agent that serves every user (a coordinator) to a team in which each agent serves one user, with and without a communication channel between the agents. Teams deliver worse group outcomes than the coordinator in every environment: without a channel, they completely collapse in two environments, and even with one, coordination overhead creates substantial gaps. For example, in the personal assistant environment, the coordinator fulfills a targeted user request about twice as often as teams. We identify distinct behaviors associated with this poor group-level performance, including stalling as teams grow, overriding each other's actions, and fabricating claims. We find effective but environment-specific mitigations, such as a team lead, explicit procedural instructions, and a platform check that makes an agent read its peers' messages before committing. We will release the API key, clinic, and personal assistant environments as MAMUBench, comprising 74 scenarios for evaluating multi-user, multi-agent coordination.

Sahan Paliskara, Nattaput Namchittai, Andrew Lampinen

Independent Researcher · Anthropic

Multi-Agent LLM SystemsMulti-Agent CoordinationAI Agent BenchmarksMulti-Agent SystemsMulti-Agent Communication
AskPDF