The Model Context Protocol has become the common language for connecting AI agents to tools and data. An MCP server exposes capabilities, file access, database queries, API calls, internal services, that a model can invoke. That makes the MCP server a high-value piece of infrastructure sitting between an unpredictable language model and your real systems. At Basalt Cyber we assess MCP deployments regularly, and we consistently find servers built for functionality with security bolted on as an afterthought. This checklist gathers the controls we look for, organised so you can work through them against your own server.
Why MCP servers deserve their own threat model
An MCP server has two untrusted neighbours. On one side is the model, which can be manipulated through prompt injection into calling your tools with hostile parameters. On the other side is the wider supply chain of tool definitions, some of which may come from third parties you do not fully control. The server therefore has to defend against a confused, manipulable client and against the possibility that the tools it advertises are themselves malicious. Both directions matter.
Authentication and token scope
The first failure we see is a server that authenticates weakly or not at all, trusting that it sits on a private network. Treat every MCP server as internet-reachable in your threat model.
- Require authentication for every connection; never expose an unauthenticated server.
- Scope tokens to the minimum capabilities the client needs, not a blanket grant.
- Propagate user identity so the server can authorise actions against the real user's permissions rather than a single broad service identity, which avoids the confused-deputy trap.
- Set short token lifetimes and support rotation and revocation.
Tool poisoning and rug-pull descriptions
MCP tools advertise themselves to the model with names and descriptions, and the model reads those descriptions as instructions. This creates a uniquely MCP class of attack. A poisoned tool description can contain hidden instructions that steer the model the moment the tool is listed, even before it is called. A rug-pull is worse: a tool that looks benign when first installed and reviewed, then changes its description or behaviour later to inject instructions or exfiltrate data once trust is established.
- Review every tool description as untrusted instruction content, including hidden or unicode-encoded text.
- Pin tool definitions and detect changes; alert when a previously approved tool's description or schema mutates.
- Isolate tools from different trust domains so one server's tools cannot reference or shadow another's.
- Do not auto-update third-party tools without review.
Injection in tool handlers
Once a tool is invoked, its handler receives parameters chosen by a model that can be manipulated. If those parameters flow unsanitised into a shell command, a SQL query, a file path, or an HTTP request, you have a classic injection vulnerability with the model as the attacker's proxy.
- Never build shell commands by string concatenation; avoid invoking a shell at all where possible.
- Use parameterised queries for every database call.
- Validate and canonicalise file paths to prevent traversal outside intended directories.
- Apply allowlists to outbound requests so a fetch tool cannot reach internal metadata endpoints or arbitrary hosts.
- Constrain and type-check all parameters against a strict schema before use.
Secrets handling
MCP servers often hold the credentials that make tools work: database passwords, API keys, cloud tokens. Those secrets must never reach the model or its context.
- Keep credentials server-side; never return them in tool output or error messages.
- Store secrets in a managed secrets store, not in code or tool descriptions.
- Scope each credential to the single tool that needs it, so a compromise of one handler does not surrender all of them.
- Scrub secrets and tokens from logs and stack traces.
Supply-chain trust
Installing an MCP server is installing code, and installing a remote tool is trusting a third party with a line into your systems. Apply the same rigour you would to any dependency.
- Source servers and tools from providers you can attest to; verify signatures and checksums.
- Pin versions and review changes before upgrading.
- Maintain an inventory of every MCP server and tool in use, with its owner and trust level.
- Sandbox third-party servers so a malicious one cannot reach beyond its intended scope.
Logging and rate limits
You cannot respond to what you cannot see, and you cannot bound what you do not limit. Comprehensive logging plus rate limits turn an MCP server from a blind spot into something you can monitor and contain.
- Log every tool invocation with caller identity, parameters, and outcome, with secrets redacted.
- Rate-limit per client and per tool, with tighter limits on sensitive or destructive operations.
- Alert on anomalies such as unusual tool sequences, parameter patterns, or volume spikes.
- Set timeouts and resource caps so a single request cannot exhaust the server.
Putting the checklist to work
Run this list against every MCP server before it touches production, and re-run it whenever you add or update a tool. The two MCP-specific risks, tool poisoning and confused-deputy authority, are the ones generic application security guidance will miss, so give them extra attention. These controls sit alongside the broader agent defenses in our AI red teaming practice and the platform-level controls in our LLM security work.
Frequently asked questions
Is a private network enough to secure an MCP server?
No. Network isolation helps but the model itself is an untrusted, manipulable client inside the boundary. Authenticate and authorise every call regardless of network position.
What is unique about MCP versus general API security?
Tool descriptions are read by the model as instructions, so poisoning and rug-pull attacks have no direct analogue in a normal API. The supply chain of tool definitions is itself an injection surface.
How do I stop a tool from misusing the server's credentials?
Scope credentials per tool, propagate the end user's identity for authorisation, and never let the agent act with a broad standing identity it can be tricked into abusing.
Takeaway
An MCP server is security-critical middleware between a manipulable model and your real systems. Harden it on both fronts: authenticate and least-privilege the client side, treat tool descriptions and the tool supply chain as untrusted on the other, and instrument everything with logging and rate limits so abuse is bounded and visible.