Blog · arXiv Analysis · Last reviewed June 25, 2026

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 sharp boundary is the acquisition envelope: the files, rows, fields, time ranges, derived attributes, and tool results that may enter the agent's context for this instruction before any final answer or external action exists.

For this essay, least-data execution means the agent receives only the smallest source, subject, field set, time window, and derived attribute set needed for the current instruction. The privacy boundary is crossed when a tool returns extra data into the agent context, even if the final response never repeats it.

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.

For this essay, an agent data request is any model-initiated or model-mediated request that causes outside data to be returned into an agent run: a file read, search query, database call, enterprise connector retrieval, email lookup, calendar fetch, profile expansion, API response, embedded resource, or derived inference. The boundary is not only whether the agent has credentials. It is whether the returned payload fits the user's task, the declared purpose, and the minimum data needed at that step.

An acquisition envelope should therefore be machine-checkable, not just a policy sentence. It should bind the source, subject, fields, time window, sensitivity label, derivation rule, and destination before the tool result reaches model context. If the runtime cannot say what the agent was allowed to acquire, it cannot later prove that the agent stayed inside the task.

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 paper's threat model is intentionally conservative: the user is benign, the tools answer faithfully, and the privacy failure comes from the agent's own tool-calling behavior. That matters because the failure does not require a malicious website, compromised connector, or hostile prompt. It can occur when a capable agent is simply too eager to gather context.

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.

Over-acquisition also changes incident response. A final answer review may say "no disclosure," while the trace shows that an agent read a national identifier, private address, confidential file, unrelated email thread, or older medical record. If logs then retain the returned payload, a privacy failure at acquisition becomes a privacy failure in observability too. The same evidence needed for accountability can become a second copy of the data unless retention, redaction, and review rights are designed together.

Current Governance Context

As of June 25, 2026, acquisition-stage privacy is not governed by one agent-specific rule. The pieces sit across privacy law, AI record-keeping, identity and authorization work, tool protocols, and security guidance.

The GDPR's data-minimization principle says personal data should be adequate, relevant, and limited to what is necessary for the purposes for which it is processed, and its data-protection-by-design provision requires default processing to be limited to what is necessary for each specific purpose. That does not automatically answer every jurisdictional question for every agent deployment, but it gives the right engineering test: the agent should not pull a broader payload merely because the connector can return it.

The EU AI Act adds a traceability anchor for high-risk systems. Article 12 requires high-risk AI systems to technically allow automatic event recording over the system lifetime, with logs relevant to risk identification, post-market monitoring, and operation monitoring. That is not a complete privacy design for agents, and not every agent is a high-risk AI system. It does, however, reinforce the idea that consequential systems need reconstructable traces of what happened.

The standards and protocol layer is moving in the same direction. NIST's AI Agent Standards Initiative frames secure agent identity, authentication, interoperability, and evaluation as active standards work. NIST's February 2026 software and AI agent identity concept paper focuses on identifying, managing, and authorizing actions by software and AI agents. The Model Context Protocol's 2025-11-25 tools specification describes tools as model-controlled capabilities that let models interact with external systems such as databases, APIs, and computations. MCP security guidance separately warns against broad scopes because omnibus permissions expand blast radius and hide intent in audit trails.

Those sources do not say that PrivacyPeek is a legal standard. They show why the paper's acquisition-stage view belongs in deployment review. An agent platform that can prove only "the user had access" or "the final answer was clean" has not yet proved least-data execution.

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. Connector permission is not acquisition policy. 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.

A practical standard starts with the minimum acquisition envelope. Before a tool call, the runtime should know the allowed source, allowed subject, allowed fields, allowed time window, allowed sensitivity labels, allowed derivations, and allowed destination for returned data. If the model asks outside that envelope, the system should deny, narrow, or require explicit approval rather than returning the larger object and hoping the model ignores the excess.

Field-level and row-level narrowing should happen before context insertion. A database tool should not return a full record when one field is enough. A file tool should not open adjacent files because their names look related. A connector should not search an entire mailbox when the instruction identifies one thread. A retrieval layer should prefer handles, snippets, summaries, and redacted views until the task justifies broader access.

Tool outputs should carry provenance and sensitivity labels. The agent trace should distinguish requested data from incidental data, source-of-record data from generated summaries, user-provided files from enterprise records, and trusted system data from untrusted content. That label discipline supports prompt-injection defense, deletion, retention, and later audit.

Logs should be evidentiary, not maximal. Reviewers need enough to reconstruct the acquisition decision: tool name, version, requester, intent, arguments, returned schema, redaction result, policy decision, and downstream use. They do not always need to retain the full sensitive payload. When payload retention is necessary for regulated review or incident response, it should have access controls, expiry, and redaction paths separate from ordinary debugging telemetry.

Probe testing should become part of agent evaluation. It is not enough to test whether the final answer is correct. Red teams should ask whether unnecessary data entered context and whether a later prompt, tool call, memory write, or adversarial follow-up can recover it. That makes acquisition leakage measurable rather than speculative.

Failure Modes

Permission laundering happens when a system treats source access as task necessity. The user, agent, or service account may be allowed to read a repository, mailbox, case file, or customer system, but the current instruction may justify only one field or one document.

Field creep happens when a tool returns whole records, full files, or expanded profiles where a smaller schema would answer the request. Temporal creep happens when the agent widens a time window, pulls history, or follows older related threads without a task reason. Derived-attribute creep happens when the agent infers a sensitive attribute that was not needed for the instruction.

Trace hoarding happens when debugging, observability, or evaluation systems retain the payload after the task is over. Probe persistence happens when later prompts can still elicit sensitive data that was acquired but not originally disclosed. These are not separate from privacy governance; they are the operational path by which an excessive acquisition becomes durable exposure.

Acquisition Receipt

A governable run should leave an acquisition receipt. The receipt should identify the task, user or delegated agent identity, tool, query, source, allowed envelope, returned schema, returned item identifiers or hashes, redaction before context insertion, policy decision, downstream use, retention rule, deletion path, and reviewer when review is required.

The audit-grade question is not "could the user or agent access this item?" but "was this item necessary for this instruction at this step?" That question connects PrivacyPeek's benchmark logic to ordinary deployment work: schema design, connector scopes, runtime policy, observability, retention, and incident review all have to preserve the difference between authorized access and necessary acquisition.

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.

Source Discipline

This article treats PrivacyPeek as a May 2026 arXiv research paper and benchmark, not as a peer-reviewed field measurement of all deployed agents. Its results support the claim that acquisition-stage auditing is a serious evaluation target; they do not prove a universal leakage rate for every production agent, connector, or vendor.

Legal and standards sources are used by type. GDPR text anchors data minimization and data protection by design for EU personal-data processing. The EU AI Act anchors high-risk AI record-keeping, not a general duty for every agent trace. NIST materials show an active U.S. standards and identity agenda; they are voluntary guidance and project material, not product certification. MCP specifications describe protocol mechanics and security expectations for MCP deployments; they are not a privacy warranty for any tool server.

Source discipline also means separating three claims: what the agent was authorized to access, what it actually acquired, and what it disclosed. Privacy governance fails when those are treated as equivalent.

For adjacent agent surfaces, see When the Data Agent Becomes the Privacy Surface, 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, AI Agent Observability, Model Context Protocol, and Agent Tool Permission Protocol.

For privacy and governance background, see Privacy and Data, Data Minimization, Contextual Integrity, AI Audit Trails, AI Data Retention, AI Data Security, NIST Privacy Framework, Global Privacy Control, and AI Agents.