Your AI agent's tool list is the recipient list your privacy policy has to name

A customer emails support asking why they were charged twice. The agent reads their account from your own database, looks up the invoice in Stripe, and drafts the reply through your email provider. Three companies outside your systems have now handled that customer's name and email address, and your privacy policy names one of them, the model vendor, because that was the only one anybody added when the language model went into support. A month later an enterprise prospect's security review asks for your sub-processor list, checks it against what the product does, and the gap is yours to explain in the middle of the deal. Article 13(1)(e) of the GDPR required those recipients, or their categories, in the notice you gave the customer when you took their data 1.

What does giving a model tools change?

It moves the choice of vendor from your code into the model's reasoning. With a single language-model call you pick the vendor when you write the call. With tools you pick a list, and the model picks from that list while a request is running. The Model Context Protocol, the interface most agent frameworks now expose tools through, states it as a design principle: tools are model-controlled, so the model can discover and invoke them automatically from its reading of the user's prompt. The same page says there should always be a human able to deny a tool invocation, which is advice rather than a default. Unless you built that gate, nothing approves the individual call.

The Spanish data protection authority, the AEPD, published 76 pages on what that means for the GDPR in February 2026. It binds nobody outside Spain, and I lean on it here anyway: it is the first regulator to write this down at length, and the GDPR articles it reads apply to you wherever in the EU you are. Its transparency section says an agent will bring in recipients beyond the ones the processing already accounted for, that this will happen "in many cases", and that you have to disclose who they are 2.

The baseline case, one model call and one vendor, I have written up separately in what one LLM call adds to your privacy policy. All of it still holds. What follows is what changes once the model has a tool list.

Which of the agent's calls add a recipient?

Article 4(9) defines a recipient as a person or body to which personal data are disclosed, "whether a third party or not" 1. So the test is whether personal data leaves your systems and arrives in someone else's; how central the tool is, and whether you have a contract with whoever runs it, are later questions.

Whatever a tool returns goes into the model's context and travels to your model vendor on the next turn. The model vendor is therefore a recipient of every row below, and the table is about the companies you would be adding on top of it.

The two "no" rows are the easiest place to get this wrong. Adding no company is not the same as changing nothing: a retrieval tool pointed at a new table sends a new category of personal data to the vendor you disclosed for something narrower, and your notice has to describe what is going there now. The AEPD makes the same point about internal data: once any component of the agent runs on someone else's infrastructure, reaching into your own systems can become a disclosure to a third party that the processing never accounted for 2.

Work from the tool definitions themselves, because an architecture diagram will not show you this. A search tool looks harmless until you notice the agent puts the customer's email address in the query to find their account.

How do you name recipients the model picks?

By deciding them in advance and publishing the decision. The set of tools an agent may call is yours to pin; only the choice within that set belongs to the model. Article 13(1)(e) asks for recipients or categories of recipients 1, and a pinned tool list gives you either: the names, or a category you can defend because you know everything inside it. My view is that on an agent you should publish the names, because a category like "third-party service providers" only works when you could have written the list out, and the reason people reach for it is that they could not.

One tool type breaks the tidy version of this. A web search, a browse tool, or a general HTTP fetch is one line on your list whose recipient is chosen at run time by whatever the model decides to look up, so pinning the list does not pin the recipients. You get most of it back in two moves: name the tool provider, which is a recipient like any other, then either restrict the destinations the tool may reach or keep identifiers out of what you pass it. An email address in a search query is what turns that call into a disclosure; the same search without one is not.

The pin itself can also slip, in two ways. A remote tool server can tell your client its list of tools has changed, and a client that re-reads the list and carries on has let another company extend what your agent can do with no deploy on your side. And an agent given more autonomy than the task needs will reach for more of the list than it needs. How much autonomy it has is your design decision rather than a property of the model, which the AEPD says in as many words 2. Choosing a level where a person approves outbound calls is available to you, and it is a great deal cheaper than discovering the recipient list afterwards.

What does the agent's memory do to your retention line?

An agent that remembers is building a profile. The AEPD describes semantic memory as retaining facts from past interactions to personalise an application, creating a continuously updated profile of the user 2. That is the feature working as intended, and it is also personal data that nothing deletes until you say so. You owe your users a storage period, or at least the criteria you use to set one 1, and a fresh memory store arrives with neither.

A deletion request is where this gets expensive. It has more places to reach than a row in your main database, and they are not all equally settled. The memory stores are settled: they hold the person's data for your own purposes, and the AEPD says an agent has to be built from the outset so erasure can be carried out across them 2. The logs are arguable, because the right to erasure gives way where you need the data to defend a legal claim, and a security log has a real case for that 1. Decide it per store and write down which way you went. What you cannot do is run a DELETE against one table and call the question closed.

What should you do about the agent you have already shipped?

Open its tool definitions and list every tool that can send personal data to another company. That list is your recipient list, and anything on it that your privacy policy and sub-processor list do not carry is a disclosure you owe.

Email your existing users before the agent goes live, and say what changed. Quietly editing the policy page does not count: the transparency guidelines endorsed by the EDPB, which coordinates the EU's national privacy regulators, call it both insufficient and unfair to leave people to re-read your policy, and they treat adding categories of recipients as exactly the kind of change that has to reach them well in advance 3.

Settle each new name: a provider acting only on your instructions needs a DPA, one setting its own purposes does not, and sorting your vendors into those groups is the cheap first pass. A tool that processes outside the EEA also needs its own legal footing for the trip, on the Commission's list of countries it considers safe or on standard contractual clauses, and it cannot ride on the ones you signed for a different vendor 1.

Give the memory a retention period, decide per store where erasure stops, and add the new recipients to your record of processing activities, the internal inventory of what you process and who you send it to. Under 250 employees does not excuse you from keeping one once the processing is more than occasional 1.

This drifts because the tool list changes in a pull request while the privacy policy changes in a document, and nothing joins the two. Lawcel is a service that watches a codebase for changes that make a company's published legal documents wrong. It reads each pull request and opens a case naming the documents that change affects, commenting on the pull request as well so whoever wrote it sees the problem without leaving GitHub. A new tool in a manifest arrives as an ordinary diff, so nobody has to remember to look. If your team is shipping agents this quarter, connect your repo before the tool list gets away from you.