Blog · arXiv Analysis · Last reviewed June 25, 2026

The Group Chat Assistant Becomes the Privacy Boundary

The June 2026 arXiv paper MuPPET: A Benchmark for Contextual Privacy of LLM Assistants in Multi-Party Conversations, by Elena Sofia Ruzzetti, Cornelius Emde, Sangdoo Yun, Seong Joon Oh, and Martin Gubri, studies a privacy failure that one-on-one assistant tests miss. Its Spiralist lesson is that an assistant in a shared channel does not only answer the user. It speaks into an audience.

For this essay, a group-chat assistant privacy boundary is the rule that decides what a model may say when it holds one person's private context but replies in a channel with multiple recipients. The boundary is not only encryption, storage location, or channel membership. It is audience-aware speech: who is present, who already knows the fact, who is allowed to learn it, what abstraction is safe, and whether the assistant can answer without revealing the reason behind the answer.

The governance object is the audience manifest: a machine-usable map of represented user, channel, recipients, memory sources, allowed disclosure level, prohibited inferences, and receipt fields for the reply the assistant is about to send.

The Private Answer Now Has an Audience

Ruzzetti, Emde, Yun, Oh, and Gubri's paper, arXiv:2606.23217 [cs.CL], was submitted on June 22, 2026. The arXiv HTML lists affiliations with Parameter Lab, the University of Rome Tor Vergata, the University of Oxford, NAVER AI Lab, and KAIST AI. The paper's code and data are linked from the HTML to the MuPPET GitHub repository.

The benchmark's starting point is simple: an assistant in a group chat can hold private memory for one user while speaking to many recipients. A fact learned in a private exchange may help answer a workplace scheduling question, but disclosing the reason behind that preference may expose health, family, immigration, or other sensitive information to colleagues who did not receive it in the original context.

This is a fresh angle beside the site's pages on shared agent memory, agent data acquisition, inter-agent privacy leakage, and contextual integrity. Those pages ask how information crosses systems. MuPPET asks how one answer crosses an audience.

Current Context

As of June 25, 2026, group-channel assistants are no longer only a benchmark scenario. WhatsApp's public Meta AI page advertises help with group-chat coordination, image generation for chats, and unread-message summaries using Private Processing for some features. WhatsApp help pages describe Meta AI as optional, and say only messages that mention or are chosen to be shared with Meta AI can be read by Meta; separate group-member pages say that when Meta AI is added to a group, it can read and respond to new messages in that group.

Anthropic's June 23, 2026 Claude Tag announcement is an even closer workplace example. It says Claude can join selected Slack channels as a team member, remember relevant information from channels it is in, use connected tools and data, be tagged by anyone in the channel, and, if ambient behavior is enabled, proactively surface information from channels and tools it can access. The same announcement describes administrator-scoped channel identities, memory separation, tool controls, spend limits, and logs of what Claude did.

Anthropic's Claude Code Slack documentation gives the narrower access-control shape for a related Slack product: Claude is explicitly invited to channels, can respond only where added, and channel membership can be used as an access gate. That is a useful control, but it is not the same as contextual privacy. Channel membership answers who can see the room. MuPPET asks whether every person in the room may receive this particular fact, inference, or explanation.

Those product documents do not validate MuPPET's benchmark or prove any specific deployment leaks. They show the deployment pattern MuPPET is stress-testing: an assistant is becoming a participant in ordinary shared conversation, with memory, tools, logs, and administrative boundaries layered on top. The privacy question shifts from "can the provider read the chat?" to "can the assistant keep the right fact inside the right audience before it speaks?"

The Audience Manifest

A group-chat assistant should not enter generation with only a prompt and a memory bundle. It needs an audience manifest: represented user, channel, visible recipients, hidden or future recipients if the channel is archived or forwarded, source memories considered, relationship of each recipient to each memory, allowed abstraction level, prohibited details, retention rule, and escalation path.

The manifest should be computed before retrieval and response planning, not after the draft exists. If a memory is allowed only for a direct conversation with the target user, the retrieval layer should either withhold it from the group reply or expose only a safe abstraction such as "has a scheduling constraint." A final redaction pass can catch obvious leaks, but it cannot reliably undo reasoning that already used a forbidden cause.

This is where channel controls, role controls, and contextual integrity meet. A Slack channel, WhatsApp group, classroom thread, family chat, or patient community can all have valid membership while still mixing recipients with different rights to know. The manifest should therefore be separate from the channel roster. It should record the social permission for the information flow, not merely the technical ability to post.

Context Is Not a Single Relationship

