Deep Dives9 min read

MCP Security Risks: What Mac Users Need to Know About AI Tool Servers

HassanainMarch 24, 2026

I wrote my complete guide to AI agent security on Mac a couple of weeks ago, and a lot of you had the same follow-up question: what about MCP specifically? You wanted the deep technical picture — how the protocol works, what exactly it exposes, and why security researchers keep flagging it. So here it is.

MCP (Model Context Protocol) is the open standard that Anthropic created to let AI agents connect to external tools. It's how Claude Code reads your files, how OpenClaw talks to your email, and how custom agents connect to databases, APIs, and services. I use MCP tools every single day building CoreLock. They are genuinely useful. They are also, right now, one of the most under-secured pieces of infrastructure on any developer's Mac.

This post is not anti-MCP. The protocol is solving a real problem. But the security model has not caught up to the adoption curve, and 30 CVEs in the first year of production use tells you everything you need to know about where we are.

What Is MCP and How Does It Work?

Model Context Protocol is a client-server protocol built on JSON-RPC 2.0. If you're familiar with the Language Server Protocol (LSP) that powers VS Code's language integrations, MCP borrows the same message-flow architecture but applies it to AI agent tool use.

The architecture has three layers:

Hosts are the applications you interact with — Claude Desktop, Claude Code, Cursor, OpenClaw, or any custom agent application. The host manages the user session and the LLM connection.

Clients live inside the host. Each client maintains a one-to-one connection with a single MCP server. The client handles protocol negotiation, capability discovery, and message routing.

Servers are the tool providers. Each server exposes a set of capabilities to the agent through three primitives:

Tools — functions the agent can call. A file system server exposes tools like read_file, write_file, list_directory. A GitHub server exposes create_issue, list_pull_requests, merge_branch. The agent discovers available tools via tools/list and invokes them via tools/call.
Resources — data the agent can read. These are like GET endpoints — file contents, database records, API responses. The agent can subscribe to resource updates.
Prompts — reusable prompt templates the server provides. Less commonly used, but they allow servers to shape the agent's behavior for specific workflows.

A single host can connect to multiple servers simultaneously. Right now, as I type this, Claude Code on my machine is connected to a file system server, a git server, and a web search server. Each one is a separate process running on my Mac.

This is where the security story begins.

How MCP Servers Access Your Mac

Every MCP server runs as a child process of the host application. When Claude Code spawns an MCP server, that server inherits the same user permissions as Claude Code itself — which inherits the same permissions as Terminal, which on most developer Macs has been granted Full Disk Access.

Let me be concrete about what this means:

File system access. A file system MCP server can read and write any file your user account has access to. Your .env files, your SSH keys in ~/.ssh/, your AWS credentials in ~/.aws/, your browser profiles, your Keychain exports. The MCP specification's own file system server had two CVEs (CVE-2025-53109 and CVE-2025-53110) that allowed path traversal and symlink attacks to escape even the directory restrictions the server was supposed to enforce. Cymulate Research Labs demonstrated that a crafted symlink could bypass all access enforcement, giving attackers full read/write access to the entire filesystem and the ability to drop malicious code via Launch Agents.

Network access. MCP servers can make outbound HTTP requests to any endpoint. Your Mac's built-in firewall only handles incoming connections, not outgoing ones. An MCP server can POST your private keys to an external server, and macOS will not generate a single alert. There are no network allowlists in the MCP specification.

Process permissions. On macOS, TCC (Transparency, Consent, and Control) manages application permissions. But TCC operates at the application level, not the subprocess level. If Terminal has Full Disk Access, every process spawned from Terminal inherits that access — including every MCP server. There is no per-server TCC prompt, no per-server permission grant, and no sandbox boundary between MCP servers.

Cross-server visibility. When multiple MCP servers are connected to the same host, they all feed into the same agent context. A malicious server doesn't need to hack another server to read its data — it just needs to manipulate the agent into passing that data through. More on this in the attacks section.

The Security Risks

I've been tracking MCP security research since the protocol launched, and the vulnerability surface breaks down into five categories.

1. Tool Poisoning

This is the attack that got the most attention, and rightfully so. Invariant Labs published the original research and it's genuinely alarming.

