The risk with enterprise research agents is often described in the wrong direction. People worry about what the model can see: internal docs, tickets, contracts, roadmaps, incident notes. MosaicLeaks argues that the more dangerous question is sometimes what the agent reveals while it works.

That shift matters.

A deep research agent is useful precisely because it mixes sources. It reads private internal material, then goes out to the web to fill gaps, verify context, connect entities, and complete multi-step questions. The problem is that these outward-facing actions can become a leakage channel. An observer does not need access to the private documents or the model’s hidden reasoning. In the MosaicLeaks setup, all the adversary sees is the agent’s external query log.

That is enough surprisingly often.

The paper, MosaicLeaks: Privacy Risks in Querying-in-the-Open for Deep Research Agents, introduces a benchmark of 1,001 multi-hop tasks that deliberately force this blend of private and public retrieval. The benchmark chains enterprise documents with web content so the agent has to move back and forth between local context and external search. This is not a contrived single-prompt jailbreak story. It is a benchmark built around ordinary research behavior.

That is why it deserves attention from developers, security teams, product leaders, and any company planning to deploy research agents on top of internal knowledge.

The core issue is the mosaic effect

The most important idea in MosaicLeaks is not a new model trick. It is the mosaic effect.

A single web query may look harmless. A second one may also look harmless. But when several queries are seen together, they can reveal a private fact that none of them fully exposed on its own. The leak emerges from composition.

That is what makes the problem operationally difficult.

Security teams are used to looking for obviously sensitive strings leaving the boundary: customer names, account numbers, unreleased codenames, direct copies of confidential text. MosaicLeaks points to a different class of failure. The agent might never paste the secret directly. Instead, it leaves behind a breadcrumb trail of seemingly normal searches that let an outside observer reconstruct the secret afterward.

This is especially relevant for deep research systems because they work in chains. One query identifies an entity. Another resolves a date. A third narrows a vendor, geography, or business event. In aggregate, the query log starts to look less like search behavior and more like a compressed map of private context.

That is why “the model did not quote the document” is not a sufficient safety argument.

MosaicLeaks measures three kinds of leakage

The benchmark does something useful for practitioners: it breaks privacy leakage into three levels.

Intent leakage asks whether an observer can infer what the agent was trying to investigate just from the web-query log. This is already serious in a corporate setting. Even if the underlying answer stays hidden, the fact that an agent is researching a specific supplier issue, acquisition target, security disclosure, or region can itself be sensitive.

Answer leakage is stronger. Here, the adversary gets the query log and a question about the private information, then tries to answer it without seeing the enterprise documents. If the observer can do that, the web trail has become an indirect answer key.

Full-information leakage is stronger still. In this case, the adversary gets only the query log and tries to produce verifiably true claims about the private documents without being told exactly what question to ask. That is close to the nightmare scenario for enterprise deployment: a passive observer learning new confidential facts from normal-looking traffic.

This taxonomy is useful because it maps to real organizational concerns. Product teams may care first about user-visible correctness. Security teams will care whether a third party can infer intent, answer a known private question, or discover confidential facts outright. MosaicLeaks shows these are not the same thing and should not be evaluated as if they were.

Better task performance can make privacy worse

One of the most important findings in the paper is also one of the least surprising once you think about how agents are optimized.

If you train an agent only to solve the research task better, it may learn to search more aggressively, make more external calls, and expose more context to get to the right answer. In other words, the shortest path to better performance may run straight through higher leakage.

The authors report exactly that.

On Qwen3-4B-Instruct, training for task performance increased strict chain success from 48.7% to 59.3%, but it also pushed privacy leakage from 34.0% to 51.7%. The model got better at completing the task and worse at keeping secrets. That is not a side note. It is the central warning.

For teams deploying research agents in production, this should change how success is defined. If your reward function, evaluation loop, or product KPI mainly values answer completion, retrieval persistence, or task throughput, you may be training the system into a stronger exfiltration habit without calling it that.

MosaicLeaks also finds that zero-shot privacy prompting helps only a little. The paper says prompting reduced leakage but did not eliminate it. On Qwen3-4B-Instruct, answer leakage or full-information leakage still occurred in 25.5% of samples even with a privacy-aware prompt. That is not a meaningful safety margin for enterprise use.

The lesson is uncomfortable but clear: “be careful with private data” is not enough when the model is still rewarded for finishing the chain at all costs.

What PA-DR changes

The paper’s proposed response is PA-DR, short for Privacy-Aware Deep Research.

The main idea is not to bolt privacy on as a final filter. Instead, PA-DR changes the training objective so the agent is rewarded for task success and privacy preservation together. The framework combines situational rewards for task success with a learned privacy classifier, then uses dense credit assignment over both per-query leakage and mosaic-level leakage.

That design matters because privacy failure in research agents is often local and cumulative at the same time.

A single query may be questionable on its own. A sequence of queries may become risky only in combination. If you only score the final outcome, the model gets weak feedback about which step caused the problem. PA-DR tries to make privacy legible during the chain, not only after the chain is over.

The results are notable.

Training Qwen3-4B-Instruct with PA-DR improved strict chain success from 48.7% to 58.7%, while reducing answer and full-information leakage from 34.0% to 9.9%. That is not perfect privacy, but it is a much healthier tradeoff than simply optimizing for accuracy and hoping prompts will compensate.

In practical terms, PA-DR suggests a broader design principle for enterprise agents: privacy needs to be part of the optimization target, not an external policy document taped onto the product after training.

Why this matters beyond the benchmark

It would be easy to treat MosaicLeaks as a paper about one benchmark and one training method. That would miss the larger point.

More companies are moving toward systems that let agents read internal documents and use web retrieval, external APIs, or SaaS tools in the same workflow. That architecture is powerful because it lets agents answer questions that neither a static RAG stack nor a pure web agent could solve alone.

It is also exactly the architecture that creates querying-in-the-open risk.

For developers, the takeaway is that agent safety is not only about prompt injection, tool permissions, or output moderation. Query generation itself is part of the attack surface.

For security teams, MosaicLeaks is a reminder to monitor outbound behavioral patterns, not just direct data loss signatures.

For product leaders, it is a warning against performance dashboards that celebrate research completion rates without tracking what information the system externalizes while getting there.

And for companies deploying internal research agents, the paper suggests a simple rule: if the system mixes confidential context with external retrieval, assume the query log is a potential disclosure surface until proven otherwise.

That is the real value of MosaicLeaks. It makes a subtle risk measurable.

Once you see it clearly, it becomes harder to keep pretending that ordinary-looking web searches are operationally neutral.

Sources