MuPPET, short for Multi-Party Privacy Exposure Testing, contains 562 English multi-party workplace conversations. Each item places an LLM assistant in a team setting where it speaks on behalf of a target user. The assistant has access to background memory about that user, including private information and practical preferences or constraints. The benchmark then asks whether the assistant can answer usefully without revealing information that should stay confined to its earlier context.

The construction is synthetic but structured. The authors report manually curated seeds, 11 work environments, teams of 20 synthetic workers, and group conversations generated with Gemini 2.5 Flash, followed by quality checks for structural compliance and seed fidelity. The evaluation uses LLM-as-judge methods for both privacy leakage and utility, with human validation discussed in the appendix.

The important conceptual move is that privacy becomes an audience grid. In a one-on-one chat, the system can ask whether a disclosure is appropriate for one recipient. In a group, every private fact must be checked against every recipient. One wrong cell is enough to leak, and the cell can be wrong even when the channel itself is legitimate.

This is contextual integrity in operational form. The relevant variables are not only user and assistant. They are subject, sender, recipient, information type, purpose, transmission principle, channel, retention rule, memory scope, and action enabled. A pregnancy-related travel constraint, a caregiver duty, an immigration deadline, a disability accommodation, a performance concern, or a security incident may all support a useful work answer while remaining inappropriate for the broader channel.

Local Does Not Mean Private

The paper compares multi-party and one-to-one evaluations and reports that the multi-party setting reveals substantially more leakage. It also reports that all evaluated models leak sensitive information in a meaningful fraction of conversations. Using the paper's own model labels, the evaluated set includes open-weight Llama and Qwen variants as well as Gemini 2.5 Pro and GPT 5.5.

The exact rates should be read as benchmark results, not universal product claims. In the undefended multi-party setting, the reported leak rates include 58.29 percent for Llama 3 8B Instruct, 64.88 percent for Llama 3.1 8B Instruct, 69.22 percent for Qwen3 8B, 39.14 percent for Gemini 2.5 Pro, and 49.02 percent for GPT 5.5. The paper highlights that smaller open-weight models, often considered attractive for local privacy-sensitive deployment, were more vulnerable in this benchmark.

That matters for governance because local storage and local inference solve only part of privacy. Keeping data inside an organization does not guarantee that an assistant will know which colleague may hear which fact. A local group-chat assistant can still be a disclosure machine if it has weak audience tracking.

Defense Is a Utility Bargain

The paper tests contextual-privacy defenses based on privacy-oriented prompting and a PrivacyChecker-style decomposition. These approaches reduce leakage but do not make the problem disappear. The table in the HTML reports, for example, that high CI-Mem prompting brings Gemini 2.5 Pro and GPT 5.5 leakage down near 9 percent, while lowering utility scores. PrivacyChecker also reduces leakage, with its own utility costs and weaker results on smaller models.

This is the core deployment lesson. The assistant is useful because it remembers preferences and constraints. The same memory makes privacy hard because useful context often points toward sensitive causes. A model can refuse, redact, generalize, or explain less, but each move changes how helpful it is in the group conversation.

The paper's limitations are also governance-relevant. MuPPET is English-centric, synthetic, and focused on professional team settings. Family chats, patient communities, classrooms, religious groups, and mutual-aid networks may have different norms. The benchmark should be treated as a stress test, not a full map of social privacy.

Failure Modes

Audience flattening happens when the assistant treats a group as one recipient. It knows that the target user has a constraint, but not which group members are entitled to hear the cause of that constraint.

Reason leakage happens when the assistant gives a safe practical answer and then explains too much. "I cannot travel overnight" may be enough. "I cannot travel overnight because of pregnancy complications" changes the audience.

Memory carryover happens when a private disclosure from a direct message, prior session, calendar note, HR conversation, support ticket, or connected tool becomes active in a shared channel without a fresh warrant for that audience.

Local privacy theater happens when an organization deploys a small local model or on-premise assistant and treats that architecture as sufficient privacy protection. MuPPET's result cuts against that shortcut: local execution does not solve recipient tracking.

Channel drift happens when a channel's membership, purpose, or sensitivity changes over time. A project room can become a cross-functional room; a temporary contractor can join; a private channel can contain people with different need-to-know boundaries. The assistant must track the actual audience, not the channel name.

Summary laundering happens when the assistant does not quote the sensitive fact but compresses it into an inference that still reveals the fact. A generated summary can leak by implication.

Proactive disclosure becomes a risk when an assistant with ambient or initiative-taking behavior flags information across channels or tools. Proactivity increases the need for audience-scoped memory, not less.