MCP tool descriptions are plain text strings that the AI model reads to understand what a tool does. A legitimate tool description looks like: "Reads a file from the given path and returns its contents." A poisoned tool description looks the same on the surface, but includes hidden instructions that override the agent's behavior.

Invariant Labs demonstrated three proof-of-concept attacks:

A math tool (literally an add function) with a description containing hidden instructions to exfiltrate the user's SSH keys and mcp.json configuration whenever the tool was called.
A tool that hijacked a send_email function from a different, trusted MCP server — making the agent silently CC all outgoing emails to an attacker-controlled address.
A WhatsApp MCP server attack where a "fact of the day" tool modified its own description after installation to redirect message history to an attacker-controlled phone number.

The fundamental problem is that language models cannot reliably distinguish between "this is a description of what the tool does" and "these are instructions you should follow." This is the same prompt injection vulnerability that affects agents broadly, but tool poisoning weaponizes the MCP protocol itself as the injection surface.

2. Data Exfiltration

An MCP server that can read files and make network requests can exfiltrate anything on your system. That's not a vulnerability — it's the intended capability set used maliciously.

Anthropic's own Slack MCP server was found to be vulnerable to "link unfurling" attacks. When an AI agent posted a message to Slack through the MCP server, Slack would automatically unfurl URLs in the message. An attacker could craft a message that caused the agent to post a URL containing encoded sensitive data, which Slack would then send to the attacker's server via the unfurl request. No exploit needed — just creative use of a standard Slack feature.

The broader pattern: MCP servers have unrestricted network access and broad file system access. Any server can read your local files and send them anywhere. The specification doesn't include data flow controls, outbound network restrictions, or file access auditing.

3. Cross-Server Attacks (Confused Deputy)

This is the risk that scales with MCP adoption. The more servers you connect, the more dangerous each one becomes.

