How to Run an MCP Security Review Before Connecting AI Agents to Business Systems

Tools & Technical Tutorials

22 April 2026 | By Ashley Marshall

Thousands of MCP servers are already live and connecting AI agents to business data - but the security practices to match that speed simply do not exist yet. Before you plug your next AI agent into your CRM, email, or internal database, here is what a proper security review actually looks like.

What MCP Is and Why the Security Bar Matters Right Now

The Model Context Protocol (MCP) is an open standard developed by Anthropic that lets AI agents connect to external tools, data sources, and services through a consistent interface. Think of it as a universal plug socket for AI: instead of building bespoke integrations for every tool, developers drop in an MCP server and the agent can immediately read files, query databases, send emails, or trigger workflows.

The speed of adoption has been striking. Workflow automation services such as Zapier reported millions of requests processed through their MCP endpoints within weeks of launch. Thousands of public MCP servers are already live on registries and GitHub repositories, covering everything from Google Drive and Slack to Postgres databases and internal ticketing systems. Anthropic's own Claude desktop app, along with developer tools like Cursor and VS Code extensions, all support MCP natively.

That speed is exactly what makes the security picture uncomfortable. As cloud security firm Wiz noted in their April 2025 research briefing, the MCP ecosystem is growing rapidly even as the specification itself continues to evolve. The March 2025 update introduced a foundational authorisation model that has already sparked active debate among security researchers, and an official server registry - which would provide meaningful trust signals - remains on the roadmap rather than available today.

For UK businesses, this creates a very specific risk profile. You are potentially connecting an AI agent that has broad natural-language capabilities to systems that hold personal data, financial records, client communications, or operational infrastructure. Under the UK GDPR, the ICO's guidance on AI and data protection makes clear that organisations are accountable for the decisions their systems make and the data those systems access - including when that access is mediated by an AI agent running over a third-party protocol.

The case for running a proper security review before you go live is not about slowing down AI adoption. It is about not having to unpick a data breach, a credential leak, or a regulatory investigation six months after the fact. The review process described in this post takes a few hours the first time. Every subsequent integration takes minutes once you have the framework in place.

It is also worth being honest about what MCP security is not. It is not a solved problem. The protocol is young, the tooling is immature, and some of the risks described below - particularly around prompt injection and tool poisoning - have no complete technical fix yet. What a good security review gives you is visibility, documented decisions, and a set of controls that reduce your exposure while the ecosystem matures.

Step 1: Vet Every MCP Server Before You Connect It

The first and most important step in any MCP security review is treating every server you plan to connect as you would treat any privileged software installation. Wiz's security research is blunt on this point: installing a local MCP server is definitionally running arbitrary code on your machine. The security model is essentially the same as a package manager - which means supply chain risk is real.

In practice, the MCP ecosystem today resembles what npm or PyPI looked like in its early years. Servers are built by independent developers with no established standards for secure development. Registries like glama.ai attempt to surface trust signals - licence information, vulnerability presence, whether the server runs successfully - but the limitations are significant. In Wiz's analysis of glama.ai's registry, roughly 100 of the 3,500 listed servers were linked to non-existent repositories. The "verified" and "official" labels do not confirm the identity of the developer or establish any trusted connection between a server and the product or company it claims to represent.

Before connecting any MCP server, work through the following checks:

Source verification. Who published this server? Is there a clear organisational owner with a public security track record? Prefer servers published directly by the vendor of the product you are integrating - Atlassian's own Jira server, for example, rather than a community-maintained alternative. Check the GitHub repository for recent commits, open issues flagging security concerns, and the number of contributors. A server maintained by a single anonymous account with no recent activity is a red flag.

Code audit. For any server handling sensitive data or credentials, read the source code before running it. This sounds onerous but for most MCP servers it means reviewing a few hundred lines of Python or TypeScript. Look for: outbound network calls to unexpected endpoints, hardcoded credential handling, and any code that reads files from the local filesystem beyond what the server's stated purpose requires.