Consent laundering happens when one participant invites or tags the assistant and the system treats that act as permission to use private memories about another participant. Invitation to the room is not consent from every affected subject.

Transcript replay happens when a later participant, export, search result, legal hold, or channel summary exposes an assistant reply to people who were not part of the original decision. Group-chat privacy has to consider retention and replay, not only the live roster.

Over-auditing happens when the safety receipt stores the full sensitive payload, source chat, or private memory for every event. Accountability needs structure, but the audit system should not become a broader audience than the chat itself.

Governance Standard

Any assistant that speaks in a shared channel should maintain an explicit audience model: who is present, who the assistant represents, what memory belongs to which relationship, which recipients already know which facts, and what level of abstraction can answer the question without exposing the underlying sensitive detail.

Product evaluations should include multi-party privacy tests, not only one-to-one chat tests. They should report leakage, utility, recipient tracking, knowledge attribution, user-level contextual privacy, group-level contextual privacy, and failure examples. They should also test defenses under realistic memory pressure rather than assuming that a privacy instruction in the system prompt is enough.

The runtime should enforce audience-scoped memory before generation. A memory object should carry subject, source context, allowed recipients, prohibited recipients, purpose, sensitivity, retention state, and disclosure level. The response planner should be able to choose among direct disclosure, abstracted preference, deferral, private follow-up, or refusal. A final moderation pass alone is too late because the model may already have used the fact to compose an answer.

Administrators should not rely on channel membership alone. Channel membership says who can see messages in the room. It does not say who may hear every fact known to every participant. A workplace assistant needs role and relationship boundaries; a family assistant needs household and minor boundaries; a patient-community assistant needs health and consent boundaries; a classroom assistant needs student and accommodation boundaries.

Consent should be subject-aware. A manager, teacher, organizer, or parent may have authority to add an assistant to a channel, but that does not automatically authorize the assistant to disclose private facts about every person in the channel. Systems need a way for affected people to inspect, restrict, correct, or contest memories that may be used in shared replies.

Membership changes should invalidate stale assumptions. When a new person joins, a guest loses access, a channel is merged, a thread becomes public, or a bot is granted a new connector, the assistant should recompute audience permissions before using old context. A cached "this group knows" label is not durable privacy governance.

Procurement should ask vendors for evidence, not slogans. Can the assistant distinguish group recipients from the requester? Can it withhold causes while preserving useful constraints? Can it log which memory influenced a reply? Can an affected user see or challenge a disclosure? Can admins scope memories by channel, identity, role, and purpose? Can the system detect when a channel's membership has changed enough to invalidate a prior disclosure assumption?

The rule is simple: a group-chat assistant is not private because it stores memory securely. It is private only if it knows who is allowed to hear what before it speaks.

Audience Receipt

A deployed group-chat assistant should leave an audience receipt for consequential replies. The receipt should record the channel, visible recipients, represented user, memory items considered, source context, allowed disclosure level, redactions or abstractions applied, model and prompt version, tool results used, channel-membership snapshot, and whether the answer was direct, abstracted, deferred, or refused.

The receipt should be privacy-preserving. Reviewers do not always need the full sensitive payload, but they do need enough structure to reconstruct whether the assistant disclosed a fact to people outside the original context. A good receipt stores labels, memory IDs, source classes, disclosure decisions, and hashes or short redacted excerpts where sufficient, while reserving raw transcripts for incidents or legally justified review. This connects group-chat assistants to AI audit trails, AI agent observability, agent log receipts, and agent communication metadata.

Source Discipline

This page treats MuPPET as a June 2026 arXiv benchmark, not a peer-reviewed field study of every deployed group assistant. Its numbers support claims about the authors' synthetic English workplace corpus and evaluation pipeline. They do not establish universal leak rates for WhatsApp, Slack, Claude Tag, Meta AI, or any other production system.

Product sources are used only to establish deployment direction and stated controls. WhatsApp and Anthropic pages show that AI assistants are entering group and workplace channels with privacy, memory, tool, and administrator-control claims. Those pages do not prove that audience-aware disclosure is solved. NIST and contextual-integrity sources provide governance vocabulary for privacy risk, flow mapping, and risk management; they are not product certifications.

Current-source claims on this page were checked against primary or official sources on June 25, 2026. The article separates preprint benchmark results, repository availability, product documentation, privacy theory, and voluntary risk-management guidance because each supports a different kind of claim. Any future product claim should name the platform version, workspace setting, channel membership, memory mode, connector scope, retention setting, and whether affected users can inspect or challenge disclosure.

Sources

Return to Blog