MCP and GDPR: EU Data Residency for Agent Integrations

Start With the Processing Path

The first review should be a data-flow review, not a tool catalog review. MCP clients discover tools with JSON-RPC tools/list and invoke them with tools/call. Over Streamable HTTP, each client message is an HTTP POST to one MCP endpoint, with replies returned as JSON or request-scoped server-sent events. That gives you a clean technical boundary to inspect, but it does not tell you whether the payload contains personal data or whether the next hop stays in the EU.

For each source, write down five fields: tool arguments, upstream query, upstream result, agent-visible response and operational log. A harmless-looking issue-tracker search can include employee names, customer email addresses, ticket text, IP addresses, account IDs or support notes. The European Commission describes personal data broadly as information relating to an identified or identifiable living individual, and processing includes retrieval, consultation, use and disclosure by transmission.

A useful map is blunt:

agent client -> MCP endpoint -> connector or upstream MCP server -> SaaS/database/file API
             -> tool result -> model context -> audit log

Put the locations and vendors on every arrow. Then decide what each arrow may carry before rollout. The logging side of that map pairs naturally with audit logging for AI agent tool calls.

Separate Residency From Transfer

Residency answers where a service stores or runs data. GDPR transfer analysis asks whether personal data is disclosed or made available to a recipient in a third country or international organization. Those are related questions, but they are not the same question. An EU-hosted MCP endpoint can still send tool results to an agent or model provider outside the EEA. A locally running client can still call a US-hosted upstream SaaS.

Article 44 of the GDPR sets conditions for transfers of personal data to third countries or international organizations, including onward transfers. So the engineering checklist needs more than a region label. It needs the route: who receives the request, who receives the result, where logs are stored, where subprocessors operate, and whether any connector hands data to a non-EEA API.

This is also where hosted versus self-hosted architecture becomes a compliance decision. If that tradeoff is still open, compare it with hosted vs self-hosted MCP aggregation.

Assign Roles Before You Add Tools

Do not wait for legal review to discover that the architecture diagram has no roles. The European Commission explains the controller as the party deciding why and how personal data is processed, while a processor acts only on behalf of the controller. In an agent integration, your company is often the controller for employee, customer or user data in its systems. The MCP layer, model provider, hosted connector provider and upstream SaaS may each be processors, independent controllers or both for different operations.

That classification changes what evidence you need. If a vendor is a processor, Article 28 expects a contract or other binding legal act, documented instructions, appropriate security measures and controls around sub-processors. If a service uses tool-call data for its own product analytics, abuse monitoring, training or enrichment beyond your instructions, the role may no longer be a simple processor story. The engineering team cannot settle the legal label alone, but it can provide the facts that make the label reviewable.

Capture a small record for each integration:

{
  "source": "linear",
  "personal_data_expected": true,
  "purpose": "engineering issue triage",
  "mcp_boundary": "workspace endpoint",
  "upstream_vendor_role_to_review": "processor or independent controller",
  "subprocessor_evidence": "DPA, region, logs, backups"
}

The point is not bureaucracy. It is avoiding a tool surface where nobody can explain why an agent was allowed to retrieve a customer record, where the record went, or which contract covered the processing.

Minimize the Tool Surface

MCP gives you protocol mechanics, not GDPR compliance by default. A server that exposes every possible tool through tools/list has created a large processing surface. A server that exposes narrow, named tools with explicit input schemas has something a reviewer can reason about. The tool specification also warns that tool annotations should be treated as untrusted unless they come from trusted servers, so do not rely on a remote readOnlyHint alone as your compliance control.

Prefer tool definitions that force the smallest useful request. A broad tool invites personal data sprawl:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "crm.search_everything",
    "arguments": { "query": "acme" }
  }
}

A narrower version makes the purpose and boundary visible:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "crm.find_accounts_by_domain",
    "arguments": { "domain": "acme.example" }
  }
}

Then enforce the rule server-side. The MCP endpoint should check the workspace, key, source, tool, arguments and write permission before forwarding the request. Prompts can remind an agent to avoid personal data, but prompts are not access control. The same least-privilege thinking applies to keys and sources; the companion guide on scoped API keys for AI agents covers that boundary in more detail.

Keep Client Config Reviewable

Client configuration is compliance evidence because it shows what endpoint the agent can reach. Keep it short enough that a security reviewer can read it without reconstructing your whole integration estate. In Claude Code, a remote HTTP server can be added with a command like this:

claude mcp add --transport http workspace https://mcp.example.com/agent/mcp \
  --header "Authorization: Bearer $AGENT_MCP_KEY"

In VS Code, workspace MCP configuration can live in .vscode/mcp.json with a top-level servers object, or in a portable workspace .mcp.json with mcpServers. A minimal remote entry should still avoid hardcoded secrets:

{
  "servers": {
    "workspace": {
      "type": "http",
      "url": "https://mcp.example.com/agent/mcp"
    }
  }
}

The compliance smell is not that developers use different clients. It is that every client gets a different long-lived upstream token, a different set of sources and a different logging path. Point clients at one controlled endpoint, keep credentials out of committed files, and make the endpoint enforce source and tool policy at runtime.

Where SPYN3 fits

SPYN3's own processing stays in the EU: the API in Amsterdam, the database in eu-west-1 (Ireland), backups in Frankfurt. It proxies calls to your systems and does not store or index their documents, and upstream credentials are encrypted at rest. The one exception is opt-in: AI tool search, off by default, sends the task text and tool descriptions to OpenAI in the US. That narrows what SPYN3 adds to your data map. It does not settle where your upstream systems or your AI provider process data. Those stay your assessment, and this is not legal advice.

Review Checklist

1. Draw the full route from agent client to MCP endpoint, upstream source, model context, logs and backups.
2. Classify the personal data each tool can retrieve, including identifiers in arguments and logs.
3. Record controller, processor and sub-processor assumptions for every vendor in the route.
4. Check whether any request, result, log or backup creates a transfer outside the EEA.
5. Expose narrow tools with explicit schemas instead of broad search tools.
6. Use scoped credentials and keep upstream tokens behind the MCP boundary.
7. Test denial paths for forbidden sources, forbidden writes and expired credentials.
8. Keep records of tool calls sufficient to investigate who called what, when and with which outcome.