Version pinning. One of the underappreciated risks identified by security researchers at Invariant Labs is what they call an MCP rug pull: a server that appears safe at installation can have its tool descriptions updated by the server operator after you have already approved it. Some clients do not re-validate tool descriptions on subsequent connections. Until the protocol provides stronger integrity guarantees, pin to a specific commit hash where possible and document the version you reviewed.

Internal registry. For teams deploying MCP at scale, the most pragmatic control is maintaining your own curated list of approved servers. Vet each one once, document the review, and require any new server to go through the same process before it can be connected to production systems. This borrows directly from mature approaches to dependency management in software engineering.

The goal of this step is not to block all third-party servers. It is to ensure you have made a deliberate, documented decision about each one rather than installing it because the README looked credible.

Step 2: Scope Credentials and Apply Least Privilege

MCP servers almost always require credentials to do anything useful. A server connecting your AI agent to your CRM needs an API key. One connecting to your email needs OAuth access. One connecting to your database needs connection credentials. The way you grant and scope those credentials is one of the highest-leverage security decisions in your entire MCP setup.

The principle of least privilege applies here just as it does to any software system: each MCP server should receive only the permissions it actually needs, scoped as narrowly as the underlying service allows. In practice, this means asking several specific questions for each integration:

Read versus write. Does this server need to write data, or just read it? An MCP server that helps your AI agent retrieve information from your knowledge base does not need write access to that knowledge base. Many APIs offer read-only scopes or tokens - use them wherever possible. The blast radius of a compromised read-only credential is dramatically smaller than a compromised read-write one.

Scope to resources, not systems. Where the underlying service supports resource-level permissions, use them. A server connecting to Google Drive should ideally be scoped to a specific folder, not the entire Drive. A server connecting to a Postgres database should connect as a user with SELECT permissions on specific tables, not as the database administrator.

Credential storage. MCP servers often store API keys in configuration files on the local filesystem - typically in locations like `~/.cursor/mcp.json` or similar. Invariant Labs' tool poisoning research demonstrated that a malicious MCP server can instruct an AI agent to read these files and transmit their contents to an attacker. This means that all your MCP credentials, if stored in a single configuration file, are effectively a single point of compromise. Mitigations include using a secrets manager (1Password, HashiCorp Vault, or AWS Secrets Manager) rather than plaintext config files, and ensuring that each server's credentials are stored and rotated independently.

Token rotation. Treat MCP server credentials as you would any other privileged access token: rotate them regularly, revoke them when a server is removed, and audit which credentials are active. Many teams connect an MCP server, forget about it, and leave the credential active indefinitely - including after the server is no longer in use.

Authentication for remote servers. Remote MCP servers accessed over HTTP introduce additional complexity. The March 2025 MCP specification introduced an OAuth authorisation model, but security researchers have noted that the implementation is complex and prone to bugs. If you are connecting to a remote MCP server, verify that it implements the current authorisation specification correctly and that you understand exactly what scopes you are granting.

A practical starting point: before connecting any server, write down what credentials it needs and what the minimum viable scope for those credentials is. If you cannot articulate that clearly, the integration is not ready to go live.

Step 3: Understand and Control What the Agent Can Actually Do

The third area of an MCP security review is one that many teams skip entirely: auditing what actions the AI agent can take through each connected server, and putting controls in place to limit or monitor those actions. This is distinct from credential scoping - it is about the behaviour of the agent itself, not just the permissions of the underlying account.

The most significant risk here is what security researchers call indirect prompt injection or tool poisoning. In April 2025, security firm Invariant Labs published a detailed disclosure of a critical vulnerability in the MCP ecosystem. Their research demonstrated that malicious instructions can be embedded within MCP tool descriptions - invisible to users in the client interface but visible to the AI model. These hidden instructions can direct the AI to access sensitive files, transmit credentials to external endpoints, or behave in ways that directly contradict what the user asked for.

Their proof-of-concept was stark. A malicious server registered a simple addition tool. Hidden in that tool's description were instructions directing the AI to read the user's MCP configuration file and SSH private keys, then pass their contents to the attacker via a side parameter - all while the user's interface showed only a routine maths operation. The AI followed those instructions precisely.

