MCP server security & GDPR: how to keep your deployment safe

How do you stay safe with MCP servers?

You stay safe if every MCP server only accepts authenticated requests, offers only fixed and narrowly authorised tools, treats third-party content as data, logs every call and only goes live after a review. Everything else on this page expands on these five points.

• Sign-in on every request
• Narrow permissions per tool
• Third-party text is never a command
• Audit log of every call
• Approval before go-live

Why is MCP security a discipline of its own?

Because an AI agent decides at runtime which tool to call, and in doing so reads text that someone else wrote. Classic security asks who is allowed in. With MCP, there is an added question: what may the agent do on its own, and who told it to?

When you connect business systems via the Model Context Protocol, the risk shifts from pure access control to the question of how an agent can be induced to do something nobody wanted. This guide complements the general framework in GDPR-compliant AI with the concrete levers at MCP level.

Which attacks threaten MCP servers? The threat model

The most important attacks target sign-in to the server, the passing on of credentials, manipulated tools and text that the model mistakes for a command. The table shows how each one happens and what helps against it.

What we see in practice: In our own security research on publicly available MCP servers, the high-rated findings consistently lay at the transport and sign-in level, not in the logic of individual tools. A typical pattern is a host check that compares only the start of the address instead of the whole. That is why sign-in comes first on the checklist. Background on OAuth pitfalls in the MCP ecosystem is provided by CyberSec42's security research on MCP OAuth security.

How prompt injection works in detail and which defences are effective is described in the guide Prompt injection and AI security.

What does the MCP specification require for authorization?

The current MCP specification (version 2026-07-28) makes authorization optional. Anyone offering it over HTTP, however, should implement OAuth 2.1 according to fixed rules, and the server must verify that every token was issued specifically for it.

The most important requirements from the authorization specification and the Streamable HTTP transport, as of October 2026 (version overview):

• OAuth 2.1 as the foundation: Authorization servers must implement OAuth 2.1; the flow uses PKCE.
• Sign-in on every request: The token is in the Authorization header of every HTTP request, never in the URL.
• Token only for this server: MCP servers must verify that a token was issued with them as the audience. Clients must name the server for this via a resource indicator (RFC 8707).
• No passthrough: Servers must not accept or forward other tokens. This is the protection against token passthrough.
• Metadata: Servers must offer OAuth 2.0 Protected Resource Metadata (RFC 9728) so that clients can find the right authorization server.
• Scopes in moderation: The specification recommends starting with a minimal set of scopes and requesting more only when needed.
• Local servers over stdio: They do not follow the OAuth specification but obtain credentials from the environment.
• Transport: Servers must check the Origin header to prevent DNS rebinding, should bind locally only to 127.0.0.1 and should authenticate every connection.
• New in this version: The protocol no longer has sessions. If a server needs state across several requests, holding such an identifier is not authentication according to the specification; every request is checked on its own. Dynamic client registration is marked as deprecated, and Client ID Metadata Documents are preferred.

The specification's Security Best Practices also describe confused deputy, token passthrough, SSRF in metadata discovery, compromised local servers and the minimisation of scopes in detail. Anyone building a server themselves should read both documents in full.

OWASP MCP Top 10: which risks does OWASP name?

OWASP lists ten risk classes for MCP environments, from unprotected credentials to unapproved shadow servers. As of October 2026, the project has beta status (OWASP MCP Top 10).

What does SAP require of its own MCP servers?

The SAP Architecture Center ties its own MCP servers to a governance checklist that also works well as a yardstick outside SAP (SAP Architecture Center).

• No passing through of the user token; instead, token exchange according to RFC 8693 with agent and user context
• No long-lived credentials, secrets in a secrets store, TLS from version 1.2
• Validate inputs, follow the OWASP MCP Top 10
• Rate limits below the quotas of the target system, timeouts and circuit breakers
• Stateless operation and versioned tool descriptions
• Audit log of every tool call with caller, parameters with redacted personal data, target API, status and duration, linked via W3C TraceContext

What SAP otherwise permits for AI agents on SAP systems is covered in the guide SAP MCP server and API Policy. For direct database access, there is a separate guide on the SAP HANA MCP server.

Checklist for operating MCP servers

We use this checklist before every go-live and with every change. Each point can be checked individually.