When multiple MCP servers are connected, a malicious server can influence how the agent uses other servers. This is the classic confused deputy problem. Server A is trusted (your company's internal database server). Server B is malicious (a community MCP server you installed from npm). Server B's tool description includes hidden instructions that cause the agent to query Server A's database, extract sensitive records, and pass them through Server B's network connection.

Neither server is "hacked." The agent is doing exactly what it's been instructed to do — it just can't tell that the instructions are malicious. The attack surface grows combinatorially with each additional server.

4. No Permission Granularity

As of the current specification, MCP has an authorization framework built on OAuth 2.1 with PKCE. This handles authentication — proving who a client is to a server. But it does not handle fine-grained authorization at the tool level.

There is no mechanism to say: "This file system server can read /Users/me/projects/ but not /Users/me/.ssh/." There is no read-only mode for servers that only need to inspect data. There is no network allowlist that restricts which domains a server can contact. There is no capability scoping that limits which tools a server can expose based on context.

A server is either connected or it's not. When it's connected, it operates with the full permissions of the host process. The MCP specification acknowledges this gap — the security best practices documentation recommends "principle of least privilege" — but provides no enforcement mechanism.

5. Supply Chain Risk

MCP servers are distributed through npm, pip, GitHub, and increasingly through community registries. The same supply chain risks that have plagued package ecosystems for a decade apply directly here.

Three chained CVEs in Anthropic's own mcp-server-git (CVE-2025-68145, CVE-2025-68143, CVE-2025-68144) demonstrated that a malicious .git/config file could achieve full remote code execution when combined with the filesystem MCP server. Research from Upwind found that approximately 36.7% of MCP servers on the web contained latent SSRF vulnerabilities similar to the one disclosed in Microsoft's MarkItDown MCP server.

This isn't speculative. The same supply chain patterns hitting OpenClaw's skill marketplace are hitting MCP server registries. An MCP server is just an npm package or Python script with a JSON-RPC interface. If you'd be cautious about running an unknown npm package with sudo, you should be equally cautious about connecting an unknown MCP server to your AI agent.

What macOS Doesn't Protect You From

I build Mac security software, so let me be direct about what Apple's built-in protections do and don't cover here.

TCC inheritance. macOS TCC controls are application-scoped, not process-scoped. When Terminal has Full Disk Access, every subprocess inherits it. MCP servers don't trigger their own TCC prompts because they're child processes of an already-authorized application. This is documented behavior, not a bug — but it means the permission model that protects you from random apps doesn't apply to MCP servers at all.

No outbound firewall. The macOS Application Firewall blocks incoming connections. It does nothing about outbound traffic. An MCP server exfiltrating data via HTTPS POST to an attacker's server looks identical to legitimate API traffic at the network level. You won't see a prompt, an alert, or a log entry unless you have third-party monitoring.

No process isolation. macOS App Sandbox provides strong isolation for App Store applications. But MCP servers don't run in the App Sandbox. They're command-line processes spawned from Terminal or an Electron app, running with full user-level access. There's no process-level containment.

Gatekeeper doesn't apply. Gatekeeper checks code signatures and notarization for applications downloaded from the internet. MCP servers installed via npm install or pip install bypass Gatekeeper entirely — they're scripts, not signed application bundles.

The net result: macOS treats MCP servers the same way it treats any shell script you run in Terminal. If you trust Terminal, macOS trusts everything Terminal spawns. That's a reasonable model for manual command-line usage. It's a dangerous model when an AI agent is autonomously spawning and interacting with multiple server processes.

How to Stay Safe with MCP

The MCP security model is immature, but that doesn't mean you're helpless. Here's what I actually do — not theoretical advice, but practical steps I follow on my own development machines.

1. Audit Every Server Before Installing

MCP servers are usually small — a few hundred lines of TypeScript or Python. Before you connect a new server, read the source code. Check what network requests it makes, what file paths it accesses, and what data it sends in tool responses. If the source isn't available, don't install it.

2. Minimize Connected Servers

Every connected server expands the attack surface. Only connect the servers you're actively using. Disconnect servers between sessions if your host application supports it. The cross-server confused deputy attack only works when multiple servers are connected simultaneously.

3. Check Your Host App's Permissions

Open System Settings, go to Privacy & Security, and check what permissions your Terminal app or agent host has. If Terminal has Full Disk Access (most developer Macs do), understand that every MCP server inherits that access. Consider whether you can run agent sessions from a more restricted application.

4. Monitor Network Activity During Agent Sessions

This is where runtime monitoring actually matters. You can't prevent an MCP server from making network requests through configuration alone — but you can detect unexpected connections. Watch for connections to unfamiliar domains, especially during tool execution.

CoreLock monitors process spawning and network connections in real time. When an MCP server makes an unexpected outbound connection or accesses a sensitive file path, CoreLock flags it. This is exactly the kind of behavioral monitoring that fills the gap between what MCP promises and what MCP enforces. You can check it out here.

5. Use MCP-Scan

Invariant Labs released MCP-Scan, an open-source security scanner specifically designed for MCP configurations. It checks for tool poisoning patterns, known vulnerable server versions, and suspicious tool descriptions. Run it against your mcp.json configuration regularly.

6. Watch for Server Updates

Like any npm package, MCP servers receive updates. An update can introduce malicious behavior that wasn't present in the version you reviewed. Pin server versions in your configuration and review changelogs before updating.

The Path Forward

The MCP specification is actively evolving. The June 2025 spec update introduced OAuth 2.1-based authorization, and the November 2025 anniversary release added task tracking and structured output. Permission scoping and fine-grained authorization are on the roadmap.

The community is building tooling around the gap. Invariant Labs' MCP-Scan handles static analysis. Snyk released agent-scan for runtime vulnerability detection. Cloudflare published authorization middleware for remote MCP servers.

But specifications and tooling take time to mature. The 30 CVEs filed against MCP implementations in the first year — including critical RCE vulnerabilities in Anthropic's own reference servers — show that the ecosystem is still in its "move fast and break things" phase. The security fundamentals are catching up, but they haven't arrived yet.

In the meantime, runtime behavioral monitoring is what fills the gap. You can't configure your way to safety when the protocol itself doesn't enforce boundaries. What you can do is watch what MCP servers actually do on your system — what files they read, what network connections they make, what processes they spawn — and flag anything anomalous.

That's what I built CoreLock to do. Not because I don't trust MCP as a protocol — I use it every day. But because trust and verification aren't the same thing, and right now, MCP gives you trust without verification. You need something watching the other side.

Ready to try CoreLock?

Free to download. No credit card required.

Download CoreLock Free

Back to all posts