What is Model Context Protocol?
In late 2024, Anthropic published the Model Context Protocol (MCP) — an open standard that allows AI assistants like Claude to connect to external tools and data sources. Within months, every major AI coding tool had adopted it: Claude Code, Cursor, Zed, and a growing ecosystem of community-built MCP servers.
The idea is powerful: instead of copy-pasting file contents into a chat window, you configure an MCP server that gives the AI direct access to your filesystem, your database, your Git repository, or your internal APIs. The AI can then read, search, and (depending on permissions) modify those resources as part of its work.
For developers, this is transformative. For security teams, it is a new and largely invisible attack surface.
Why MCP is a Security Risk
Access Without Visibility
When a developer installs a filesystem MCP server and connects it to Claude Code, they have just given an AI model — one that communicates with Anthropic's infrastructure — read access to potentially their entire home directory or project tree. In most organizations, this happens with zero IT visibility.
MCP servers are typically configured in a JSON file (~/.claude/mcp.json, ~/.cursor/mcp.json, etc.) that no existing security tool reads. Your EDR does not know it exists. Your CASB cannot see it. Your DLP has no policy for it.
Tool Escalation
MCP servers are not read-only by default. A developer might install an MCP server that provides:
- Filesystem access — read and write files anywhere on the endpoint
- Database access — query internal databases that the developer's machine can reach
- Shell execution — run arbitrary commands on the host
- Internal API access — call internal services using the developer's credentials
Any of these represents a significant data exposure risk. An AI model that has been given shell access through MCP can exfiltrate data to Anthropic's servers as part of a seemingly normal coding conversation.
Prompt Injection via MCP
A subtler risk: MCP servers that retrieve external data (web pages, GitHub issues, Slack messages) can be used to inject malicious instructions into the AI's context. An attacker who knows a developer is using a web-scraping MCP server can craft a webpage that, when retrieved, instructs the AI to perform actions the developer did not intend.
What Good MCP Governance Looks Like
Step 1: Inventory. Know which MCP servers exist across your fleet. This requires an endpoint agent that reads AI tool configuration files — network monitoring alone is not enough, because local MCP servers do not make outbound network connections.
Step 2: Classify. Not all MCP servers are equal risk. A server that provides read-only access to a developer's local project directory is very different from one that provides shell execution or database write access. Classify each server by the tools it exposes.
Step 3: Policy. Define which MCP server types are permitted, which require approval, and which are blocked outright. Apply these policies fleet-wide, automatically.
Step 4: Alert. Get notified when new MCP servers appear — especially ones with high-privilege tool access. Treat "new MCP server with filesystem write access" like you treat "new outbound connection to unknown IP."
How Sielum Handles MCP
Our agent reads MCP configuration files for every supported AI tool on each endpoint. It reports:
- The name and command of each configured MCP server
- The tool types it exposes (filesystem, database, shell, API, etc.)
- Whether it has been approved under your organization's policy
The server classifies each MCP server and generates alerts for anything that matches your risk policy — for example: "MCP server with write_file or execute_command tool discovered on endpoint dev-42, not in approved list."
Your security team gets a central view of every MCP server across the fleet, with the ability to approve, block, or flag for review. Approved servers are persisted; new servers immediately generate an alert until reviewed.
The Bottom Line
MCP is not going away. It is the direction the entire AI tooling ecosystem is moving. The question is not whether your developers are using MCP servers — they almost certainly already are. The question is whether your security team knows.
You cannot secure what you cannot see. Start there.
Want to see a demo of MCP discovery in action? Talk to our sales team — we run proof-of-concepts on real enterprise environments.