Data Minimization for AI Agents: Share Less, Keep Control

Data minimization for AI agents means giving an agent only the fields a task needs, replacing or removing the rest before it reaches the model, and keeping those fields out of memory and logs as well. It reduces exposure without hurting results because most tasks depend on a handful of facts, not on the whole record. The method is simple to state: define the task, allowlist the fields, enforce the list in the tool layer, and test the output against the full-data version.

Key takeaways

• Minimize per task, not per agent. The same agent may need different fields for a refund reply and for a delivery update.
• Enforce the field list in the tools and integrations, not only in written instructions, because instructions can be ignored or overridden.
• Replace instead of only deleting. Consistent placeholders and generalized values keep the model's reasoning intact.
• Free text, attachments, memory and logs are where minimization most often leaks, so design them on purpose.
• Prove it works by running the same cases with and without the withheld fields, and review the list whenever the task changes.

What does data minimization mean when the reader is an AI agent?

Data minimization is an old privacy principle: use only the personal and sensitive information that a stated purpose requires. For a person, that usually means not collecting extra fields on a form. For an agent, the question moves to three places: what enters the model's context, what the tools return to it, and what is kept afterward in memory, transcripts and logs.

The risk is practical, not abstract. An employee who pastes an entire customer record into a chat exposes more than needed. An agent connected to a CRM, an inbox or a shared drive can do the same thing many times a day, quietly, because nobody chose what to leave out. Every extra field is one more thing a model provider processes, one more thing stored in a trace, and one more thing an injected instruction could try to extract.

This is the same logic as least privilege in access control, which the OWASP Authorization Cheat Sheet describes well: grant the minimum needed, deny by default. Minimization applies that idea to data fields instead of only to systems. For companies handling personal data of people in Brazil, the necessity principle in the LGPD points the same way, and LGPD and AI agents: what Brazilian companies should check covers the wider checklist.

Will the agent get worse if it sees less?

Usually not, provided the fields are chosen against the task. A model drafting a reply about a delayed parcel does not need a tax ID, a full address or a note about a past dispute. Extra context can even lower quality, because the model has more irrelevant material to weigh. Anthropic's guidance on context engineering describes the goal as the smallest set of high-signal information that makes the desired behavior likely. Our article on context engineering for business agents shows how to apply that to company knowledge.

There is a real exception. Sometimes a field you would like to remove is the signal. A customer's country may decide which refund wording applies. A contract's renewal date may decide whether a message is urgent. That is why minimization is a tested decision, not a blanket rule: remove, compare results, then restore only what changed the outcome.

How do you decide which fields a task needs?

Work from the task outward, one task at a time. This plan fits on a single page and can be run in a short working session with the person who owns the process.

• Step 1: Write the task in one sentence, with its output. For example: draft a status reply for a customer asking where an order is.
• Step 2: List every field the source system holds for that record, including notes and attachments, not only the ones the agent sees today.
• Step 3: Sort each field into four groups: needed to decide, needed to personalize, needed to act, and not needed.
• Step 4: For fields needed only to act, such as an email address, check whether the tool can use them without the model reading them. The agent passes a reference and the system resolves it.
• Step 5: Write an allowlist for the task. Anything not on the list is withheld by default. A blocklist fails the day a new field is added to the source system.
• Step 6: Pick a treatment for each allowed field: pass as is, mask, generalize or replace with a placeholder.
• Step 7: Enforce the allowlist in the tool or integration layer, so the model never receives the withheld fields in the first place.
• Step 8: Test on a sample of real past cases, compare outputs with the full-data version, and note any field whose removal changed the result.
• Step 9: Assign an owner and a review trigger, such as a new field, a new tool or a change in the task.

Keep the allowlist in configuration that the process owner can read, not buried in prompt text. The same discipline applies to access scopes: granting an agent only what it needs in Google Workspace or Microsoft 365 limits which systems it can reach, while the field list limits what it can read inside them. You need both.

Which redaction techniques work, and when?

Match the technique to what the model must do with the field.

