A recent analysis of over 5,200 open-source MCP server implementations found that 53% rely on hardcoded, long-lived API keys or personal access tokens — and only 8.5% use OAuth, the modern standard for secure delegation. Meanwhile, real CVEs are already documented: prompt injection via stored database entries, remote code execution through misconfigured MCP Inspector, and rogue MCP servers impersonating legitimate integrations to exfiltrate data.

MCP security is not a theoretical concern. It is happening now, in production environments, at organisations that assumed their AI tools were safe by default.

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, and 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. And right now, most organisations have no visibility into what their MCP servers are doing at all.

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, and it has already been demonstrated in real-world deployments.

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. Over half of MCP servers in the wild store credentials in plaintext configuration files. If these are over-shared or left on unencrypted devices, they become an immediate 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.

Building and maintaining a registry manually is time-consuming. SuperCISO's MCP Security Gateway gives you a centralised registry out of the box — every connected MCP server visible in one place, with no agent reconfiguration required and no code changes needed. See how it works →

2. Apply Least-Privilege to Every MCP Server

Every MCP server should be scoped to the minimum permissions required for its function.

Filesystem MCP servers should be restricted to specific directories, never the root. Database MCP servers should use read-only credentials unless write access is explicitly required. API-connected MCP servers (e.g., GitHub, Jira) should use OAuth tokens with the minimum required scopes, 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.

This is where most manual governance approaches break down — defining and enforcing tool-level permissions per team, per role, per individual is hard to do consistently without tooling. SuperCISO handles this at the tool level: allow, deny, or read-only permissions per role, across every connected MCP server, from a single interface.

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); and 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 — yet research shows more than half currently are.

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.

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.

Building MCP-specific detection rules from scratch takes significant time — and most organisations simply haven't done it yet. SuperCISO's live log and anomaly detection does this automatically: every tool call logged, unusual spikes flagged in real time, bulk exports blocked before they become incidents. See the full audit trail →

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.

Do not connect Claude via MCP to untrusted data sources without understanding the risk. Treat unexpected Claude behaviour — it suddenly asks to send an email or access a file it wasn't directed toward — as a potential injection attempt, and 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. You need a repeatable process for evaluating and onboarding new servers.

Source and publisher: is this from a verified vendor or a reputable open-source project? Permissions requested: what access does the server require, and is it proportionate? Data residency: where does data sent to this server go, and does it leave your jurisdiction? Authentication: does it use OAuth or API keys properly, or does it store credentials insecurely? Audit logging: does the server produce logs, and can they be integrated into your SIEM? Update cadence: is the server actively maintained, and are security patches applied promptly?

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 scale of the gap between where most organisations are today and where they need to be.

If you want full MCP visibility, granular access control, anomaly detection, and a complete audit trail — without building it from scratch — SuperCISO was designed exactly for this. Start for free →