Are MCP servers safe? Check what your AI tools can touch

MCP servers can be safe, but many aren't set up safely. An MCP server is a plug-in that lets your AI assistant use a tool, like your files, your database or your GitHub, and it usually runs with the same access you have. If it's sloppy, outdated or holding your keys in plain text, your AI tool becomes an easy way in.

You don't need to stop using them. You just need to know what each one can touch. Here's how.

What is an MCP server?

MCP stands for Model Context Protocol. It's a standard way to connect AI apps (like Claude Desktop, Cursor or VS Code) to outside tools. Each connection is an "MCP server."

Think of your AI assistant as a new employee, and MCP servers as the keys you hand them: one for the filing cabinet, one for the company bank account, one for the server room. Handy. Also, every key you hand over is one more thing that can be misused.

You usually add MCP servers by editing a small settings file, often named claude_desktop_config.json, mcp.json or .mcp.json. That file is where most of the risk lives.

Are MCP servers safe to use?

The protocol itself has a careful security guide. The trouble is in how servers are built and how people configure them.

Some numbers:

• Security company Endor Labs looked at 2,614 MCP servers. 82% used file-handling code prone to "path traversal" bugs (where a tool meant for one folder can be tricked into reading any file), and 34% used code tied to "command injection" bugs (where bad input can make the tool run commands on your machine). Source: Endor Labs, Classic Vulnerabilities Meet AI Infrastructure. That's "risky code patterns," not "proven hacks," but it's a lot.
• GitGuardian found 24,008 secrets in public MCP setup files, and 2,117 of them still worked. Part of the reason: setup guides often tell people to paste keys straight into the file. Source: GitGuardian, State of Secrets Sprawl 2026.

More of these on our stats page.

What can an MCP server actually access?

Often, a lot more than you'd guess. The official MCP security guide warns that local MCP servers run with the same privileges as the app that launched them, and it lists the risks plainly: running any command, data theft and data loss. Source: Model Context Protocol, Security Best Practices.

Look for these in your config:

Access to your whole disk. A file server pointed at your home folder, or at / or C:\, can read your documents, your saved passwords files, your SSH keys, everything. Point it at one project folder instead.

Shell or terminal access. A server that can run commands can do anything you can do from a terminal, including deleting files or sending data out.

Database access with full permissions. A read-only user is enough for most AI questions. A full-admin connection is not necessary.

Why are plaintext keys in MCP configs a problem?

Many setup guides show something like this:

{
  "mcpServers": {
    "search": {
      "command": "npx",
      "args": ["-y", "some-search-mcp"],
      "env": { "SEARCH_API_KEY": "sk-...REDACTED" }
    }
  }
}

That key is now sitting in a plain text file. If that file ever gets committed to a public project, synced to a shared drive, pasted into a support chat or read by a malicious tool, the key goes with it. That's how GitGuardian found thousands of working keys.

Better options, depending on your app: reference an environment variable instead of pasting the value, use your operating system's password store, or use servers that sign you in with a login flow rather than a pasted key. And if a key has ever sat in one of these files that you've shared, treat it as leaked. Our guide I leaked an API key. Here's exactly what to do walks through revoking it.

What does "unpinned" mean and why does it matter?

Look at that example again: npx -y some-search-mcp. That tells your computer to download the latest version of that package from the internet every time it starts, and the -y means "don't ask me."

If the package's author gets hacked, or sells the package, or a lookalike gets substituted, the next version runs on your machine automatically, with your access. "Pinning" means naming an exact version, like some-search-mcp@1.4.2, so updates only happen when you choose.

What is auto-approve and should I turn it off?

Many AI apps can ask your permission before each tool action, or skip asking. Skipping is faster. It's also what turns a prompt injection into real damage.

Here's why. If your AI reads a web page or email with hidden instructions (see What is prompt injection?), the only thing standing between "the AI was told to delete files" and "files got deleted" may be that permission prompt. Keep it on for anything that writes, sends, deletes or spends.

How do I pick a safer MCP server?

Before you add a new one, spend two minutes on a quick sniff test:

• Who made it? A server published by the company whose service it connects to is usually a better bet than a random copy with a similar name.
• Is it maintained? Recent updates and answered bug reports are good signs. A project abandoned two years ago is not.
• What does it ask for? If a weather tool wants shell access or your whole home folder, that's a red flag.
• Can it run read-only? Many servers have a read-only mode. Use it unless the AI truly needs to change things.

None of this is a guarantee. It just weeds out the obvious bad bets before they ever touch your machine.

How do I check my own MCP setup?

Paste your config into our free AI Tool Permissions Audit. It works with Claude Desktop, Cursor, VS Code and .mcp.json files, and it runs entirely in your browser, so your config never leaves your computer. It flags:

• plaintext keys sitting in the file,
• unpinned packages that auto-update,
• servers with access to your whole disk or a shell,
• auto-approve settings.

It's free and needs no signup.

Your five-minute fix

1. Find your config files. Look for claude_desktop_config.json, mcp.json or .mcp.json in your AI apps' settings.
2. Run them through the AI Tool Permissions Audit. It's local-only, so it's safe to paste.
3. Delete servers you don't use. Every unused server is risk with no benefit.
4. Shrink access. Point file servers at one folder, use read-only database users, and remove shell access unless you truly need it.
5. Move keys out of the file and rotate any that were in it. Then pin package versions and keep approval prompts on for risky actions.