A second attack vector, which Invariant Labs call shadowing, is even more concerning in multi-server environments. A malicious server can embed instructions in its tool descriptions that modify the behaviour of other, trusted servers. In their demonstration, a bogus server caused the agent to redirect all outbound emails to the attacker's address - even when the user explicitly specified a different recipient.

The practical controls available to you today are as follows:

Human-in-the-loop. The MCP specification itself explicitly recommends requiring human approval before tool invocation. Many MCP clients support approval workflows where the agent surfaces the proposed action and waits for confirmation before executing it. Enable this for any action that writes data, sends communications, or makes external API calls. It adds friction but dramatically reduces the impact of a compromised or malicious server.

Client selection. Not all MCP clients are equivalent. Some auto-run tools without surfacing them to the user; others require explicit approval. Some show the full tool inputs; others show a simplified summary that can mask malicious parameters. Choose your client based on its security posture, not just its feature set. Evaluate: does it show full tool descriptions? Does it support per-server approval flows? Does it have any mechanism to detect anomalous tool behaviour?

Tool allowlisting. For production deployments, consider allowing only specific named tools from each connected server rather than the full set of tools the server advertises. Some enterprise MCP gateway solutions support this - centralising all server connections through a proxy that enforces tool-level policies, logs all invocations, and can block specific tool calls based on rules.

Sandboxing. For higher-risk integrations, consider running MCP servers in containers with restricted network egress. This limits the impact if a server attempts to make outbound calls to unexpected endpoints. Note that sandboxing alone does not prevent a compromised server from using other tools available to the agent - it only limits direct outbound access.

Step 4: Map Your MCP Connections to UK Data Protection Obligations

For UK businesses handling personal data - which is to say, almost every business - connecting an AI agent to live systems via MCP is likely to trigger data protection obligations that go beyond technical security. The ICO's guidance on AI and data protection is clear that organisations must be accountable for how their AI systems process personal data, and that accountability applies to the full data flow, including third-party tools and integrations.

The NCSC's guidelines for secure AI system development, developed jointly with the US Cybersecurity and Infrastructure Security Agency (CISA) and agencies from 17 other countries, make a related point: keeping AI systems secure is as much about organisational culture, process, and communication as it is about technical measures. Security must be integrated from the start, not bolted on after deployment.

The specific data protection questions to work through before going live with an MCP integration are as follows:

Does this integration require a Data Protection Impact Assessment (DPIA)? The ICO's updated AI guidance introduced specific requirements around DPIAs for AI systems. If your MCP integration enables an AI agent to systematically access, process, or act on personal data - customer records, employee data, communications - a DPIA is likely required before you go live. This is not optional; the UK GDPR requires it for high-risk processing activities.

Where does data flow? Map every data flow in your MCP integration. When the agent queries your CRM via an MCP server, what data is retrieved? Is it sent to the AI model provider for inference? Does the MCP server log it? Does it touch any third-party infrastructure? For remote MCP servers, you are potentially transferring personal data to a third-party processor, which requires appropriate contractual safeguards under the UK GDPR.

What is the lawful basis? The ICO's guidance requires that AI processing of personal data has a clear lawful basis. If you are using an MCP-connected agent to process client data, employee data, or any other personal data, you need a documented lawful basis for that processing. This is particularly relevant for automated decision-making: if the agent is making or contributing to decisions that affect individuals, Article 22 of the UK GDPR may apply.

Data minimisation. One of the clearest mitigations for MCP-related data protection risk is also one of the simplest: do not give the agent access to more personal data than it needs. If the integration is for internal knowledge management, scope it to the relevant knowledge base. If it is for customer communications, restrict it to the relevant account records. Prompt minimisation reduces both security risk and data protection exposure.

Documentation. Whatever decisions you make about your MCP integrations, document them. The ICO's accountability principle requires that you can demonstrate how and why your AI systems process personal data in the way they do. A short decision log - covering what data is accessed, what controls are in place, and what the lawful basis is - is both good practice and a meaningful protection if you ever face regulatory scrutiny.

