The Model Context Protocol (MCP) is rapidly becoming the standard way to extend AI assistants like Claude with real-world capabilities — connecting them to databases, internal tools, APIs, calendars, code repositories, and more. For end users, this is transformative. For IT administrators, it introduces a new and urgent question: how do you give employees access to these powerful integrations without opening the door to data leakage, unauthorised access, or supply chain attacks?

This post walks through what MCP is, where the security risks lie, and the practical controls IT teams can put in place today.

What is MCP, and Why Does It Matter for IT?

MCP is an open protocol, developed by Anthropic, that allows AI models to connect to external tools and data sources through standardised "servers." Think of it like USB-C for AI — a common interface that lets Claude plug into virtually any system.

When a user runs Claude with MCP enabled, Claude can:

• Read and write files on a local or network filesystem

• Query internal databases or SaaS platforms

• Execute code or run shell commands

• Interact with services like GitHub, Jira, Slack, or your CRM

This is extraordinarily powerful — and that power is exactly why it demands proper governance. An MCP server that has been tampered with, misconfigured, or simply too permissive can become a vector for data exfiltration or unauthorised system access.

The Core Security Risks

Before looking at controls, it's worth naming the specific threats:

Prompt injection via MCP tools. A malicious document, webpage, or database entry could contain instructions designed to manipulate Claude into taking unintended actions — like exfiltrating data or executing commands. This is the MCP-era equivalent of SQL injection.

Overly permissive MCP servers. An MCP server with broad filesystem or API access means Claude (and by extension the user) can touch far more than they should. Least-privilege is just as important here as anywhere else.

Unvetted third-party MCP servers. The MCP ecosystem is growing fast, and not every community-built server has been security-audited. Employees installing arbitrary MCP servers from GitHub is the shadow IT problem of the AI era.

Credential exposure. MCP servers often need API keys or OAuth tokens to connect to external services. If these are stored insecurely or over-shared, they become a liability.

Local vs. remote server confusion. MCP servers can run locally (on the user's machine) or remotely (hosted services). Remote MCP servers introduce network-level attack surface that local ones do not.

1. Establish an Approved MCP Server Registry

Just as you maintain a software catalogue or an approved SaaS list, create an approved MCP server registry — a curated list of MCP servers that have been reviewed and are permitted for use in your organisation.

For Claude specifically, Anthropic's claude.ai platform exposes MCP integrations through its Connections / Integrations interface. Claude for Enterprise allows administrators to control which integrations are available to users at the tenant level. Enforce usage of only registry-approved servers and disable the ability for end-users to add arbitrary connections.

For users running Claude via Claude Desktop or the Claude API, consider deploying a managed configuration file (claude_desktop_config.json on Windows/macOS) via your endpoint management platform (Intune, Jamf) that pre-defines approved MCP servers — and restricts users from modifying it.

2. Apply Least-Privilege to Every MCP Server

Every MCP server should be scoped to the minimum permissions required for its function. Practically, this means:

• Filesystem MCP servers should be restricted to specific directories, never the root. A user's Claude accessing only ~/Documents/ProjectX is very different from accessing the entire filesystem.

• Database MCP servers should use read-only credentials unless write access is explicitly required — and even then, scoped to specific tables or schemas.

• API-connected MCP servers (e.g., GitHub, Jira) should use OAuth tokens with the minimum required scopes, and those tokens should be rotated regularly.

• Shell/command execution MCP servers should be treated with the highest scrutiny. Consider whether they are necessary at all, and if so, sandbox the execution environment.

Document the permission profile for each approved MCP server in your registry so reviewers and auditors can understand the blast radius of any given integration.

3. Use Remote MCP Servers Over Local Where Possible

For enterprise deployments, hosted/remote MCP servers are generally preferable to locally-run ones because they:

• Can be centrally managed, updated, and monitored by IT

• Can enforce authentication (OAuth 2.0, API keys managed by a secrets vault)

• Can have network-level controls applied (firewall rules, allowlisting)

• Produce server-side logs that feed into your SIEM

Anthropic and a growing number of partners (Atlassian, Box, HubSpot, Linear, and others) publish official hosted MCP servers accessible via verified URLs. Prefer these over community-built local alternatives where the option exists.

When remote MCP servers are used, ensure all traffic goes through your web proxy or CASB so you retain visibility over what data is being sent and received.

4. Manage Secrets Properly

MCP servers frequently need credentials — API keys, OAuth tokens, database passwords. These should never be stored in plaintext in configuration files on user devices.

Best practices:

• Use a secrets management platform (HashiCorp Vault, Azure Key Vault, AWS Secrets Manager) to store and rotate credentials, with MCP server configs referencing secret IDs rather than raw values.

• For OAuth-based integrations, use short-lived tokens and enforce re-authentication periodically.

• Audit which service accounts and API credentials have been issued for MCP use, and revoke any that are no longer active.

• If credentials must be stored locally (e.g., in claude_desktop_config.json), ensure the device is encrypted and the file has appropriate filesystem permissions — not world-readable.

5. Monitor MCP Activity Through Logs and SIEM

Visibility is non-negotiable. Every MCP interaction — tool called, data read, command executed — should leave a log trail.

• For remote MCP servers: ensure server-side logging is enabled and that logs are forwarded to your SIEM (Sentinel, Splunk, etc.). Build alerts for anomalous patterns: unusually large data reads, access outside business hours, calls to sensitive endpoints.

• For local MCP servers: consider deploying endpoint logging agents (e.g., Sysmon on Windows, Unified Log on macOS) that capture process execution events. A Claude Desktop session spawning unexpected child processes is a signal worth investigating.

• For Claude Enterprise: Anthropic provides audit log capabilities at the organisational level. Ensure these are enabled and exported to your log management platform.

Define a baseline of normal MCP usage for your organisation, then alert on deviations.

6. Educate Users on Prompt Injection Risks

Prompt injection is one of the most important — and least understood — security risks in the MCP era. Users need to know that data Claude reads can contain instructions, and that Claude is designed with defences against this, but no defence is perfect.

Practical guidance for users:

• Do not connect Claude via MCP to untrusted data sources (public web scraping, unvetted files from external parties) without understanding the risk.

• Treat unexpected Claude behaviour (e.g., it suddenly asks to send an email or access a file it wasn't directed toward) as a potential injection attempt — stop and report it.

• Never approve Claude actions that seem outside the scope of what you asked for.

This is a cultural and training challenge as much as a technical one.

7. Define a Review and Approval Process for New MCP Servers

The MCP ecosystem is evolving week by week. New servers are published constantly. You need a repeatable process for evaluating and onboarding them:

For servers that pass review, add them to your registry with a documented approval date and reviewer. Revisit annually or when significant updates are released.

Bringing It Together

MCP is not a threat to manage away — it's a capability to govern responsibly. The organisations that get this right will give their employees a genuine AI productivity advantage while keeping their data and systems secure. Those that don't will find themselves dealing with the same shadow IT and data governance problems they've spent years trying to solve, now accelerated by the speed and autonomy that AI brings.

The framework is the same one that's served IT well for decades: inventory, least privilege, monitoring, and user education. What's new is the urgency — and the opportunity.

The question for IT admins in 2026 and beyond is no longer "should we allow AI tools?" It's "how do we allow them well?" MCP is where that question becomes most concrete — and most consequential.