Agents collect more than they reveal: auditing privacy at the acquisition stage
A June 2026 benchmark inspects the moment sensitive data enters an agent's context, not just what it later discloses — and finds over-collection is widespread.
What is this?
Most privacy evaluations for LLM agents ask a single question: did sensitive data leave the system? They inspect the agent’s final answer or its outbound actions and check whether a phone number, a medical detail, or a colleague’s salary made it into the output. A benchmark published on arXiv in June 2026, PrivacyPeek: Auditing What LLM-Based Agents Acquire, Not Just What They Say (arXiv:2606.00152), argues this misses the earlier and more consequential failure. Before an agent can leak anything, it first has to acquire it — pull it into context via a tool call, a retrieval step, or a database query. The paper reframes the privacy question around that collection moment: not “should this data have left?” but “should the agent have gathered it at all?”
The framing matters because acquisition is where the principle of data minimization actually lives. An agent that quietly reads your entire calendar to answer a question about tomorrow’s meeting has already violated least-privilege, even if it never repeats a single unrelated event back to you.
How it works
PrivacyPeek separates two things that most benchmarks conflate. The first is Probe Elicitation — the familiar test of whether you can coax the agent into saying something sensitive. The second, and the paper’s contribution, is Acquisition Inspection: reading the agent’s tool-call trajectory to detect when it reached for data outside the scope of the task it was given.
Concretely, the benchmark provides a task, an environment with tools, and a definition of what data the task legitimately requires. As the agent runs, its sequence of tool calls is recorded and examined against that scope. If the task is “find a restaurant near the office for Thursday” and the agent’s trajectory includes a call that fetches the user’s saved payment methods or unrelated contacts, that is flagged as over-acquisition — regardless of whether any of it surfaces in the reply. The authors built the case set through a human-in-the-loop pipeline, yielding 1,182 cases spanning 7 acquisition behaviors and 16 application domains, and ran it against 10 agents across 4 model families.
The headline result is that unnecessary acquisition of sensitive information is widespread across the tested agents — a pattern invisible to any evaluation that only reads the final output. This lines up with a broader survey the same month, Agents That Know Too Much: A Data-Centric Survey of Privacy in LLM Agents (arXiv:2606.26627), and extends the contextual-integrity lens of earlier work like Beyond Jailbreaking: Auditing Contextual Privacy in LLM Agents (arXiv:2506.10171) from what agents disclose toward what they touch.
Why it matters
The gap is architectural, not cosmetic. Output-only privacy testing can certify an agent as “safe” while it routinely hoovers up data it has no business reading. That exposure is real even when nothing leaks: acquired data sits in the context window where a downstream prompt injection can exfiltrate it, lands in logs and traces retained by the platform, and widens the blast radius of any later compromise. An agent wired to broad tools — email, files, calendars, CRM — with a habit of over-collecting is a standing liability, because the sensitive material is already inside the boundary before any attacker shows up.
It also breaks a common compliance assumption. Data-minimization obligations under regimes like the GDPR are about collection and processing, not only disclosure. An agent that reads far more than a task requires is a minimization problem on its own terms, and a purely output-focused audit will never surface it.
Defenses
Treat acquisition as a first-class control point rather than trusting that a clean-looking answer means clean behavior.
Audit the trajectory, not just the output. Log every tool call and retrieval, and evaluate them against the data the task actually needs — this is exactly what Acquisition Inspection formalizes. A test suite that only reads final responses will pass agents that over-collect.
Scope tools to the task. Prefer narrow, purpose-bound tools (“get Thursday’s calendar events”) over broad ones (“read all calendar data”), so the agent physically cannot acquire beyond scope. Bind tool availability to the current task rather than granting the full toolset by default.
Enforce minimization at the boundary. Put a policy layer between the agent and its data sources that can deny or narrow a request whose scope exceeds the task, instead of relying on the model to restrain itself.
Minimize retention of what is acquired. Drop sensitive fields from context, logs, and traces once they are no longer needed, so over-collection does not quietly become long-lived exposure.
Test with acquisition-aware benchmarks. Adopt evaluations that separate what an agent says from what it gathers; the two failure modes need different fixes and only one of them shows up in the transcript.
Status
| Aspect | Detail |
|---|---|
| Source | PrivacyPeek (arXiv:2606.00152), published June 2026 |
| Class | Acquisition-stage privacy leakage — over-collection of sensitive data into agent context |
| Method | Dual evaluation: Acquisition Inspection (tool-call trajectory audit) + Probe Elicitation |
| Scope | 1,182 cases, 7 acquisition behaviors, 16 application domains |
| Tested | 10 LLM-based agents across 4 model families |
| Finding | Unnecessary acquisition of sensitive information is widespread |
| Nature | Research benchmark / measurement — no CVE, not an active exploit |