Step 5: Build a Repeatable Review Process

A one-off security review before your first MCP integration is valuable. A repeatable process that applies the same standard to every subsequent integration is what actually keeps your risk posture coherent as your use of AI agents grows. This section covers how to operationalise the review so it does not become a bottleneck.

The core of a repeatable MCP security review is a short checklist that someone - a technical lead, a security-minded developer, or an IT manager - can work through before any new MCP server is approved for connection to production systems. Based on the framework above, that checklist covers six areas:

1. Server provenance. Who published this server? Is the source code publicly available and recently maintained? Have you reviewed the code for unexpected network calls or file access?

2. Version pinning. Have you pinned to a specific version or commit hash? Do you have a process to review and approve updates before they are applied?

3. Credential scoping. What credentials does the server require? Are they scoped to the minimum necessary permissions? Are they stored in a secrets manager rather than a plaintext config file?

4. Action controls. What actions can the agent take through this server? Is human-in-the-loop approval enabled for write actions? Has the tool set been reviewed for anything unexpected?

5. Data protection mapping. What personal data, if any, does this integration access or transmit? Is a DPIA required? What is the lawful basis?

6. Incident response. If this server were compromised, what would you do? Who would you notify? How quickly could you revoke its credentials and disconnect it?

Beyond the checklist, there are a few structural decisions that make ongoing MCP security management practical. First, centralise your MCP server configuration wherever possible. If all servers are managed through a single configuration file or a gateway, you have a single place to audit, update, and revoke access. Distributed, individually-managed MCP installations are much harder to keep track of as teams grow.

Second, maintain an active inventory. Know which MCP servers are connected, to which systems, with which credentials, and who approved them. This does not need to be complex - a shared spreadsheet or a section of your IT asset register works fine. What matters is that the inventory exists and is kept current.

Third, run periodic reviews. Set a calendar reminder to review your active MCP connections every quarter. Check that the servers are still being maintained by their publishers, that the credentials are still appropriately scoped, and that the integrations are still serving a legitimate business purpose. Decommission anything that is not actively used.

The counterargument to all of this is that it creates overhead that slows down AI adoption at a time when speed matters. That concern is legitimate. But the review process described here, once established, should take no more than thirty minutes per new integration. The alternative - discovering a credential leak, a data breach, or an ICO investigation after the fact - takes very much longer to resolve.

Wiz's conclusion in their MCP security research is the right frame: treat MCP with the same discipline you would apply to any privileged integration surface. The tools are powerful. The risks are real. The controls are available. The question is whether you choose to apply them before or after something goes wrong.

What to Watch as MCP Security Matures

MCP security is a rapidly moving field, and it is worth knowing what improvements are coming so you can factor them into your planning. The current limitations are real, but many of them are being addressed directly by the protocol designers and the broader open-source community.

The most significant near-term development is an official MCP server registry. When this arrives, it should bring with it stronger primitives around signing, pinning, and version locking - patterns borrowed from mature package managers like npm and Cargo. This would substantially reduce supply chain risk by making it possible to verify that the code you are running matches the code that was reviewed and published.

Tool namespacing is another improvement that will reduce the risk of tool name conflicts and impersonation. Cloudflare has already implemented scoped naming conventions in their Agents SDK, demonstrating how this can work in practice. When namespacing becomes standard in the MCP specification, it will be much harder for a malicious server to register a tool that shadows or overrides a trusted one.

On the client side, there is active development of MCP gateways - proxies that centralise all server connections and provide a single point of control for audit logging, guardrails, and governance. Open-source options including MCP Guardian and MCP Gateway are already available, with the former offering auditing capabilities, message approvals, and server management, and the latter focusing on data masking and prompt injection mitigation.

