MCP server security checklistWhat to check before you install.

In early 2026, OX Security mapped the MCP ecosystem and found roughly 7,000 servers in circulation with around 150 million downloads. None of them require a cryptographic signature. None require identity verification from the author. The Model Context Protocol spec defines how servers communicate with agents. It does not define how you decide whether to trust a server before running it.

That gap is the problem.

When you add a server to claude_desktop_config.json, the Claude desktop client spawns it as a local subprocess on startup. From that point, the server can invoke any tool it exposes and can read any output the agent returns. If your agent has a GitHub token, a Stripe key, or a database URL in its environment, the MCP server does too. The spec says nothing about what the server is allowed to do with that.

Snyk researchers demonstrated this concretely in early 2026. They showed that a malicious MCP server could inject prompt content through tool output, redirect the agent to perform actions the user never authorized, and exfiltrate data through what looked like normal agent calls. The attack did not require any vulnerability in Claude or Cursor. It used the MCP protocol exactly as designed.

The short version

Five things to know before you install anything:

1. An MCP server runs with the same credentials and permissions your agent session has. There is no isolation by default.
2. Tool output from an MCP server flows directly into the agent's context window. Attacker-controlled content in that output can redirect agent behavior.
3. OX Security found ~7,000 servers and ~150M downloads with no signature requirement. The ecosystem grew faster than its security model.
4. Many servers are solo-maintained, built from a weekend project, and have no public security disclosure process.
5. The Snyk MCP GitHub prompt-injection heist (early 2026) showed that a server does not need a traditional vulnerability to do serious damage.

The trust questions before installing

Before you add any server, work through these questions. If you cannot answer one, that is itself the answer.

Where is the source code?

Find the repository. Read the source. Not the README. The actual code the tools run. Most MCP servers are small enough that you can read the whole thing in 30 minutes. Look at what each tool does, what files it touches, and what it sends outbound. If there is no public source, stop here.

Verify the binary matches. Clone the repo, build from source, compare the checksum to what the package ships. For npm-distributed servers (npx @company/server), inspect the published package content:

npm pack @company/mcp-server
tar -tf company-mcp-server-*.tgz | head -40

Look for obfuscated scripts, eval calls, or outbound fetch calls that do not appear in the documented feature set.

Who maintains it?

Check the commit history. A server with one author, no issue activity, and commits that cluster around a single week is higher risk than one with multiple contributors and a maintained changelog. Look for:

• A SECURITY.md or equivalent disclosure process
• A history of dependency updates (stale deps compound risk)
• Responses to issues and PRs (tells you if anyone is watching)
• An org with a public track record vs. an anonymous account

Anonymous does not mean malicious. But anonymous with no verifiable history means you have no basis for trust other than reviewing the source yourself.

What tools does it expose, and are they read or write?

List every tool the server declares. Read the descriptions the server reports to the agent, which may differ from what the code actually does. For each tool, ask:

• Does it read or write?
• Does it touch the network?
• Does it execute shell commands?
• Does it read files outside the paths it claims to need?

An MCP server that only reads a local SQLite database and returns rows is a different risk profile from one that can execute arbitrary shell commands or POST to external APIs. Most servers that claim read-only access also ship a "run this for me" tool buried in the list. Count the tools. Understand each one.

What credentials does it need, and how does it use them?

Check the server's configuration format. A server that requires GITHUB_TOKEN in its environment will receive that token every time the agent starts, for the full session. Ask:

• What is the minimum scope the token needs?
• Does the server log its inputs?
• Does it send data to a third-party endpoint?
• Where does it store credentials it receives?

Generate a minimal-scope token for each server. A GitHub MCP server that reads repo metadata does not need repo:write. Give it repo:read and nothing else. Revoke and regenerate if the server's behavior changes unexpectedly.

Does it sandbox child processes?

Some MCP servers spawn their own subprocesses to do work. A code-execution server, a terminal server, a browser automation server. Ask whether those child processes run in any isolation at all: a container, a VM, a chroot, restricted file descriptors. Most do not. A child process that breaks out of its intended scope can write to your filesystem, reach the network, or read the parent's environment. If the server spawns processes and does not document the sandbox, assume there is none.

A related question is whether the server itself has any network egress restrictions. An MCP server with no sandbox and no egress control can silently exfiltrate the contents of tool calls to any endpoint it chooses. The pattern looks identical to a legitimate server doing its job. You will not see it in agent logs because the exfiltration happens inside the server process, not in the agent's output stream.

How MCP servers leak credentials

There are three paths, and the Snyk research covered all of them.

Ambient environment inheritance. When the Claude desktop client spawns an MCP server, the server inherits the full environment of the parent process. If you export OPENAI_API_KEY in your shell profile, and Claude runs from that shell, and Claude starts an MCP server, the MCP server has your OpenAI key whether or not it needs one. The same is true for AWS credentials, GitHub tokens, and database URLs. No code needs to be malicious. The inheritance is automatic.

