Data Minimization Instruction Prompt for Agents

This playbook is for AI engineers building tool-calling agents that must request only the minimum necessary data for a task. The system prompt constrains tool queries, filters retrieved fields, and requires the agent to justify its data needs before fetching. Use this when your agent has access to databases, APIs, or internal tools that could return more data than the task requires, and you need enforceable data minimization rules embedded directly in the system instructions rather than relying solely on application-layer controls.

The ideal user is an AI platform engineer or technical product manager who has observed over-fetching in production agent traces—agents pulling full customer records when only an email address is needed, or retrieving entire document bodies for a simple status check. This prompt is most effective when your agent operates in a tool-rich environment where the cost of over-fetching is measurable: increased latency, higher token consumption, unnecessary data exposure in agent memory, or compliance risk from pulling data categories the task doesn't require. You should have a clear catalog of available tools and their data shapes before implementing this prompt, as the minimization rules must reference specific tool parameters and return fields.

This prompt is not a replacement for proper access control lists, field-level encryption, or database permissions. It is a behavioral layer that reduces over-fetching, limits unnecessary data retention in agent memory, and creates an audit trail of data access justifications. Do not use this prompt when your tools already enforce strict field-level access controls at the API layer, or when the agent's task genuinely requires broad data access for reasoning. Avoid this approach if your model lacks reliable tool-calling capabilities or if the added justification step introduces unacceptable latency for real-time workflows. For high-risk domains involving regulated personal data, this prompt must be paired with application-layer enforcement and human review of access patterns—never rely on prompt-level constraints alone for compliance.

This prompt template is designed to be placed in the system instructions of a tool-calling agent. It enforces a data minimization policy by requiring the agent to declare what data it needs, why it needs it, and to request only those fields before making any tool call that retrieves data. The prompt acts as a gate, preventing the agent from over-fetching user records, pulling entire documents when only a summary is needed, or retaining data in memory beyond its immediate purpose. Adapt the placeholders to match your specific tool schemas, data categories, and risk tolerance.

markdownCopy
# SYSTEM INSTRUCTION: DATA MINIMIZATION AGENT

You are an agent with access to tools that retrieve and process data. Your primary directive is to minimize data access, retrieval, and retention. Before calling any tool that fetches data, you must complete the following justification block internally. Do not proceed with the tool call if the justification is incomplete or fails the minimization checks.

## REQUIRED PRE-CALL JUSTIFICATION (Internal)
For every data retrieval tool call, reason through:
1.  **Purpose:** What is the specific user task this data serves? Map it to one of: [ALLOWED_PURPOSES].
2.  **Minimum Fields:** What are the exact fields required to complete this task? Request only these fields. Do not use wildcard selectors or fetch entire objects.
3.  **Scope:** What is the minimum time range, record count, or entity scope needed? Use the most restrictive filter available in the tool.
4.  **Retention:** How long will this data be needed in the conversation context? It must be discarded after the task is complete or when [MAX_RETENTION_TURNS] turns have passed.

## TOOL CALL RULES
- **Field Filtering:** Always use the `fields` parameter in [TOOL_NAME] to specify exact fields. If a tool does not support field filtering, you must fetch the minimal record and then immediately discard unused fields from your working memory.
- **Just-in-Time Fetching:** Do not pre-fetch data you might need later. Fetch data only when it is immediately required for the current step.
- **No Exploratory Reads:** Do not browse or list data without a specific, justified purpose tied to the user's request.
- **Deny Over-fetching:** If a user asks for "all data," "everything you have," or similar, you must refuse and ask for specific fields or a specific task to justify the access.

## RESPONSE FORMAT AFTER TOOL USE
When you present information to the user, cite the specific fields you retrieved and the purpose they served. If you discarded any data, note that it was discarded.

## VIOLATION HANDLING
If you find yourself about to violate these rules, stop and state: "Data Minimization Check Failed: [REASON]." Then, ask the user for a more specific request or suggest a less invasive alternative.

## CONTEXT
- **Allowed Purposes:** [ALLOWED_PURPOSES]
- **Data Categories:** [DATA_CATEGORIES]
- **Max Retention Turns:** [MAX_RETENTION_TURNS]
- **Risk Level:** [RISK_LEVEL]

To adapt this template, replace the square-bracket placeholders with your specific operational context. For [ALLOWED_PURPOSES], define a strict enum like ["troubleshooting_login", "billing_inquiry", "account_recovery"]. For [DATA_CATEGORIES], list the types of data the agent might encounter, such as ["PII", "Support_Tickets", "Payment_History"]. The [RISK_LEVEL] placeholder should map to your internal data sensitivity tiers (e.g., PII_HIGH, INTERNAL_LOW) and can be used to dynamically adjust the strictness of the retention and scope rules. Ensure your actual tool definitions include the fields parameter referenced in the prompt; if they don't, you must wrap the tool call in application logic that filters the response before it reaches the model's context. Before deploying, run eval checks that specifically test for over-fetching by asking the agent for broad tasks and verifying that the resulting tool call arguments contain only the necessary fields and filters.

This prompt is not a standalone artifact; it is a policy layer that must be integrated into the agent's execution loop. The system prompt defines the data minimization contract, but the application harness is responsible for enforcing it. The harness should intercept every tool call the agent attempts, validate the requested fields and filters against the declared justification, and block or rewrite calls that exceed the minimum necessary scope. Without this enforcement layer, the prompt becomes a suggestion rather than a constraint, and over-fetching will occur in production under real user pressure.

Implement the harness as a pre-execution hook in your agent framework. Before a tool call is dispatched, extract the justification and requested_fields from the agent's reasoning or structured output. Validate that each requested field maps to an explicit need stated in the justification. For database queries, enforce SELECT column allowlisting based on validated fields. For API calls, strip unvalidated query parameters. Log every validation decision—both approvals and blocks—with the agent's justification, the requested fields, the allowed fields, and a timestamp. This audit trail is critical for compliance reviews and for debugging over-fetching patterns. Implement a retry mechanism: if a tool call is blocked, return a structured error to the agent explaining which fields were denied and why, then allow the agent to reformulate the request. Set a maximum retry limit (2–3 attempts) before escalating to a human reviewer.

Model choice matters. Use a model with strong instruction-following and structured output capabilities for the agent itself, but consider a smaller, faster classifier model for the field-validation step to reduce latency and cost. The validation model only needs to perform a binary check: does the justification support each requested field? This separation of concerns keeps the agent responsive while maintaining enforcement integrity. For high-risk domains such as healthcare or finance, route blocked requests to a human approval queue rather than allowing the agent to retry indefinitely. The harness should also enforce data retention: after the task completes, purge agent memory of any fetched data that is no longer needed, and log the purge event. This closes the loop on the minimization lifecycle and prevents data from persisting in agent context beyond its justified purpose.