The MCP specification itself is also evolving. Tool annotations for "readOnly" and "destructive" actions were introduced in a recent release. The next step - enforcement mechanisms for those annotations, and permission declarations at the org level - would bring MCP permissions much closer to the model used by OAuth scopes and mobile app permissions, which is a significantly more mature and user-understandable model.

For UK businesses planning their AI agent strategy, the practical implication is this: the controls available to you today are sufficient to deploy MCP safely if you apply them deliberately. The controls available in twelve months will be substantially better. Building your review process now, and building it on principles rather than specific tooling, means you will be well-positioned to adopt stronger controls as they emerge without having to retrofit security onto an already-deployed estate.

The NCSC's framing remains the most useful: security must be a core requirement, not just in the development phase, but throughout the lifecycle of any AI system. MCP is no exception. The businesses that approach it with that mindset are the ones that will extract the most value from it - because they will not be spending 2027 unpicking the security decisions they rushed through in 2025.

Frequently Asked Questions

What is MCP and why does it create security risks?

MCP (Model Context Protocol) is an open standard that lets AI agents connect to external tools and data sources through a consistent interface. The security risks arise because MCP servers often run arbitrary code with access to credentials and data, the ecosystem lacks mature trust signals, and the protocol's youth means security practices have not kept pace with adoption. Thousands of servers are already live with no official registry or code-signing standard.

What is a tool poisoning attack and how does it work?

A tool poisoning attack embeds malicious instructions within MCP tool descriptions that are invisible to users but visible to the AI model. When the agent invokes the tool, it follows the hidden instructions - which can include reading sensitive files, transmitting credentials to an attacker, or modifying the agent's behaviour with respect to other trusted tools. Invariant Labs demonstrated this with a proof-of-concept that exfiltrated SSH keys and MCP configuration files through a seemingly innocent addition tool.

Do I need to do a DPIA before connecting AI agents to business systems via MCP?

Almost certainly yes, if the integration involves personal data. The ICO's guidance on AI and data protection requires a Data Protection Impact Assessment for high-risk processing activities, which typically includes systematic access to personal data by AI systems. This applies regardless of whether the processing is direct or mediated through a third-party protocol like MCP.

What is an MCP rug pull and how do I protect against it?

An MCP rug pull is when a server's tool descriptions are updated after you have already approved and connected the server - potentially inserting malicious instructions into tools you have been using safely. Protection involves pinning to a specific version or commit hash, implementing a process to review and approve updates before applying them, and using a gateway or proxy that can detect changes to tool descriptions.

Is it safer to use local MCP servers or remote ones?

Both have distinct risks. Local servers run arbitrary code on your machine and carry significant supply chain risk. Remote servers do not run locally, but can still achieve remote code execution, credential theft, or data exfiltration by interacting with other tools or permissions available to the client. Remote servers also introduce vendor risk around data handling. The safer approach is to prefer local servers from well-vetted publishers for sensitive integrations, and to apply the same credential scoping and action controls regardless of server type.

What should I look for when reviewing MCP server source code?

Focus on four areas: unexpected outbound network calls to endpoints not related to the server's stated purpose; how credentials are stored and handled (look for hardcoded secrets or overly broad file access); what the tool descriptions contain (hidden instructions in tool docstrings are the primary tool poisoning vector); and whether the server has any mechanism to update its own configuration or tool descriptions after installation.

How do I manage MCP security across a team rather than just individual developers?

The most effective approach is an internal registry: a curated list of approved MCP servers, each with a documented review, the specific version approved, and the credentials it is authorised to use. Pair this with a gateway or proxy that centralises all server connections and enforces the approved list. This gives you visibility, control, and an audit trail without blocking individual developers from experimenting in non-production environments.

What UK-specific regulations apply to MCP and AI agent deployments?

The primary framework is the UK GDPR and Data Protection Act 2018, administered by the ICO. The ICO's AI guidance covers accountability, transparency, lawful basis for processing, and DPIA requirements. The NCSC's Guidelines for Secure AI System Development (developed with CISA and 17 other countries' agencies) provide technical security guidance. For regulated sectors, additional requirements may apply from the FCA, CQC, or other sector regulators.