• 1. Sign-in on every requestNo endpoint without authentication, not even internal ones. The token is checked on every request, including audience and expiry.
• 2. Scope is mandatoryEvery tool requires a matching scope. A token that may only read invoices cannot change master data.
• 3. Local means loopback onlyLocal HTTP servers bind to 127.0.0.1, check Origin and Host exactly against a fixed list and still require a token. Even better: stdio.
• 4. Fixed toolsOne tool per use case with fixed fields and upper limits. No generic "run query" or "call URL".
• 5. Read firstThe first server only reads. Tools that write come later, in a separate server and with approval by a human.
• 6. Validate inputsEvery parameter is checked against a strict schema. Anything unexpected is rejected, not "repaired".
• 7. Rate limitsLimits per user and per tool, below the quotas of the connected system.
• 8. TimeoutsEvery call to a target system has a time limit and a circuit breaker, so that no agent slows a backend down in a loop.
• 9. Audit log without content dataWho, which tool, which parameters, status, duration. Personal values redacted, no email texts or receipts in the log.
• 10. Error texts do not go to the modelError messages from target systems often contain third-party text and internal details. The model gets a neutral message; the full text goes to the audit log.
• 11. Secrets storeCredentials live in a secrets store, not in configuration files or environment files in the repository, and are rotated regularly.
• 12. Updates with pinned versionsServers and dependencies run on a pinned version. Updates are applied deliberately, and tool descriptions are re-read in the process.
• 13. Approval of new serversNo MCP server goes live without a documented review, not even "just for testing" with real data.
• 14. Separation of roles and clientsAn agent working for client A sees no data from client B. The separation is technically enforced, through client-bound tokens and by checking every access against the context.

Would you like to know how your existing setup measures up against this list? The MCP security quick check shows what your AI agents can reach today.

Local MCP servers: what applies on your own machine?

Local MCP servers run with the rights of the signed-in user and are therefore as dangerous as any other program you install. The specification describes three ways this goes wrong: a malicious start command in the configuration, malicious code in the server itself, and an open local server that is addressed from a web page via DNS rebinding.

• Prefer stdio: Then only your own client talks to the server, and there is no open port.
• If HTTP, then tightly: Bind to 127.0.0.1, check Origin and Host exactly, use a token locally too.
• Look at the start command: For one-click installation, clients must, according to the specification, show the exact command in full and obtain consent. Actually read it.
• Run with limits: Start servers in a sandbox or container, with access only to the necessary folders and network destinations.

How do you approve new MCP servers?

With a fixed process that checks origin, code, permissions, network and vendor terms before a server touches real data. OWASP names unapproved servers as a risk class of their own (MCP09, Shadow MCP Servers).

1. Origin: Who maintains the server, how actively, is there a reporting channel for security vulnerabilities?
2. Code and version: Review a specific version and use exactly that one, not "latest".
3. Read the tools: Which tools does the server offer, what do the descriptions say, are there free-form queries, shell tools or URL tools?
4. Permissions and network: Which account does it use to access systems, which destinations may it reach?
5. Vendor terms: Does the provider of the connected system allow access by AI agents at all? Several vendors published rules on this in 2025 and 2026. The guide MCP and vendor policies gives an overview.
6. Test operation: First with test data, then with real data and an audit log.
7. Directory: Every approved server is listed with its version, owner and purpose. Every update is a new approval.

Logging: audit-ready, but without content data

An MCP server should log every tool call in a way that later shows who triggered what, without the log itself becoming a data collection. An agent whose actions you cannot trace is not manageable in the sense of the GDPR.

• Identity of the trigger and an ID for the request, linkable across systems
• Tool called and parameters, personal values redacted
• Result status, data volume and duration
• Timestamp, stored append-only, not changeable afterwards

In a dispute, for example over the question "Who sent this invoice?", this is the difference between an answer you can prove and a shrug. Define retention periods and access rights for the log itself, because logs are personal data too.

GDPR: what do you need to settle when using MCP?

For MCP use you need a legal basis, data processing agreements with all service providers, data minimisation already in the tool, an honest account of who operates which part, and often the involvement of the works council. This is our assessment, not legal advice.

Data processing

As soon as personal data goes to a service provider who processes it on your behalf, you need a data processing agreement under Art. 28 GDPR (GDPR). This affects the model provider, the operator of the MCP server if that is not you, and hosting providers. The contract regulates purpose limitation, sub-processors, retention periods and processing locations. The major model providers make such contracts available in their enterprise and cloud offerings.

Data minimisation in the tool

