Putting MCP into production in the UK: the NCSC's guidance, and what UK data law expects

The same month the NSA published its design guidance for Model Context Protocol, the UK's National Cyber Security Centre — with its Five Eyes partners — published Careful adoption of agentic AI services, summarised in its May 2026 blog Thinking carefully before adopting agentic AI. For a UK organisation, that is the guidance that counts: it comes from the body your board actually answers to, and it lands the same warning in British terms. Layered on top is UK data-protection law — the UK GDPR and the Data Protection Act 2018, now amended by the Data (Use and Access) Act 2025 — which turns "connect our systems to an LLM" into a regulated activity with specific obligations.

This is not an argument against MCP. It is the standard worth adopting to connect language models to real systems. It is an argument for deploying it deliberately — and the reassuring part, for a UK buyer especially, is that the secure way to build it is also the compliant way and the sovereignty-preserving way. They are the same build. Here is the map.

What the NCSC actually says

The NCSC's guidance treats agentic AI risks as extensions of known LLM and supply-chain risks, amplified by autonomy: broad access to systems and data, behaviour that is hard to predict, actions that happen faster than a human can review, and systems whose decisions are hard to explain. Its headline recommendations are deliberately plain:

• Start small — use agents for low-risk, well-understood tasks first.
• Apply established cyber security controls from the outset — access control, secure development, supply-chain scrutiny, monitoring, incident response.
• Restrict access to sensitive data and critical systems — do not grant broad or standing access.
• Layered defence and strict access controls, deployed incrementally.
• Plan for failure — prioritise resilience, reversibility, and risk containment; assume the system may behave unexpectedly.

It is the same substance as the NSA's MCP-specific sheet, in the UK's institutional voice — and notably, the NCSC also flags the jurisdiction of hosted models as a matter to weigh, which bears directly on how and where you run an MCP server.

What UK data law adds

The moment an MCP server exposes business data to a model and any of that data is personal, you are processing personal data — and the UK GDPR and DPA 2018, as amended by the Data (Use and Access) Act 2025, apply. Three obligations bear directly on an MCP build:

• Security of processing (Article 32). You must apply appropriate technical and organisational measures — authentication, access control, encryption, isolation, logging. These are precisely the controls the MCP specification leaves optional.
• Data minimisation and purpose limitation. An agent with broad tool access will reach for more data than the task needs. Scope the tools, and the data they can touch, to the minimum.
• International transfers. The Act revised the UK's transfer test, and the UK retains its EU adequacy decision (renewed to December 2031). The practical consequence: keep data in-UK and in-jurisdiction and you preserve that alignment; route it to an offshore-hosted MCP server and you can turn a straightforward integration into a cross-border transfer problem you then have to justify.

Underlying all of it is accountability: you must be able to evidence that these measures are in place.

Where MCP collides with the obligations

MCP's security model is underspecified by design. Authentication is optional; there is no built-in role-based access control; tokens have no mandated lifecycle; servers often lack task and data isolation; and trust between components is largely implicit, which is what makes tool poisoning, over-broad scopes, and output-poisoning attacks possible. Every one of those gaps maps onto a UK obligation it would otherwise breach — optional auth against Article 32, broad tool access against data minimisation, missing logs against accountability. The protocol's defaults and the regulator's expectations point in opposite directions, and closing that distance is the work.

The secure, compliant, and sovereign pattern

The architecture that satisfies the NCSC's "restrict access, layered defence, plan for failure" and the UK GDPR's Article 32 is a single pattern:

• Run the MCP server in your own environment and your own jurisdiction, so data never crosses your boundary or leaves the UK.
• Scope tools and permissions to the minimum, and segregate by data sensitivity so public-data tools and sensitive-data tools never share a trust zone.
• Supply what the protocol omits — authentication, RBAC, a real token lifecycle, and comprehensive audit logging.
• Filter egress, and keep a human in the loop for consequential actions, with the ability to reverse them.

For a UK organisation this is a happy convergence rather than a trade-off: keeping the server and the data inside your boundary and inside the UK answers the NCSC's hosting-jurisdiction concern, meets Article 32, and avoids manufacturing a cross-border transfer — all at once.

At Vitnis we build MCP integrations for UK organisations exactly this way: in your environment, in-jurisdiction, scoped to the minimum, secure and compliant by design, and handed over clean. The fastest way to stand an MCP server up is rarely the way that survives a data-protection review — and building to the NCSC's guidance and UK data law from the start is far cheaper than retrofitting either after an incident.