Data minimisation for agents that always want more context

Agent builders often treat context as fuel: if an answer is weak, add more documents, longer conversation history, richer user profiles and additional tool output. That can improve some tasks. It can also expose people to unnecessary processing, expand the attack surface, confuse retrieval and make deletion or access requests harder to honour.

The better design target is not maximum context. It is the minimum authorised, relevant and timely context needed for this task. That standard has to operate across the whole agent pipeline because data can expand at collection, retrieval, memory, tools and logs even when the visible prompt looks restrained.

Define the task before judging necessity

Minimisation is impossible without a specific purpose. “Improve the assistant” does not tell a team whether employment history, location or previous conversations are necessary. “Schedule a follow-up with the customer named in the open support case” creates a testable data need.

For each action, identify:

• the outcome the agent may pursue;
• the minimum facts required to decide and act;
• the data categories that are explicitly unnecessary;
• freshness requirements;
• who is authorised to use the data for that purpose;
• when the data should leave working context and storage.

The UK’s ICO guidance on AI and data minimisation notes that what is adequate, relevant and limited depends on the circumstances and discusses techniques that can support both minimisation and effective AI. Regulatory applicability requires analysis of the processing and jurisdiction; the engineering principle is broadly useful even for confidential non-personal data.

Minimise at six separate layers

A context window is only one layer of processing:

Layer	Common expansion	Minimisation control
Collection	Ingest an entire repository because it may be useful	Source allowlist and field-level purpose rules
Retrieval	Search all indexed content for every user	Permission, tenant, time and task filters before ranking
Assembly	Add top results and full conversation history	Selective fields, bounded chunks and relevance threshold
Memory	Save every interaction indefinitely	Explicit write policy, scoped memory and retention schedule
Tools	Send complete records to an external service	Parameter allowlist, transformation and local pre-processing
Observability	Log prompts, context and outputs by default	Structured events, redaction, sampling and protected debug mode

A privacy review should follow one piece of data across all six. A field excluded from the model prompt may still appear in a retrieval cache, trace export or evaluation dataset. A deleted memory item may survive in backups or supplier logs.

Filter before sensitive data reaches the model

Do not rely on the model to ignore unnecessary data. Once a record is in context, it can influence output, appear in traces or be exposed through manipulation. Enforce purpose and authorisation before retrieval results are passed to generation.

Useful patterns include separate indexes for strong isolation boundaries, metadata filters tied to authoritative identity attributes, row- or document-level policy checks, field projection, time windows and pre-computed task views. Recheck permissions when source access changes; stale access metadata can make a previously valid index unsafe.

Semantic similarity is not necessity. A vector search can find a record that is closely related to the query but outside the user’s authority or the workflow purpose. Rank only within the authorised candidate set and test both over-disclosure and loss of legitimate results.

Shape context around the decision

After authorisation, reduce context to what the next decision needs. For a meeting-scheduling action, the agent may need availability ranges and contact preferences, not the text of past private meetings. For a support response, it may need the current product, issue and approved account status, not every historical note.

Techniques include:

• structured tool responses instead of full records;
• extractive selection with links to source evidence;
• pseudonymous identifiers until identity is needed;
• coarse values where precision does not change the decision;
• local computation that returns a result instead of raw inputs;
• progressive disclosure when an authorised user explicitly requests detail.

Summarization can reduce volume but does not prove minimisation. Verify that the summary excludes unnecessary attributes, preserves decision-critical qualifications and inherits the source’s access and retention controls.

France’s data-protection authority, CNIL, recommends selecting data relevant to the defined objective, removing irrelevant data, applying privacy-by-design transformations and regularly reassessing whether minimisation measures remain adequate in its AI development recommendations. CNIL also notes that large volume is not automatically incompatible with minimisation; the focus is whether personal data is useful and appropriately selected and protected.

Give memory a write policy, not just a store

Agent memory should answer three questions before persisting information:

1. Is this fact needed for a defined future purpose?
2. Is the current actor permitted to create memory for that subject and scope?
3. What event or time will delete, refresh or invalidate it?

Separate working state, user preferences, business records and learned operational summaries. They have different owners and retention needs. Avoid copying authoritative records into conversational memory where a pointer or fresh lookup will do.

Let users and operators inspect and correct durable memory when appropriate. Record provenance so a preference inferred from one conversation is not mistaken for an authoritative fact. Apply stricter rules to sensitive attributes and avoid inferring them merely because personalization might improve.

Minimise tool calls and downstream disclosure

An agent can leak data through a legitimate tool call even when its own storage is well designed. Define schemas that allow only necessary fields and values. Validate outbound parameters at a trusted boundary. Use purpose-specific service identities and prevent free-form prompts from becoming arbitrary payloads to third parties.

For each tool, map:

• fields sent and returned;
• provider role and contractual constraints;
• processing and storage locations;
• retention, logging and model-improvement settings;
• onward subprocessors;
• deletion and incident routes.

The NIST Privacy Framework treats privacy risk as an enterprise risk that can arise from data processing and provides Identify, Govern, Control, Communicate and Protect functions. Its data-processing-ecosystem view is especially relevant to agents that pass context through several providers.

Design logs for learning without copying the world

Teams need observability, evaluation and incident evidence. That does not justify recording every prompt and full context indefinitely. Start with structured events: system version, action class, policy decision, source identifiers, outcome, latency and error code. Add content only where a defined investigation or quality purpose requires it.

Use tiered logging. Routine operation may keep metadata and redacted samples; a time-limited debug mode can capture more under stricter access and approval. Tokenise or hash identifiers when linkage is needed without direct identity, while recognising that pseudonymised data can remain personal data.

Apply retention to derived evaluation sets too. A “golden” test case copied from production can outlive the source record unless its provenance and deletion obligations travel with it.

CNIL’s guidance on data collection and management for AI also calls attention to metadata, retention and maintenance copies: fields that appear secondary can still support re-identification or persist beyond day-to-day development need.

Test usefulness and privacy together

Minimisation can fail in both directions. Too much data increases exposure; too little can produce wrong actions, inequitable service or repeated requests for information. Evaluate the trade-off with representative tasks.

Build ablation tests that remove fields or sources and measure whether decision quality changes. Test permission tiers, sensitive fields, stale data, cross-tenant queries, prompt injection and deletion. Inspect retrieved context, not only the final answer, because the system can process restricted data without reproducing it visibly.

Document residual risks. The EDPB’s Opinion 28/2024 addresses when AI models may be considered anonymous, legitimate interests and consequences of unlawfully processed personal data. It emphasises case-by-case assessment; teams should not assume a model or embedding is anonymous merely because raw records are difficult to read.

Make minimisation a release property

Add data-scope checks to change review. A new tool, retrieval source, memory feature or telemetry provider should update the data map and rerun relevant tests. Monitor context size and category, unauthorised retrieval denials, memory growth, retention failures and debug-mode use.

The release decision should state which data the agent may collect, retrieve, persist and disclose for each action class. It should also say what remains uncertain and who will revisit the decision when purpose or technology changes.

Agents do not need every available fact. They need a disciplined data path that can justify each fact’s presence at the moment it is used. That constraint can improve privacy, security and task clarity at the same time.