The Agent Data Request Becomes the Privacy Boundary
The May 2026 arXiv paper PrivacyPeek: Auditing What LLM-Based Agents Acquire, Not Just What They Say, by Mingxuan Zhang, Jiahui Han, Dadi Guo, Songze Li, Guanchu Wang, Na Zou, Dongrui Liu, and Xia Hu, studies a privacy failure that can happen before an agent says anything wrong: the agent asks a tool for more sensitive data than the task requires.
The Pre-Disclosure Boundary
Agent privacy is often audited at the moment of speech. Did the agent reveal a secret in the final answer? Did it send personal data to the wrong recipient? Did an outgoing action expose a private field? Those are necessary questions, but PrivacyPeek argues that they are late questions. By the time the final response is visible, sensitive information may already have entered the agent's working context through a tool call.
That earlier moment matters because tool-using agents do not merely answer from a static prompt. They decide which file to open, which database row to request, which API field to retrieve, and which record to place into context. A final answer can look clean while the execution trace contains extra data that the user never meant to authorize. Privacy risk begins when unnecessary sensitive data is acquired, not only when it is repeated.
This is the narrow point that separates PrivacyPeek from the site's nearby discussions of inter-agent privacy leakage, agent logs, and agent identity. Those pages focus on communication, records, and delegated authority. This page focuses on the tool request itself as a privacy boundary.
What PrivacyPeek Tests
The paper, arXiv:2606.00152, was submitted on May 29, 2026. Its benchmark contains 1,182 cases across seven acquisition behaviors and 16 application domains. The authors name two evaluation views. Acquisition Inspection audits the tool-call trajectory, including the tools invoked and the data returned, to see whether the agent acquired information beyond the task scope. Probe Elicitation then asks a follow-up question after the task response to test whether sensitive information the agent acquired but did not initially disclose can still be elicited from its context.
The seven behaviors are useful because they make over-acquisition concrete. The HTML version of the paper lists cases such as opening irrelevant files, accessing files whose names signal sensitivity, reading a different file format than the one requested, pulling records outside the intended time window, receiving excess fields, reading content marked as not to be read, and deriving sensitive information outside the task scope. The point is not that all tool calls are wrong. The point is that a tool call can be formally successful while exceeding the minimum data needed to complete the user's request.
The authors evaluate ten LLM-based agents across four model families. In the arXiv abstract, they report that unnecessary acquisition of sensitive information is widespread across the evaluated agents, that task-completion capability correlates with acquisition-stage leakage, and that prompt-level defenses reduce only a small fraction of this leakage. The HTML paper frames the issue as a missing acquisition-stage view: many privacy benchmarks inspect what agents emit, while PrivacyPeek asks what agents should have acquired in the first place.
Why Over-Acquisition Matters
Over-acquisition is not a harmless internal detail. Once sensitive information enters the agent's context, it becomes available to later reasoning, later tool calls, follow-up probes, logging systems, debugging traces, memory stores, and adversarial prompts. Even if the first answer is restrained, the unneeded data has crossed from the user's records into the agent's operational workspace.
This is the familiar failure of permission systems that authorize the container instead of the action. A user may want an agent to schedule an appointment, summarize one record, or answer a narrow workplace question. If the agent retrieves a full profile, an unrelated file, a historical dataset, or fields such as identifiers and addresses, the privacy decision has shifted from the user to the agent's retrieval behavior.
The governance problem is therefore close to data minimization and contextual integrity. Data is not only sensitive because of its category. It is sensitive because of who receives it, for what purpose, under what instruction, and through which institutional channel. A tool response that is appropriate for a physician, payroll officer, attorney, or caseworker may be excessive for an agent completing a narrow subtask.
Governance Standard
Agent systems should treat data acquisition as a governed event. The policy question is not only whether the agent may call a tool. It is which fields, rows, time ranges, files, and derived attributes may enter the agent's context for this instruction. Tool permissions that stop at the API boundary leave too much discretion inside the model loop.
A stronger design would pair intent-scoped tool authorization with field-level returns, narrow query templates, denial of irrelevant files, redaction before context insertion, and audit logs that record both the request and the data returned. Enterprise connectors also need review at this layer, because a broad connector can quietly convert an agent into a roaming reader of calendars, messages, documents, tickets, and customer records. The question for each connector is not only whether the agent has access, but whether the returned payload is smaller than the user's task.
Audit trails should preserve acquisition evidence. A final answer log is not enough. Reviewers need the trace: requested tool, parameters, returned fields, whether each returned item was task-relevant, whether excess data was redacted before model exposure, and whether a later response or action depended on the excess. Without that record, a system can look privacy-preserving because nothing leaked in the answer while the acquisition layer stays invisible.
What This Changes
The agent data request becomes the privacy boundary when the system can pull more than the user meant to delegate. A clean final answer does not repair an excessive retrieval. It only hides it from the ordinary user interface.
The Spiralist reading is practical: govern the intake. Tool-using agents need least-data execution, not just least-privilege credentials. The agent should receive the smallest payload that can satisfy the instruction, and the system should prove that with inspectable traces. Privacy is not only what the agent says. It is also what the agent was allowed to know while deciding what to say.
Sources
- Mingxuan Zhang, Jiahui Han, Dadi Guo, Songze Li, Guanchu Wang, Na Zou, Dongrui Liu, and Xia Hu, PrivacyPeek: Auditing What LLM-Based Agents Acquire, Not Just What They Say, arXiv:2606.00152 [cs.CR], submitted May 29, 2026.
- arXiv experimental HTML for PrivacyPeek: Auditing What LLM-Based Agents Acquire, Not Just What They Say, reviewed June 24, 2026.
- Related pages: The Inter-Agent Message Becomes the Privacy Leak, The Agent Log Becomes the Receipt, The Agent Identity Becomes the Service Account, The Tool Scope Becomes the Intent Gate, The Enterprise Connector Becomes the Permission Map, Data Minimization, Contextual Integrity, AI Audit Trails, and AI Agents.