• Remove: the field is not needed. This is the default and the simplest option.
• Mask: show only a fragment when a person must recognize the value, such as the last characters of an order number.
• Generalize: reduce precision. An exact birth date becomes an age band, a street address becomes a city, a timestamp becomes a date.
• Pseudonymize: replace names and identifiers with consistent placeholders such as Customer A and Supplier B. The mapping stays outside the model, so the draft can be restored before a person reviews or sends it.
• Reference: let the agent act on an identifier, for example reply to the contact on record, while the system looks up the address or phone number.
• Summarize upstream: a deterministic step extracts the few relevant facts from a long document, and the agent sees only that extract.

Consistency matters more than people expect. If the placeholder for the same person changes between messages, the agent loses the thread and may confuse two parties. Also be realistic about detection. Pattern matching catches formatted values such as card or document numbers, but it misses names and context inside free text. Prefer structured fields with an allowlist, and treat automatic detection in free text as a second layer, not the first.

Pseudonymized data is still personal data while a mapping exists. Protect the mapping with the same care as the original record, and keep it out of the agent's reach.

An illustrative scenario: a delivery status reply

Illustrative scenario: a distribution company wants an agent to draft replies to customers asking where their order is. The customer record holds a full name, phone number, delivery address, billing details, order items, carrier events, and a free-text notes field where staff have written about earlier complaints.

Applying the plan, the task needs the first name, the order status, the latest carrier event, the expected delivery window and the item category. It does not need the billing details, the full address or the notes. The sending step needs the address, but only the sending tool does, so the agent passes the order reference and the tool resolves the contact. A rule flags orders whose notes mention an open complaint, and those go to a person, who sees the full record by design.

The team runs a sample of past cases through both versions. If replies match in substance and tone, the narrower version ships. If one case differs, say a note about building access instructions turned out to matter, they add one extracted field for delivery instructions instead of exposing the whole note. The result is a smaller surface with the same usefulness.

Where does minimization quietly fail?

Most leaks come from places teams forget to design.

• Free text: notes, email bodies and ticket comments contain exactly what the structured fields were cleaned of.
• Attachments: a PDF passed to the agent carries every page, not only the paragraph the task needs.
• Broad tool outputs: a lookup tool that returns the entire customer record undoes the allowlist. Design tools to return narrow, task-shaped results.
• Memory and summaries: whatever the agent saw can be stored and resurface in an unrelated conversation.
• Logs and traces: debugging data often keeps full prompts. Record field names, references and decisions, and keep values out. What to log for AI agent observability covers that balance.
• Injected instructions: text in an email or web page can tell an agent to reveal what it holds. The OWASP guidance on prompt injection stresses limiting what the model can access and do. An agent that never received a field cannot leak it.

Treat the allowlist as a living control rather than a one-time project. The NIST AI Risk Management Framework frames this as continuing work: map where data flows, measure whether controls hold, and manage changes. In practice that means an owner, a sample of evidence and a scheduled review.

How Be Human approaches it

Be Human treats the field list as part of role design. In a first engagement we define one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion, and the allowlist for each task is written down at that point. Field limits and redaction are applied in the integrations rather than in prompt text, the agent works through its own identity with scoped permissions, and logs record references instead of raw values. Under managed operations, recurring evaluations re-run cases against the minimized inputs, permission reviews catch fields that have crept back in, and changes to the list go through the owner on the company side.

Frequently asked questions

Is data minimization the same as anonymization? No. Minimization decides what the agent receives for a task, while anonymization tries to make data impossible to link back to a person. Pseudonymized data still counts as personal data while a mapping exists, so use minimization first and treat placeholders as an extra layer.

Does minimization replace a security review of the AI provider? No. It reduces what is exposed if something goes wrong, but you still need to know where data is processed, how long it is retained and who can access it. The two controls work together, and neither makes the other unnecessary.

How can I tell whether a withheld field hurt the results? Run the same set of real past cases with and without the field, and have the workflow owner compare the outputs for substance, tone and errors. If a difference appears, restore only the narrowest version of the field that fixes it, such as an extracted fact instead of a whole note.

Who should own the field list? The person who owns the workflow should own it, with privacy or security review on the sensitive fields. They know what the task needs and can judge the trade-off. Revisit the list whenever the task, a tool or the source system changes.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.