Prompt injection through tool output. An MCP server returns content that flows into the agent's context window. If the server fetches a web page, reads a file, queries an API, or does anything that involves attacker-controlled input, that input reaches the agent. The Snyk GitHub heist used this: a server that read repository content could be fed a repo containing specially crafted content that redirected the agent's next actions. The agent followed the injected instructions because, from its perspective, those instructions came through a trusted tool call.

Long-lived grants with no revocation. MCP servers do not have a concept of per-call authorization. Once a server is in your config file, it runs for every session until you remove it. There is no per-request credential handoff, no session scoping, no audit trail attached to individual tool invocations. A server that misbehaves in session 47 had the same access in sessions 1 through 46.

This is different from OAuth, where a token has a defined scope and the authorization server can revoke it. It is different from API key management, where you generate a key per integration and rotate on suspicion. MCP sessions inherit ambient credentials and hold them for the session duration. If you want to know whether a specific server touched your GitHub token on a specific day, you currently have no place to look. The agent's conversation log shows tool calls and responses. It does not show what the server did with the credentials it received.

A broker closes that specific gap. Instead of the MCP server inheriting the token from the environment, the session opens a scoped grant. Every grant has an audit record tied to the session and server that requested it. The question "did session 47 touch the prod token" becomes answerable without digging through opaque process logs.

The part most security guides skip

The framing most people use is "npm packages but for agents." That framing is too generous.

npm added package signatures in v7, provenance attestation in 2023 (npm provenance), and a public vulnerability database that feeds into advisories on npmjs.com. The ecosystem built SLSA tooling, dependency scanners, lockfile verification, and automated PR alerts. All of that infrastructure exists because package managers learned these lessons the hard way over a decade.

MCP has none of it. Not yet. The OX Security report from early 2026 says ~7,000 servers and ~150M downloads. No signing. No registry-level security checks. No audit trail. And the stakes are higher: npm packages run code in a build step or at import time. MCP servers run for your entire agent session with your full credential set exposed.

The common response is "just check the source." That is necessary, not sufficient. Most supply chain attacks modify the published artifact, not the public source. A server that passes source review can ship a different binary. Without reproducible builds and checksum verification, source review only catches naive attacks.

You are trusting MCP servers the way you trusted npm packages in 2013. The ecosystem will build the infrastructure. For now, the scrutiny has to come from you.

The checklist

Copy this into a PR description, a runbook, or your team's MCP onboarding doc. Run it every time you add or update a server.

## MCP server install checklist

Source
- [ ] Source repository identified and URL recorded
- [ ] Source code read (not just README)
- [ ] Binary/package built from source and checksum compared
- [ ] No obfuscated code, eval, or unexplained outbound fetches

Maintainer
- [ ] Author identity verified (org or known individual)
- [ ] Commit history reviewed (active maintenance, not abandoned)
- [ ] SECURITY.md or disclosure process exists
- [ ] Dependency staleness acceptable

Tools
- [ ] Full tool list enumerated from server's capability declaration
- [ ] Each tool categorized as read-only or write
- [ ] No undocumented shell-exec or network-write tools present
- [ ] Tool descriptions match what the code actually does

Credentials
- [ ] Minimum-scope token generated specifically for this server
- [ ] Server does not require credentials beyond documented scope
- [ ] No logging of input parameters to external endpoints
- [ ] Credentials stored in config, not hardcoded in source

Sandboxing
- [ ] If server spawns child processes, isolation mechanism documented
- [ ] Child process scope matches documented behavior
- [ ] Network egress limited to documented endpoints

Runtime
- [ ] Server runs in a test environment before production use
- [ ] Tool output reviewed for prompt-injection risk (attacker-controlled content)
- [ ] Server removed from config when not actively needed
- [ ] Incident response plan exists if server is compromised

What this means for your stack

The checklist above handles the decision point. The harder problem is the runtime: once you decide to trust a server, it still runs with ambient credentials for the entire session, with no per-call audit trail, and with tool output feeding directly into the agent context.

A better model holds credentials outside the agent's environment. The agent (and the MCP servers it spawns) get a reference. The actual value appears inside a specific child process at exec time and disappears when the process exits. Tool output that flows back through the agent context contains nothing with monetary or access value. An audit log records every grant, so you can answer "did session 47 touch the prod token" in three seconds.

hasp is one working implementation of that model. curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, hand the next session a reference instead of a key. Source-available (FCL-1.0), local-first, macOS and Linux, no account.

The MCP ecosystem will build better tooling over time. Registry-level signing, provenance attestation, automated security scanning: all of it is coming because the npm story played out once already. Until then, the scrutiny is manual, and the credential surface is yours to manage.