Agent privacy is a data-flow problem, not a policy document

Agent privacy is decided at three boundaries — what enters the context window, what leaves in a tool call, and what persists to memory — and at none of them does the privacy policy execute. The policy names intentions. The flows leak facts. If your privacy program for an agent system is a document rather than a set of enforcement points in the data path, you have a statement of aspiration, not a control.

Agents are structurally different from stateless model calls, and the threat-model research is precise about why: state accumulates without bound across sessions, the control plane is natural language and therefore manipulable by the data flowing through it, and authorization rides implicitly in prose rather than explicitly in scopes. What that produces is a data trail no policy anticipated. The sensitive surface isn't just PII fields — it's derived inferences, where a query sequence reveals a medical condition without a single explicit fact; scratch directories where intermediate task files persist in unmanaged storage after the task dies; episodic memory that bleeds across sessions when it isn't scoped to one; cached tool outputs nobody inventories. And the user can't see any of it — the visibility gap between what someone told an agent and what the agent retained is itself a privacy failure.

Each boundary has its own enforcement pattern, and every one is a data-engineering artifact. At the tool-call boundary the structural problem is provider inference: every MCP call teaches the tool provider your query parameters, timing, and implicit state. The countermeasures are projections and tags — context stripping that projects each invocation down to the minimum necessary fields, schema annotations that declare per-tool what may cross, purpose-limitation checks that run at invocation time rather than audit time. At the memory-write boundary the pattern is lifecycle enforcement: TTLs by data category — hours for raw PII, weeks for preferences — enforced by infrastructure rather than requested by prompt; ephemeral working memory purged when the task completes; a PII-detection pipeline of the Presidio variety sitting on the write path; retrieval namespaces partitioned per user. Projection layers, schema annotations, TTLs, partitions: this is the same toolbox data platforms have used for governance for a decade. Privacy engineering for agents is data engineering with an adversarial imagination.

The concession is that minimization costs utility, and pretending otherwise discredits the whole program. Strip context too aggressively and tool calls degrade or fail outright; a PII-abstraction stage adds latency and a second model whose judgment you now have to trust; TTLs that delete too eagerly destroy exactly the personalization the user wanted the agent to have. This is a tuning problem with a real trade-off curve, and the right operating point differs by domain — a consumer assistant and a lending workflow under RBI digital-lending rules should not share defaults. What's not defensible is refusing to place the controls at all because the tuning is hard.

The reason to build it this way goes beyond hygiene. Regulators increasingly ask data-flow questions — what crossed this boundary, under what purpose, retained for how long — and a system whose privacy properties live in its pipelines can answer from its architecture, the same way the EU AI Act rewards systems that treated governance as a design input. It's the identical lesson agent memory taught: govern the lifecycle before you optimize the retrieval. And it compounds with security — the flows you minimize for privacy are the same flows injection attacks traverse for exfiltration, so every field you don't pass is attack surface you don't defend. The policy document still matters; it's the specification. But a specification without enforcement points is documentation for a system that doesn't exist.