Your agent reads customer emails, queries your CRM, remembers users between sessions and routes data through third-party MCP tools. GDPR applied to classical SaaS was already demanding — applied to agents, every boundary multiplies. Here is what it actually requires in 2026 and the six concrete controls that keep a DPA off your back.
Why GDPR + agents is harder than GDPR + SaaS
Classical SaaS GDPR programmes assume a static data flow: form submit → database → dashboard. Agents are non-deterministic. Every user prompt may touch a different subset of tools, which read different data sources, which persist into memory for the next session. Five properties magnify the problem:
- Tool calls happen in-loop, invisible to your backend logs unless you instrument them.
- Memory systems persist PII beyond the original session scope.
- Model vendors (Anthropic, OpenAI) are usually outside the EU.
- Fine-tuning or RAG over user data creates derived datasets.
- Users cannot easily see what the agent "knows" about them.
The six obligations, re-cast for agents
1. Lawful basis per tool call
Every tool the agent calls that touches personal data needs a lawful basis under Article 6: consent, contract, legal obligation, vital interests, public task, or legitimate interests. Tag each MCP server in your inventory with the basis you are relying on; revisit when the tool changes behaviour.
2. Data minimisation across MCP boundaries
A Postgres MCP with unrestricted SELECT access is the GDPR equivalent of handing the whole table to the agent. Narrow the scope: read-only views, row-level policies, field masking for PII columns. If the agent never needs the email field to answer a question, do not expose it.
3. Purpose limitation in memory
Memory written during a support session cannot legally be reused for marketing without fresh consent. Tag memory entries with their originating purpose; filter at retrieval by purpose match.
4. Right-to-erasure in vector memory
Article 17 does not exempt embeddings. If a user deletes their account, their vectors in your memory store must go. Design delete-by-user-id as a first-class operation from day one; re-deriving embeddings is expensive, so keep user_id on every row.
5. Cross-border transfers
Every Anthropic or OpenAI API call is an international transfer. Rely on the EU-US Data Privacy Framework (while it lasts) and the vendor’s Standard Contractual Clauses. Document the transfer in your Record of Processing Activities.
6. Automated decisions under Article 22
If the agent makes a decision with legal or similarly significant effect (credit, hiring, insurance), Article 22 kicks in. You owe the user: meaningful information about the logic, the ability to obtain human intervention, and to contest the decision. In practice: log the decision inputs and provide a human override path.
The six controls, in code
- Tool inventory file under version control, with lawful basis and scope per server.
- Data-tagging at the MCP boundary (wrap tool responses with a classification label).
- Purpose-tagged memory (
purpose: 'support' | 'sales'on every memory row). - User-scoped deletion endpoint that cascades to memory, traces, and audit logs.
- Data map that traces every PII field from source to retention.
- User-facing transparency page showing what the agent stores and a delete button.
Documentation the DPA will ask for
- Record of Processing Activities, with agents as a distinct processing activity.
- DPIA covering memory, tool calls, and cross-border transfers.
- Sub-processor register (model vendor, hosting, MCP server vendors).
- Privacy notice that specifically discloses AI agent processing.
- User-rights fulfilment runbook (access, rectification, erasure, portability).
Where this is heading
Expect two regulatory shifts over the next year: DPAs issuing agent-specific guidance (BfDI and CNIL both signalled this), and a second wave of Article 22 case law as agent-driven decisions reach courts. Build the controls now and you will not rewrite them.