MCP security: risks and best practices for Model Context Protocol

What is MCP?

The Model Context Protocol (MCP) is, in the words of its own documentation at modelcontextprotocol.io, "an open-source standard for connecting AI applications to external systems". It lets AI applications connect to data sources (local files, databases), tools (search, calculators, business apps) and workflows, so they can fetch information and carry out tasks. The project likens it to a USB-C port for AI applications.

In practice, an MCP client inside an AI app (a desktop assistant, a coding tool, an agent) connects to one or more MCP servers. Each server exposes tools, such as "read file", "query database" or "create ticket", with a name and a description the AI reads to decide when to use it. Some servers run in the cloud; many run locally on the user's own machine.

That design is why MCP spread so quickly, and why it deserves its own security thinking.

Why MCP changes the risk picture

Before MCP, most workplace AI risk was about what people typed into a chat box. With MCP, the AI can act:

• It can read whatever the connected server can reach: a folder, a mailbox, a CRM, a code repository.
• It can write, update and delete through the tools the server exposes.
• It usually acts with the user's permissions, or with a token granted when the server was set up.
• It decides which tool to use by reading text, which means it can be influenced by text it should not trust (see prompt injection).

So the question is no longer only "what data could leak in a prompt?" but "what could an agent be talked into doing, and with whose access?"

MCP security risks

These are the risks we see organisations needing to manage. The MCP project's own Security Best Practices document covers several of them in technical depth for people building servers.

• Unvetted and local servers: MCP servers are often downloaded and run on a user's machine. The MCP documentation warns that local servers from untrusted sources, or with inadequate restrictions, can run malicious start-up commands or carry malicious payloads with direct access to the user's system.
• Excessive permissions: servers granted broad scopes up front ("all files", "admin") turn one leaked token or one misled agent into a large incident. The MCP guidance calls for scope minimisation.
• Tool poisoning and indirect injection: tool names, descriptions and tool outputs are read by the model, so a malicious or compromised server can steer the agent through that text.
• Data exfiltration: an agent with read access to sensitive data and any outbound tool (email, web request, file upload) can be manipulated into sending data out.
• Connectors staff install themselves: developers and power users add MCP servers to their editors and desktop assistants without anyone knowing. That is shadow AI with real permissions.
• Authorisation flaws in servers you run: for teams building MCP servers, the specification's guidance covers problems such as confused deputy attacks, token passthrough, server-side request forgery and session hijacking.

MCP security best practices

A practical baseline for most organisations:

1. Inventory MCP use. Find out which AI apps, editors and agents are connecting to which MCP servers, on which devices, before setting policy.
2. Approve servers centrally. Keep an allow-list of vetted MCP servers and versions; treat new ones like any other software request.
3. Minimise scopes and permissions. Grant each server the narrowest access it needs, ideally read-only by default, and avoid broad admin tokens.
4. Separate read and write. Allow low-risk read tools widely; restrict create, update and especially delete operations to specific users or block them.
5. Require approval for consequential actions. Sending, deleting, paying or changing permissions should need a person to confirm.
6. Watch the text the agent reads. Treat tool descriptions and outputs as untrusted input and inspect them where you can.
7. Protect data in the flow. Apply data loss controls to what agents send to models and to external tools.
8. Log everything an agent does. Keep a record of tool calls, inputs and outputs for investigation and audit.
9. Write it into policy. Your AI security policy should say who may add MCP servers and how they are approved.

Steps 1, 4 and 8 are hard to do by hand once more than a handful of people use agents, which is where tooling earns its keep.

How Check Point covers MCP

Check Point addresses MCP in three products, each from a different angle:

Two details from Check Point's administration guide are worth knowing. Workforce AI Security agent policies can also enforce URL and file reputation checks and apply content moderation. And a separate Prompt Attack feature analyses MCP tool definitions and tool call inputs and outputs for signs of injection; when we checked, it was in Early Availability and ran in detect-only mode, so it records events rather than blocking. We confirm the current position when we quote.

Note that MCP and desktop agent coverage sits in the Enterprise tier. The web-focused Essentials tier covers AI used through browser applications, so it will not see a coding assistant's MCP connections. Our Essentials vs Enterprise guide sets out the difference.

Employee MCP use vs the agents you build

It helps to separate two problems that often get mixed up:

• Staff adding MCP servers to their own tools. A developer connects their AI editor to a database; an analyst connects a desktop assistant to a shared drive. You did not build any of it, but you are accountable for the data. This is governed by Workforce AI Security Enterprise, alongside policy and training.
• Agents your organisation builds. Your teams deploy agents on cloud or low-code platforms that call MCP servers and tools on behalf of customers or colleagues. This is the job of Check Point AI Agent Security, often paired with red teaming before release.

Many organisations only have the first problem today. Starting there gives you the inventory you need if the second arrives later.

Rolling out MCP controls without stopping work

Developers in particular will route around controls that break their tools. A staged approach works better:

1. Deploy discovery to a pilot group that includes heavy agent users, in monitoring mode.
2. Review which MCP servers and tools are in use, and which perform write or delete operations.
3. Agree an approved list with the people who use them, and block clearly risky or unknown servers.
4. Restrict high-impact operations first (deletes, external sends) rather than whole servers.
5. Extend to everyone, review agent events regularly, and revisit the list as new servers appear.

See AI coding assistant security for the developer-specific side of this.

How Forever Systems helps

We help you get MCP under control in proportion to how much it is used:

• We help scope whether you need Workforce AI Security Enterprise, Check Point AI Agent Security, the AI Network Firewall or a mix, and we quote for what fits. Pricing is confirmed at quote: ask us for a quote.
• We help run a discovery pilot and read the results with you, so decisions are based on what is actually in use.
• We help you write MCP approval into your AI policies and turn it into enforceable agent policies.

To discuss MCP security, contact us.