How to secure MCP servers: a practical checklist
Your developers wire MCP (Model Context Protocol) servers into Claude Desktop, Cursor and Copilot in seconds — often with filesystem or shell access, holding real secrets, and appearing in no asset register. This is a free, shareable checklist you can work through today to harden them. It stands on its own; the soft pitch for automating it is at the end.
Why MCP servers need securing
An MCP server is a small program an AI assistant launches to give itself new powers — read your files, run shell commands, call an API, query a database. That is genuinely useful, and it is also a new attack surface. Each server is third-party code running with real permissions, it installs in seconds with no installer or asset-register entry, it often holds credentials, and — as security researchers have shown — a malicious one can hide instructions the AI model reads but you never see. The good news: hardening them is mostly disciplined housekeeping, and you can start now.
First you need to know what you have. If you haven’t inventoried the MCP servers and AI agents on your machines yet, start with the companion guide on discovering every MCP server & AI agent on your fleet, then come back and work through the checklist below.
Eight steps to secure your MCP servers, free
No product required. Work through these on every machine that runs an AI assistant. They’re ordered so the highest-leverage steps — inventory, then least privilege — come first.
1. Inventory every MCP server — and who added it
You cannot secure what you cannot see. List every MCP server registered on each machine, which AI host launches it, and who added it. Each MCP client declares its servers in a JSON config under an mcpServers block — Claude Desktop, Cursor, VS Code, Windsurf and Continue each in their own file. The companion discovery guide has the full per-OS config-path table and the process / connection commands — start there to build the list, then work through the rest of this checklist on what you find. Don’t forget project-scoped configs a developer may have committed inside a repo.
2. Read each server’s tools, permissions and secrets
For every entry, open its command, args and env and ask: what tools does it expose, what can those tools reach (filesystem, shell, network, a database), and which secrets does it hold? Any env key whose name looks like a credential — a token, an API key or a password (for example a name ending in _TOKEN or _API_KEY) — is a secret that server can use. As a rough rule of thumb, treat a server that declares five or more permissions/scopes as elevated and ten or more as excessive, and give anything holding secrets a closer look. NetInsightPro’s risk scoring weighs the same permission thresholds, plus whether the provider is recognised and whether the config references any secrets at all (by key name and count — the values never leave the device).
3. Prefer least privilege — grant the narrowest scope
Most MCP servers are configured with far more reach than the job needs. A filesystem server pointed at / or your home directory can read anything the AI touches; scope it to the one project folder instead. Remove tools the team doesn’t use, drop shell access where a read-only API would do, and prefer servers that let you allow-list the exact operations they may perform. Least privilege is the single highest-leverage step on this list.
4. Pin versions and re-review on update
An MCP server invoked with npx -y or uvx pulls the latest published build every time it runs. Pin to a specific, reviewed version instead, so an upstream change can’t silently alter what the server does. This matters because a server can change a tool’s description after you’ve approved it — a “rug pull” (see the risks below) — so treat every version bump as a change that needs re-reviewing, not an auto-update to trust.
5. Watch for outbound connections to unexpected hosts
A server that declares one purpose but connects somewhere else is a red flag. It’s normal to see traffic to the provider APIs an agent legitimately uses — hosts like api.anthropic.com, api.openai.com, generativelanguage.googleapis.com or api.mistral.ai. What you’re hunting for is the unexpected destination — a “weather” server opening a connection to an unknown host. This is the mirror image of discovery: instead of watching for known AI hosts to find agents, you watch for hosts that don’t belong. (A purely local stdio server opens no socket at all — you catch those in steps 1 and 2, not here.) This native-app egress is exactly what browser DLP and CASB miss — see the Claude Desktop & Cursor local-tool blind spot.
6. Remove or quarantine unknown and over-permissioned servers
Anything you can’t account for — an unrecognised provider, a server nobody remembers adding, one holding secrets it has no reason to — should be disabled or removed until someone can vouch for it. Setting "disabled": true stops it running while you investigate; deleting the entry removes it for good. Don’t leave “I’ll look at it later” servers wired into an assistant with filesystem and shell access.
7. Treat MCP servers as supply chain
Every MCP server is third-party code your AI runs with real permissions. Verify the source before you install — prefer official, well-maintained servers over an unvetted package from a random registry or gist, check who publishes it and how actively it’s maintained, and be wary of servers that ask for far more access than their stated function needs. The same supply-chain discipline you apply to npm or PyPI dependencies applies here, arguably more so, because these run inside an agent that acts on your behalf.
8. Rotate any secrets an untrusted server could have touched
If a server turns out to be untrustworthy — over-permissioned, from an unverified source, or caught connecting somewhere it shouldn’t — rotate the tokens and API keys it had access to. You usually can’t prove after the fact whether a secret was exfiltrated, so treat exposure as possible and rotate precautionarily. It’s cheap insurance against a credential that may already be gone.
The checklist, at a glance
- Inventory every MCP server and who added it
- Read each server’s tools, permissions and secrets
- Grant the narrowest scope (least privilege)
- Pin versions; re-review on every update
- Watch for connections to unexpected hosts
- Remove or quarantine unknown / over-permissioned servers
- Treat MCP servers as supply chain — verify the source
- Rotate secrets any untrusted server could have touched
Free to copy and share with your team. Config-file paths and the process / connection commands to run each check live in the discovery guide.
The risks this checklist defends against
These are real, documented risks — not hypotheticals, and not reasons to panic. Understanding them is what makes the checklist worth doing.
Tool poisoning & prompt injection via tool descriptions
Invariant Labs documented a class of attack where malicious instructions are hidden inside an MCP tool’s description — text the AI model reads in full but that you only see as a simplified label in the UI. Because models are trained to follow tool instructions, a “helpful” tool can quietly be told to read your SSH keys or MCP config and exfiltrate them. It is a form of indirect prompt injection, and it is why reviewing what a server actually exposes (step 2) and preferring vetted sources (step 7) matter. For the full explainer — the variants, why it’s dangerous and how to spot a risky server — see what MCP tool poisoning is.
Rug pulls — trusted-then-changed servers
The same research showed a server can change a tool’s description after you approved it. A server you vetted last week can ship a poisoned update this week. That is the concrete reason to pin versions and re-review on update (step 4) rather than letting npx -y pull the latest build on every run.
Over-permissioned servers
Even a completely honest server is a risk if it can reach far more than it needs. A filesystem server scoped to your whole home directory turns any prompt-injection or bug into a wide-open door. Least privilege (step 3) shrinks the blast radius of everything else on this list.
Primary sources, for the detail: Invariant Labs — MCP tool poisoning attacks and Snyk — detecting tool poisoning. For deep static analysis of a single server, a code-level MCP scanner goes further than any fleet tool — including ours.
The checklist scales badly by hand. That’s what NetInsightPro is for.
Running eight checks on one laptop is easy. Running them on every laptop, on a schedule, and keeping one deduplicated picture of what changed is the tedious part — and the part worth automating. NetInsightPro does the discovery, inventory and evidence-based risk scoring for you across Windows, Linux and Android. AI-agent & MCP security is live on Pro today. The checklist above still stands entirely on its own without it.
Automatic discovery & fleet inventory (Pro)
The same config-file and process inspection you’d do by hand — run continuously on every device, reduced to one deduplicated inventory of every agent, MCP server and tool, on Windows, Linux and Android.
Evidence-based risk scoring (Pro)
Each asset scored Low, Medium, High or Critical from its declared permissions, provider recognition and secret exposure — with the evidence shown, not a black-box number. Vulnerability scanning is included and rolling out; today’s scoring is heuristic and evidence-backed.
One-click block, with an audit trail (Pro)
Block a risky asset per destination host through the OS firewall in one click — so it lands on agents and servers that talk to a network endpoint. On-device quarantine for local stdio assets is rolling out.
Policies & automatic blocking (Enterprise)
Set policies once and let NetInsightPro block matching assets across the fleet automatically, with a SOC view. That is automatic blocking — not automatic remediation; the config-level fixes in the checklist are still yours to make.
We’re early to this category and honest about the edges: NetInsightPro finds what’s running and helps you act on it fleet-wide — it does not edit your configs for you, and for deep per-server static analysis of tool poisoning or prompt injection, a code-level scanner such as Snyk or Invariant Labs goes further. NetInsightPro complements those, it doesn’t replace them. See how discovery works.
What we won’t claim
A checklist you can trust says where its product stops. Here is exactly what NetInsightPro does not do, so you can decide with clear eyes.
NetInsightPro does not remediate. It discovers, inventories, scores and blocks per destination host — but removing a server, narrowing its scope, pinning a version or rotating a token is you editing a config file. Enterprise automatic blocking is auto-block, not auto-fix.
It cannot prove a secret was leaked. NetInsightPro sees the names and counts of secrets a config references, never their values (they never leave the device). “Rotate exposed secrets” is precautionary advice — we can flag exposure, not confirm exfiltration.
Blocking is per destination host through the OS firewall — not per app process, and not by killing a live connection. A purely local stdio MCP server has no destination host; on-device quarantine for those is rolling out. There is no macOS blocking.
The manual checklist above is a real, free alternative and we don’t hide it. NetInsightPro runs alongside your antivirus and any code-level MCP scanner, never instead of them. Vulnerability scanning is included and rolling out — no deep per-package CVE claims, no fabricated metrics or logos.
Frequently asked questions
Automate the MCP-server checklist across your fleet
Start free on up to two devices, or go Pro for cross-platform discovery, inventory, evidence-based risk scoring and one-click block. Runs alongside your antivirus. Data stays on-device.
New to this? Start by discovering the MCP servers on your fleet.