Art. 5(1)(c) GDPR requires that only the necessary data is processed, and Art. 25 requires data protection by design. For MCP this means: the tool decides which fields the model sees at all. A dunning routine needs the amount and due date, not the conversation notes on the contact person. What the tool does not deliver, the model can neither process nor pass on.

Presenting the location honestly

An MCP chain has several parts, and each can run somewhere else. For each part, record who operates it and where:

We operate the MCP server itself in the EU, for example in the Azure region Germany West Central (Frankfurt) or with a German hosting provider. For the language model we use offerings with a contractually selectable EU region. If a US provider is in the path, a third-country link under Art. 44 et seq. GDPR still needs to be assessed, for example through group access or support. In that case we do not give a blanket assurance that data never leaves Europe.

Works council

Under § 87(1) no. 6 BetrVG (German Works Constitution Act), the works council has a co-determination right where technical systems are suitable for monitoring the behaviour or performance of employees (BetrVG). Audit logs that record who asked the assistant which question can fall under this. Involve the works council early and define what the logs may be analysed for.

On-premises, EU cloud or hybrid?

Both routes can be implemented in a GDPR-compliant way. The decision should depend on the data class, not on gut feeling:

1. On-premises or your own data centre Data stays in your own network, and control lies with you. In return, you operate, patch and monitor it yourself. Makes sense for particularly sensitive data or existing strong IT.
2. EU cloud (managed) A clearly defined region in Europe with considerably less operating effort. For many mid-sized companies the pragmatic standard, provided hosting and model provider keep to the chosen region.
3. Hybrid Sensitive processing locally, less critical steps in the EU cloud. More architectural effort, but fine-grained control; often the answer for grown IT landscapes in mid-sized companies.

Frequently asked questions

How do you stay safe on MCP servers?

With five basic rules: every request to the server is authenticated, every tool has narrowly defined permissions, content from emails, documents and tool responses counts as data and never as an instruction, every call is logged, and new servers go live only after a review. Read-only tools come first, tools that write only with approval by a human.

What is the most common serious vulnerability in MCP servers?

According to our own security research on publicly available MCP servers, the serious vulnerabilities lie mainly at the transport and sign-in level. Typical is an HTTP endpoint with no or incomplete authentication. Anyone who reaches the endpoint uses the tools with the operator's credentials. With local servers, DNS rebinding can even put this within reach from the browser.

What is token passthrough and why is it prohibited?

Token passthrough means that an MCP server accepts a token that was not issued for it and passes it on to a downstream interface. The MCP specification prohibits this because checks, limits and traceability are lost in the process, and the server can become a tool for data leakage.

What is tool poisoning?

In tool poisoning, manipulated instructions are hidden in the description or in the responses of a tool. This often stays invisible to humans, while the model reads it along. Protection comes from vetted servers with a pinned version, a review of tool descriptions with every update, and approval for write actions.

Can an MCP server be operated in a GDPR-compliant way?

Yes, if the legal basis, data processing agreements, data minimisation in the tool and logging are right, and you honestly record who operates which part and where processing takes place. If a US provider is in the path, a third-country link cannot be ruled out. This is our assessment, not legal advice.

Do I need a DPA with the AI provider?

As soon as personal data goes to a service provider who processes it on your behalf, you need a data processing agreement under Art. 28 GDPR. This applies to the model provider as well as to the operator of the MCP server, if that is not you.

Does the data stay in the EU?

That depends on every single part of the chain: assistant, model, MCP server and connected systems. An EU region with cloud providers is an important building block. We do not give a blanket assurance that data never leaves Europe when a US provider is involved.

What belongs in the audit log of an MCP server?

For each call: who triggered it, which tool with which parameters, result status, data volume, duration and time. Personal values are redacted, and content data such as email texts or receipts do not belong in the log. It is stored in such a way that entries cannot be changed afterwards.

Does the works council have to be involved when using MCP?

Often yes. Under § 87(1) no. 6 BetrVG (German Works Constitution Act), the works council has a co-determination right where technical systems are suitable for monitoring the behaviour or performance of employees. Audit logs of AI assistants can be such systems. So involve the works council early.

How do I check a third-party MCP server before approving it?

Check the origin and maintenance of the project, review code and dependencies in a pinned version, read the tools and their descriptions, limit permissions and network access to what is necessary, check the terms of the connected vendor, and run the server in a test environment first. Every update is a new approval.