When a team first connects an AI agent to company systems, the technical question is "can it reach the data?" The more useful question for a manager is different: what is the agent allowed to see, where can that information end up, and how long does it stay there? A chatbot answers one question and forgets. An agent reads records, calls tools, writes notes, and often keeps a memory. Every one of those steps can copy customer data somewhere new.
This guide is for the person who signs off on an agent that will touch customer information. It does not cover access rights in depth, tracing, or attacks through hostile text. Those have their own articles, linked below. It covers the data itself: classes, minimization, retention, and the questions to put to a provider.
Follow the data, not the agent
Start with a simple map. For one planned agent, list every place customer data can appear:
- Input: the user's request, plus any records the agent fetches.
- Model context: everything sent to the model provider in a single call.
- Tool calls: arguments the agent sends to other systems, such as a search query or an email draft.
- Outputs: answers, tickets, messages, files.
- Logs and traces: what you record so you can debug and audit.
- Memory: notes the agent saves for later runs.
- Provider side: whatever the model vendor stores on its own systems.
Most teams think about the first and the last. The middle ones are where surprises happen, because logs and memory quietly become a second, uncontrolled copy of your customer database. OWASP lists sensitive information disclosure as a top risk for LLM applications and points to the same basics: sanitize data, limit access, and be clear with users about how their data is used.
Sort data into classes before the agent sees it
You do not need a heavy scheme. Three or four classes are enough, as long as each has a rule the agent can follow:
| Class | Examples | Default rule for the agent |
|---|---|---|
| Public | Published pricing, documentation | May read, write, and send freely |
| Internal | Process notes, internal tickets | May read and use; may not send outside the company |
| Customer personal | Names, emails, order history, support conversations | Only the fields needed for the task; masked where possible; retention limit required |
| Restricted | Payment details, health data, credentials, contracts under confidentiality | Not available to the agent unless a specific, approved task requires it |
Two of these decisions deserve a named owner: which classes the agent can read at all, and which classes can leave your environment in a call to an outside model or tool. If personal data of people in the EU is involved, the GDPR applies to the agent just as it does to any other processing, including purpose limitation, data minimization, and storage limitation. Involve whoever handles privacy in your company early; this article is not legal advice.
Minimize what reaches the model
The cheapest control is not sending the data in the first place. Before building anything clever, try these in order:
- Fetch fields, not records. If the task needs the order status, give the agent the status, not the full customer profile.
- Mask identifiers. Replace names, emails, and account numbers with placeholders such as
CUSTOMER_1, and map them back only when the final message is sent. The model rarely needs the real value to do the reasoning. - Cut the history. Pass the last few relevant messages, not the whole conversation archive.
- Strip files. Attachments often carry far more than the task needs. Extract the one table or paragraph required.
Each step also lowers cost, because less text goes into every call. It also makes the agent's behavior easier to review, since the inputs are small enough for a person to read.
Retention: every copy needs an end date
Storage limitation means data is kept only as long as the purpose requires. For agents, that has to be applied to each copy from the map above, not just the main database. A workable starting point:
- Prompts and tool results: do not store them by default. If you need them for debugging, keep a short window, such as days rather than months, and store masked versions.
- Logs and traces: record what happened (which tool, which record ID, what outcome) rather than the customer's text. Our guide on observing AI agents without leaking data covers this in detail.
- Agent memory: decide what the agent may remember between runs. Preferences and process knowledge are fine; personal details about a customer belong in your CRM, with its existing rules, not in a free-form memory.
- Outputs: a message sent to a customer is a business record and follows the retention rules for that kind of record.
- Deletion requests: if a customer asks for deletion, you need to know every place the agent may have copied their data. This is the practical test of whether your map is complete.
Write the retention period next to each item and name who checks that deletion actually runs. A policy that nobody enforces is the same as no policy.
Ask your provider what happens on their side
When you use a hosted model, your data passes through someone else's systems. Providers publish their data controls, and the details differ by product, plan, and region. OpenAI's API documentation, for example, describes how data is retained for abuse monitoring and which controls, such as Zero Data Retention, require approval and meet specific conditions. Anthropic publishes its own API and data retention documentation. Read the current page for the exact product and plan you will use, and put these questions to the vendor in writing:
- Is our data used to train models? Is that off by default, and can we confirm it in the contract?
- What is stored, and for how long, including copies kept for abuse monitoring or safety?
- Can we get stricter retention, and what conditions apply?
- Where is the data processed, and which sub-processors are involved?
- How do we delete data on request, and how quickly?
Keep the answers with the project documents. When the provider changes its terms, you want to see what changed against what you approved.
Controls around the data
Policies work better with a few technical limits behind them:
- Allow-lists for outbound actions. The agent may send email only to approved domains and call only approved tools. Access scope is covered in agent identity and least privilege.
- Output checks. Scan drafts for patterns such as card numbers or ID numbers before anything leaves the company.
- Separate environments. Test with synthetic or masked data, never a copy of production.
- A stop switch. If the agent starts handling data it should not, you need a way to halt it quickly; see incident response and kill switches for AI agents.
- Text from outside is not an instruction. Emails and web pages the agent reads may try to make it reveal data; prompt injection controls cover that threat.
A one-page decision before launch
Before an agent touches customer data, you should be able to fill in one page:
- Which data classes can the agent read, and which fields?
- What is masked or removed before the model call?
- Where can data go outside the company, and who approved each destination?
- How long is each copy kept (prompts, logs, memory, outputs), and who verifies deletion?
- What did the model provider confirm in writing about storage and training?
- Who is the named owner, and who is told if something goes wrong?
If you cannot answer one of these, that is the thing to fix before launch, not after. For the wider picture, see how to build an operating model for trustworthy agents, and for pilots in smaller companies, your first AI agent pilot.
If you want help mapping the data flows for an agent you are planning, talk to us. A short review before launch usually finds the one or two copies of customer data that nobody had listed.