MCP Data Privacy for Enterprise: GDPR, Residency, Minimisation

For enterprise MCP, data privacy comes down to five habits: keep personal data out of agent scope unless a task needs it, minimise what tools return, know where data and sub-processors sit, sign the right processor agreements, and set retention deliberately. Nothing here is legal advice; check current rules with your own counsel and data protection officer.

Where personal data enters an agent system

Personal data rarely arrives by design. It slips in through four doors.

1. Tool results. A CRM tool returns contact names and emails along with the company data you wanted.
2. Connected sources. Mailboxes, chat and document stores contain personal data by nature.
3. Prompts and context. Users paste records into conversations.
4. Logs and recordings. Audit logs and session recordings capture arguments, results and visitor behaviour.

Map each door in your environment before writing a policy. The architecture overview helps identify the paths.

Minimise first, then control

The cheapest privacy control is not giving the agent the data. A research or reporting agent usually does not need contact personal data. A governed platform lets you exclude it at the policy level. BusinessMCP’s access control documentation lists a contact PII class and a No PII preset, and says fields a policy does not permit appear as “[redacted]” in results. That is minimisation enforced by the platform rather than by instructions to the model.

Key takeaway: instructions like “do not use personal data” are not controls. Removing the fields before they reach the model is.

Residency, processors and sub-processors

Know where your data sits and who touches it. BusinessMCP’s Enterprise page says the platform runs on Vercel with its database in Supabase’s EU region and lists sub-processors on its privacy page, and that custom servers run inside the customer’s perimeter and are not operated by BusinessMCP. It also publishes a GDPR page and a DPA. Read those for yourself and confirm they meet your obligations; a vendor’s statement is an input to your assessment, not a substitute for it.

Question	Why it matters	Where to look
Where is data stored?	Transfer rules and residency policy	Vendor privacy and security pages
Who are the sub-processors?	They are part of your processing chain	Sub-processor list
Is there a DPA?	Required when a vendor processes on your behalf	Vendor legal pages
What is retained and for how long?	Storage limitation	Retention settings
Can I delete on request?	Data subject rights	Vendor process

Company-level versus person-level data

Many enterprise use cases need only company-level information. Identifying organisations is a different practice from identifying individuals, and regulators treat them differently. BusinessMCP’s guide on visitor identification and GDPR discusses that distinction for website visitors. Whatever your use case, document which level you operate at and why.

Retention and deletion

Decide retention for every store the agents touch: logs, recordings, caches and conversation history. The Enterprise page describes session-recording retention as customer-defined on Enterprise, versus kept while the account is open on Business, a good example of why retention should be a setting you can change. Ensure deletion requests can reach logs and derived data, and confirm how backups are handled. The audit logging article covers trade-offs between evidence and exposure.

A privacy review checklist

1. List every system an agent can reach and classify the personal data in it.
2. Assign each tool to data classes and exclude personal classes by default.
3. Confirm the platform removes forbidden fields from outputs, not only from the tool list.
4. Obtain and review the vendor’s processor terms and sub-processor list.
5. Record storage regions, including logs and backups.
6. Set retention for logs, recordings and caches.
7. Run a data protection impact assessment where the processing is likely high risk.
8. Test a deletion request end to end.
9. Brief approvers on what they are authorising when they confirm a send.

Mistakes to avoid

Treating a pilot as exempt from privacy rules; connecting a mailbox to a general-purpose agent; logging full result payloads indefinitely; and assuming a hosted vendor handles compliance for you. Responsibility for lawful processing stays with the controller, which is you. Pair this with the security checklist and the ten-point readiness test.

Working with your data protection officer

Bring your data protection officer in at the design stage rather than at sign-off. Give them the architecture diagram, the list of data classes each agent may reach and the vendor’s processor documents. Ask for a view on whether a data protection impact assessment is needed, whether any processing needs a different lawful basis than the one you rely on today, and how long logs may be kept. Expect questions about who can read approvals and recordings. Having the answers ready shortens the review and usually reveals one or two agents that can simply be narrowed instead of defended.

Data subject requests and agents

If personal data flows through agent systems, requests to access or delete it must reach every place it lands. Map those places in advance: source systems, conversation history held by the client, caches, logs and recordings, and any exports. Decide who coordinates a request and how long each store takes to comply. Test the process with a dummy record before a real request arrives. Where a platform keeps logs of arguments and results, check whether entries can be searched by data subject and removed, or whether short retention is the practical answer. Simple designs, with personal data excluded from agent scope, make this far easier than retrofitting deletion later.

Cross-border and contractual points

If data or sub-processors sit outside your region, check which transfer mechanism the vendor relies on and whether your own policy permits it. Ask for notice when sub-processors change. Where a business unit in another country will use the platform, check local rules as well, since requirements differ. Record these decisions next to the architecture so reviewers can see how each flow was justified.